I have one comment on page 80 where you wrote "...memory being used by
each process (RSS - SHARE)."
SHARE tells you how much virtual memory is being shared between
processes. RSS is a measure of physical memory. So RSS - SHARE is not
valid. What you need to know (on page 80) is how much physical memory is
being used by shared memory for a process. I guess this would be called
RSHARE.
Finding out the resident shared memory per process is not possible by
default on Linux from the output of top of /proc//maps. We hit this
problem at the $DAYJOB, when we tried to figure out the increase in
memory usage per qmail-smtpd when linking in some new libraries.
exmap can tell you how much
memory a process is actually using. AFAIK it only works with Linux 2.6.
-- Richard Dawe
This is very true. While it is very common to calculate memory usage the way I suggested, Rich's commentary makes me think on it a bit harder. While the technique can be close to accurate, it can also be widly inaccurate depending on how you processes are created.
Most modern UNIX-like systems rely heavily on copy-on-write semantics to make fork() very fast. When a process has a mixture of memory mapped files, memory mapped private segments, heap, stack, and formal shared memory segments it is fairly easy to identify which parts are resident and which of the explicitly non-private parts could be shared with other processes. However, if that proccess fork()s, then the child effectively shares even the private parts -- at least until it modifies specific pages. Basically, this is really complicated. It make sizing things quite challenging.
This motivates one to change "as little as possible" after a fork(). And leads us to the explanation of why it is such a good idea to preload all your perl modules in mod_perl before you fork() Apache children. The parse and compile of perl modules is unlikely to ever be dirtied by a child process and this it truly does remain shared.
Rich's point is right on the money though -- the information in top is not the right information to be using as it can be very misleading. Checkout exmap on Linux and explore pmap on Solaris for a much more detailed picture of a process' memory usage.
Download