Tech Blog

The ps tool can output various pieces of information about a process, such as its process id, current running state, and resource utilization. Two of the possible outputs are VSZ and RSS, which stand for “virtual set size” and “resident set size”, which are commonly used by geeks around the world to see how much memory processes are taking up.

Why ps is “wrong”
Depending on how you look at it, ps is not reporting the real memory usage of processes. What it is really doing is showing how much real memory each process would take up if it were the only process running. Of course, a typical Linux machine has several dozen processes running at any given time, which means that the VSZ and RSS numbers reported by ps are almost definitely “wrong”. In order to understand why, it is necessary to learn how Linux handles shared libraries in programs.
The moral of this story is that process memory usage on Linux is a complex matter; you can’t just run ps and know what is going on. This is especially true when you deal with programs that create a lot of identical children processes, like Apache. ps might report that each Apache process uses 10 megabytes of memory, when the reality might be that the marginal cost of each Apache process is 1 megabyte of memory. This information becomes critial when tuning Apache’s MaxClients setting, which determines how many simultaneous requests your server can handle.
You can find the memory used by a program (process) by looking into /proc directory or using standard command such as ps or top. However, you must calculate all memory usage by hand i.e. add Shared Memory + mapped file + total virtual memory size of the process + Resident Set Size + non-swapped physical memory used by process.

 pmap reports the memory map of a process or processes  { pmap <pid> }

                

[vijayk@serria-new src]$ pmap 2652
2652: smsc4
Start         Size Perm Mapping
00111000     1224K r-xp /lib/tls/libc-2.3.2.so
00243000       16K rw-p /lib/tls/libc-2.3.2.so
00247000        8K rw-p [ anon ]
006d9000       84K r-xp /lib/ld-2.3.2.so
006ee000        4K rw-p /lib/ld-2.3.2.so
0084d000       52K r-xp /lib/tls/libpthread-0.60.so
0085a000        4K rw-p /lib/tls/libpthread-0.60.so
0085b000        8K rw-p [ anon ]
00cc7000      132K r-xp /lib/tls/libm-2.3.2.so
00ce8000        4K rw-p /lib/tls/libm-2.3.2.so
00fca000       44K r-xp /lib/libnss_files-2.3.2.so
00fd5000        4K rw-p /lib/libnss_files-2.3.2.so
08048000     2000K r-xp /data/sarita/benin/src/smsc4
0823c000      268K rw-p /data/sarita/benin/src/smsc4
0827f000   220356K rw-p [ anon ]
15dee000     6848K rw-p [ anon ]
8b079000        4K —p [ anon ]
8b07a000    10240K rw-p [ anon ]
8ba7a000        4K —p [ anon ]
8ba7b000    10240K rw-p [ anon ]
8c47b000        4K —p [ anon ]
8c47c000    10240K rw-p [ anon ]
8ce7c000        4K —p [ anon ]

   

 

 

 

 

you can use the following command to figureout how much memory leakage is happening in terms of VSZ.

 1st instance

[vijayk@serria-new src]$ ps -eo pid,stime,etime,vsz,rss,sz,args | grep msc
 2652 10:38       26:27 951276 274708 237819 ./msc

2nd Instance

[vijayk@serria-new src]$ ps -eo pid,stime,etime,vsz,rss,sz,args | grep msc
 2652 10:38       29:27 951290 274708 237819 ./msc

The variation in terms of VSZ is the memory leakage.
                                        { Ref : Linux memory debug tutorials. }.