This was inspired by a recent thread:
Trying to use the libgtop examples
Cross-posted to linuxquestions.org: http://www.linuxquestions.org/questi...63#post4492563
In the spring I was involved with a web based project involving some technology new to me and everyone else concerned, and our memory usage turned out to be significantly more than was predicted, so we needed to scrutinize what was responsible for what. To that end, I wrote a simple process monitor that could be used to log statistics for individual process over a period of time (days or weeks). Ie, it is based on the proc filesystem, but it is not a re-invented "top".
Since then I've refined the tool and it seems to me worth sharing, so I sat down to write a manual page. One of the things I wanted to do with that was explain some of the familiar memory measurements (RSS, VSZ, etc) from proc in a concise and concrete way not available elsewhere (although there are many discussions of these things available via online searching). While the tool serves its purpose for me based on my current understanding of these things, I'm a stickler for accuracy and do not want to spread erroneous information, so I'm looking for feedback about the following draft:
The first 4 fields are directly from /proc/[pid]/statm, the fifth is calculated by parsing /proc/[pid]/maps. I've highlighted the bits that I'm most concerned about, since these are "facts" inferred by me from use, experimentation, existing documentation, etc, and for which I have been unable to find direct confirmation.
This is the total of all the memory regions (RAM and swap) used or
partially used by the process, including all the shared libraries,
which (generally) account for most of it. Hence, this is not a mea‐
sure of the load added by the process, since (generally) much of
those shared libraries are already in play.
Resident Set Size (RSS). This is much closer to the load added by
the process, however, it still includes some memory shared (or
sharable) by other processes spawned from the same executable. If
this is the only instance running, it is an accurate measure of
how much memory the process has consumed.
This is not the total of all the shared libraries used, ie, sub‐
tracting it from the virtual size will not give you the resident
size. It is a total of all the actual shared mappings (eg, those
parts of shared libraries actually in use).
This is the bulk of the process's private, dynamically changing
This is all the memory used by the process marked as private and
writable. The significance of this figure is that it is the
actual load added by the individual process if there are multiple
instances; pmap(1) will also report this figure.
I'm also curious as to whether Data+Stack includes heap memory; it seems to me it does. If so, I could say "including stack and heap".