A process's resident set size is the amount of memory that belongs to it and is currently present (resident) in RAM (real RAM, not swapped or otherwise not-resident).
For instance, if a process allocates a chunk of memory (say 100Mb) and uses it actively (reads/writes to it), its resident set size will be about 100Mb (plus overhead, the code segment, etc.). If after the process then stops using (but doesn't release) that memory for a while, the OS could opt to swap chunks of that memory to swap, to make room for other processes (or cache). The resident set size would then decrease by the amount the kernel swapped out. If the process wakes up and starts re-using that memory, the kernel would re-load the data from swap, and the resident set size would go up again.
The ru_maxrss
field of struct rusage
is the "high water mark" for the resident set size. It indicates the peak RAM use for this process (when using RUSAGE_SELF
).
You can limit a process's resident set size to avoid having a single application "eat up" all the RAM on your system and forcing other applications to swap (or fail entirely with out-of-memory conditions).
RSS is how much memory this process currently has in main memory (RAM). VSZ is how much virtual memory the process has in total. This includes all types of memory, both in RAM and swapped out. These numbers can get skewed because they also include shared libraries and other types of memory. You can have five hundred instances of bash
running, and the total size of their memory footprint won't be the sum of their RSS or VSZ values.
If you need to get a more detailed idea about the memory footprint of a process, you have some options. You can go through /proc/$PID/map
and weed out the stuff you don't like. If it's shared libraries, the calculation could get complex depending on your needs (which I think I remember).
If you only care about the heap size of the process, you can always just parse the [heap]
entry in the map
file. The size the kernel has allocated for the process heap may or may not reflect the exact number of bytes the process has asked to be allocated. There are minute details, kernel internals and optimisations which can throw this off. In an ideal world, it'll be as much as your process needs, rounded up to the nearest multiple of the system page size (getconf PAGESIZE
will tell you what it is — on PCs, it's probably 4,096 bytes).
If you want to see how much memory a process has allocated, one of the best ways is to forgo the kernel-side metrics. Instead, you instrument the C library's heap memory (de)allocation functions with the LD_PRELOAD
mechanism. Personally, I slightly abuse valgrind
to get information about this sort of thing. (Note that applying the instrumentation will require restarting the process.)
Please note, since you may also be benchmarking runtimes, that valgrind
will make your programs very slightly slower (but probably within your tolerances).
Best Answer
From the man page for ps: