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).
Use strace -f R to follow R and all its child processes as well. This should show the exact point where the child program hangs.
Some additional possible points to check:
as root (su - root), and as the user john, compare the outputs of:
ulimit -a #will show all the "limits" set for that user. You may reach one of them?
set ; env #maybe john & root don't have same PATH or some other thing changes (LD_LIBRARY_PATH? or another?)
grep $(whoami) /etc/passwd /etc/group #see if john maybe needs to be in some group?
Best Answer
valgrindwill give you this information, along with a number of other statistics on memory use (and it will tell you about memory leaks etc.). It will slow the program down somewhat, but since yours is a short-lived process it shouldn't be an issue.Here's example output from running
ls:The specific information you're looking for is given by the "total heap usage" line.