Each process can have "normal" memory, shared memory (which may or may not be shared!) and code/library files, all of which seem to be included in the %RSS column on top.

We are trying to graph a breakdown of the RAM used by process, each running as a different user.

Is there some way we can work out how much system RAM (not swap space) is being used by a given list of PIDs, or even for each user?

Currently we are running top and scraping the values in the %RSS column, but these seem to add up to more than the total RAM used (excluding buffers+cached). I suspect this is because of shared code and libraries, and other shared memory, being counted multiple times.

I know about /proc/#/statm and /proc/#/status but I can't work out how to link the values between different processes.


For an abstract example (I don't have much real data at the moment), consider that two processes, A and B, both use libbig.so (50Mb), and B and C both share a 1Mb shared memory segment, and each happens to have a working-memory+code footprint of 10Mb:

Total RAM used by A = 60Mb
Total RAM used by B = 61Mb
Total RAM used by C = 11Mb
Sum total RAM used by A, B and C together = 182Mb (not a useful value!)
Aggregate total RAM used by A, B and C together = 81Mb (since the .so are shared).

Can anyone point me at some reference for this?

I doubt an old version of Suse like that will be at the correct kernel version, but search for "smaps".
On later 2.6 kernels it is /proc/<pid>/smaps

Oops; I should update that.

Actually, this is not for my home machine anyway. It will be running on Red Hat Enterprise Linux 5 under kernel 2.6.9-perp-SMP-HIGHMEM (64-bit processors, probably Xeons).

Thanks for pointing me at smaps. I don't suppose there's some way to get a snapshot of processes by memory segment, rather than relying on nothing having changed while we iterate over processes?

In case it's useful, I also found this article (looking for documentation on smaps), which looks to be concerned with the same problem: http://bmaurer.blogspot.com/2006/03/...ith-smaps.html

Short answer - no.

You might be able to get away with a kernel hack, but to make sure nothing changed, you'd be playing with a lot of locks you shouldn't be.
Samples are just that - no good trying to be too specific.

And yes that perl is handy - worth a look if you have an applicable kernel.