[PLUG] a bit more information

Tim tim-pdxlug at sentinelchicken.org
Thu Mar 29 14:24:46 UTC 2012


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



More information about the PLUG mailing list