How to calculate the total RAM used by several processes
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. |
All times are GMT -5. The time now is 02:30 PM. |