Uso real da memória de um processo

Question

A seguir, o uso de memória de mysql e apache , respectivamente, no meu servidor. De acordo com a saída de pmap , mysql está usando cerca de 379M e apache está usando 277M.

[root@server ~]# pmap 10436 | grep total
 total           379564K

[root@server ~]# pmap 10515 | grep total
 total           277588K

Comparando isso com a saída de top , vejo os valores quase iguais.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
10515 apache    20   0  271m  32m 3132 S  0.0  6.6   0:00.73 /usr/sbin/httpd
10436 mysql     20   0  370m  21m 6188 S  0.0  4.3   0:06.07 /usr/libexec/mysqld --basedir=....

Agora, esses valores definitivamente não são o uso atual de memória desses dois processos, pois, se fosse, ele teria excedido os 512M ram em meu sistema e eu entendo o fato de que esses são o tamanho das páginas atribuídas a esses dois processos e não o tamanho da memória usada ativamente por eles. Agora, quando usamos pmap -x , vejo uma coloumn Dirty extra que mostra muito menos uso de memória para o processo. Como visto no exemplo abaixo, a Dirty coloumn mostra 15M em oposição a 379M na primeira coluna. Minha pergunta é: O valor sob coloumn Dirty é a quantidade real de memória usada ativamente por esse processo? Se não, então como podemos descobrir o uso real da memória de um processo? Não ps e top pelas mesmas razões acima. Temos alguma coisa abaixo de /proc que dê essa informação?

[root@server ~]# pmap -x 10436 | grep total
total kB          379564   21528   15340
[root@server ~]#


[root@server ~]# free -m
             total       used       free     shared    buffers     cached
Mem:           489        447         41          0         52        214
-/+ buffers/cache:        180        308
Swap:         1023          0       1023
[root@server ~]#

    

Answer 1

Não há comando que forneça o “uso real de memória de um processo” porque não existe o uso de memória real de um processo .

Cada página de memória de um processo pode ser (entre outras distinções):

• Armazenamento temporário usado apenas por esse processo.
• Compartilhado com outros processos usando vários mecanismos.
• Backup por um arquivo em disco.
• Na memória física ou troca.

Eu acho que a figura "suja" adiciona tudo o que está na RAM (não swap) e não é apoiado por um arquivo. Isso inclui memória compartilhada e não compartilhada (embora na maioria dos casos, exceto em servidores de forking, a memória compartilhada consiste apenas em arquivos mapeados na memória).

As informações exibidas por pmap vêm de /proc/PID/maps e /proc/PID/smaps . Esse é o uso real da memória do processo - não pode ser resumido por um único número.

    

Answer 2

Vou citar algo que escrevi na página do manual para um aplicativo que faz análises semelhantes às informações principais e de desenho das mesmas fontes que pmap (por exemplo, /proc/[N]/maps ):

VIRTUAL ADDRESS SPACE VS. PHYSICAL MEMORY

It is important to understand the difference between virtual address space and physical memory in interpreting some of the above statistics. As the name implies, virtual address space is not real; it's basically a map of all the memory currently allocated to a process. The limit on the size of this map is the same for each processes (generally, 2-4 GB), and it is not accumulated (ie, you may have dozens or hundreds of processes, each with its own 2-4 GB virtual address space, on a system that only actually has 512 MB of physical memory).

Data cannot actually be stored or retrieved from virtual address space; real data requires real, physical memory. It is the kernel's job to manage one in relation to another. Virtual space stats (VirtualSz, Data+Stack, and Priv&Write) are useful for considering the structure of a process and the relationship to physical memory use, but with regard to amount of RAM actually used, the physical memory stats (ResidentSz, Share, and Proportion) are what counts.

pmap está reportando principalmente informações sobre o espaço de endereço virtual . Sua observação de que "os valores são quase iguais" em top output presumivelmente se refere à figura da VIRT, que é muito diferente da figura do RES. Estes correspondem exatamente ao que acima eu rotulei de "VirtualSz" e "ResidentSz" (o VIRT é para virtual, o RES é para residente).

Now, when we use pmap -x, I see an extra coloumn Dirty which shows far less memory usage for the process. As seen in the example show below, the Dirty coloumn shows 15M as opposed to 379M in the first coloumn. My question is: Is the value under coloumn Dirty is the 'real' amount of memory actively used by that process?

Não, mas mais ou menos. Memória "suja" refere-se a dados que foram carregados do disco e modificados subseqüentemente; desde que foi modificado, deve ser parte de memória residente porque estas mudanças estão atualmente armazenadas na RAM. No entanto, não é sinônimo disso.

    

Answer 3

A memória virtual é como os números de discagem rápida, exceto que existem cerca de 3 bilhões deles (para sistemas de 32 bits, 4 bilhões para aplicativos de 32 bits no kernel de 64 bits, muito mais para aplicativos de 64 bits) e você não pode discar números , eles precisam ser mapeados para a discagem rápida.

Vários processos podem ter diferentes mapeamentos (números de discagem rápida) para o mesmo endereço (números de telefone). Por exemplo, eles podem compartilhar várias bibliotecas, portanto, ter endereços virtuais para toda a biblioteca (você pode ver isso em pmap). Eles podem até compartilhar o mesmo executável, e. 2 instâncias de bash.

Até agora, isso explica como o sub de todo o endereço virtual pode se encaixar, mas há mais. Um processo pode ter tanta memória virtual que não cabe, como? Algumas partes de uma biblioteca ou executável não podem ser usadas, elas não serão copiadas do disco para a memória RAM, ou a memória RAM fica cheia e os bits que foram carregados do disco são descartados, porque podem ser recuperados do disco se necessário, ou memória que não é suportada, meu disco é mapeado para swap, copiado para swap e depois descartado. Ele pode então ser lido de swap se e quando necessário. Se alguma dessas estratégias anteriores for muito usada, o sistema ficará lento.