Jim is right, I missed what he pointed out about all memory being in cache.
> Someone else mentioned possible I/O problem. > > What is a bit irritating in all this is that cp should NOT have > grabbed so much main memory and allocated it to disk cache. It took > 99.65% of the memory. I would have expected it to throttle back and > only use 95% of the available memory, insteading of grabbing > everything but 86 megabytes, which was almost minimal for this smp > system. (16 processors) The use of memory in this case is not your performance issue. The way any modern operating system works is that it will use up as much memory as possible in caching, since accessing disks is several orders of magnitude slower than accessing memory. After all, if you're not using the memory for anything else, why not cache recently used disk blocks for efficiency's sake? The key thing to note here is that *if* you needed that memory for something more important, like launching a new process, then the kernel would immediately yield the cache to you for that purpose with no performance penalty. As for the I/O explanation, part of the reason your system became so slow is that your hard drive's head is thrashing. You are copying data from one part of the disk to another, which means the disk has to seek to one region of the disk, read the information, then seek to another region to write it. This back-and-forth seeking is a huge performance killer. Add on top of that the fact that you are trying to use the system, causing additional processes to read/write other regions of disk, so that just exacerbates the seek issue. Modern magnetic hard drives just do not do well with operation in parallel. For more parallel performance, people either turn to RAID (each disk is another channel for parallel operation) or SSD (no seek penalty). HTH, tim _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
