Que estatísticas de memória o comando do 'ps' do Linux realmente exibe?

Question

Considere a seguinte saída pmap de um processo simples de tail no 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

Dado o processo e o estado dele, posso obter ps para gerar várias informações sobre seu uso de memória:

$ 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

No entanto, com exceção do campo VSZ da l output, todos eles diferem mais ou menos da info pmap sobre os mapeamentos individuais. O mais estranho de tudo é claramente o campo SZ da saída -l , que eu simplesmente não consigo descobrir, em absoluto, o que está contando. Não encontrei nenhuma explicação sobre o que isso faz em qualquer documentação (a manpage menciona algo enigmático sobre a "imagem principal", mas não define esse termo, e não consigo ver nenhuma combinação de campos de pmap que somaria 1766 ou até mesmo qualquer coisa remotamente próximo a isso). Alguém sabe?

No entanto, o campo RSS das saídas v e l também é um pouco diferente de pmap , assim como o campo DRS na saída v . Embora a diferença não seja tão boa, isso ainda me deixa perplexa.

    

Answer 1

O campo SZ , que é descrito pela documentação do ps como (por completo):

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.

parece ser idêntico ao primeiro número informado pelo procfs em /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

O formato de statm é descrito na documentação do kernel ( /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)
..............................................................................

Isto não é muito informativo, mas pelo menos mostra que o próprio kernel linux reporta esse número.