Consider the following pmap
output of a simple tail
process on Linux:
$ pmap -x 3974
3974: tail -F /var/log/syslog
Address Kbytes RSS Dirty Mode Mapping
0000000000400000 60 36 0 r-x-- tail
000000000060e000 4 4 4 r---- tail
000000000060f000 4 4 4 rw--- tail
0000000000610000 132 12 12 rw--- [ anon ]
00007ffff7775000 2792 44 0 r---- locale-archive
00007ffff7a2f000 1672 432 0 r-x-- libc-2.17.so
00007ffff7bd1000 2048 0 0 ----- libc-2.17.so
00007ffff7dd1000 16 16 16 r---- libc-2.17.so
00007ffff7dd5000 8 8 8 rw--- libc-2.17.so
00007ffff7dd7000 16 12 12 rw--- [ anon ]
00007ffff7ddb000 132 104 0 r-x-- ld-2.17.so
00007ffff7fd7000 12 12 12 rw--- [ anon ]
00007ffff7ff7000 12 12 12 rw--- [ anon ]
00007ffff7ffa000 8 4 0 r-x-- [ anon ]
00007ffff7ffc000 4 4 4 r---- ld-2.17.so
00007ffff7ffd000 8 8 8 rw--- ld-2.17.so
00007ffffffde000 132 24 24 rw--- [ stack ]
ffffffffff600000 4 0 0 r-x-- [ anon ]
---------------- ------ ------ ------
total kB 7064 736 116
Given the process and the state of it, I can get ps
to output various information about its memory usage:
$ ps -lp 3974
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
0 S 1000 3974 3972 0 80 0 - 1766 - pts/0 00:00:00 tail
$ ps vp 3974
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
3974 pts/0 Ss+ 0:00 3 57 7006 660 0.0 tail -F /var/log/syslog
$ ps lp 3974
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
0 1000 3974 3972 20 0 7064 660 - Ss+ pts/0 0:00 tail -F /var/log/syslog
However, with the exception of the VSZ
field from the l
output, these all differ more or less from the info pmap
gives about the individual mappings. Most strange of all is clearly the SZ
field from the -l
output, which I just can't seem to at all figure out what it's counting. I haven't found any explanation of what it does in any documentation (the manpage mentions something cryptic about the "core image", but doesn't define that term, and I can't see any combination of fields from pmap
that would add up to 1766 or even anything remotely close to that). Does anyone know?
However, the RSS
field from the v
and l
outputs also differ slightly from pmap
, and so does the DRS
field in the v
output. Though the difference isn't all that great, it still perplexes me a bit.
The SZ
field, which is described by ps
's documentation as (for completeness):
size in physical pages of the core image of the process. This includes text, data, and stack space. Device mappings are currently excluded; this is subject to change. See vsz and rss.
seems to be identical to the first number reported by the procfs
in /proc/$PID/statm
:
$ tailf /var/log/vmware-installer &; PID=$! $ pmap -x $PID | tail -n 1 total kB 6788 616 132 $ ps -lp $PID F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 0 S 516 13848 13657 0 85 5 - 1697 - pts/7 00:00:00 tailf $ cat /proc/$PID/statm 1697 153 120 2 0 81 0
The format of statm
is described in the kernel documentation (/usr/src/linux/Documentation/filesystems/proc.txt
):
Table 1-3: Contents of the statm files (as of 2.6.8-rc3) .............................................................................. Field Content size total program size (pages) (same as VmSize in status) resident size of memory portions (pages) (same as VmRSS in status) shared number of pages that are shared (i.e. backed by a file) trs number of pages that are 'code' (not including libs; broken, includes data segment) lrs number of pages of library (always 0 on 2.6) drs number of pages of data/stack (including libs; broken, includes library text) dt number of dirty pages (always 0 on 2.6) ..............................................................................
This is neither much informative, but at least shows that the linux kernel itself reports that number.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments