Uso real de memória de um processo

A seguir estão os usos de memória mysqle, apacherespectivamente, no meu servidor. De acordo com a saída de pmapdizer, mysqlestá usando cerca de 379M e apacheestá 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 que os valores estão quase correspondentes.

  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, teriam excedido os 512M ramno meu sistema e entendo o fato de que esses são o tamanho das páginas atribuídas a esses dois processos e não são realmente o tamanho da memória usada ativamente por eles. Agora, quando usamos pmap -x, vejo uma coluna extra Dirtyque mostra muito menos uso de memória para o processo. Como visto no exemplo mostrado abaixo, o Dirtycoloumn mostra 15M em oposição a 379M no primeiro coloumn. Minha pergunta é: o valor em coloumn Dirtyé a quantidade 'real' de memória usada ativamente por esse processo? Caso contrário, como podemos descobrir o uso real da memória de um processo? Não pse toppelas mesmas razões acima. Temos alguma coisa sob/proc que vai dar 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 ~]#

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

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

• Armazenamento transitório usado apenas por esse processo.
• Compartilhado com outros processos usando uma variedade de mecanismos.
• Backup de um arquivo de disco.
• Na memória física ou troca.

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

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

Vou citar algo que escrevi na página de manual de um aplicativo que faz uma análise semelhante à parte superior e extrai informações das mesmas fontes que pmap(por exemplo /proc/[N]/maps):

ESPAÇO DE ENDEREÇO ​​VIRTUAL VS. MEMÓRIA FÍSICA

É importante entender a diferença entre o espaço de endereço virtual e a memória física na interpretação de algumas das estatísticas acima. Como o nome indica, o espaço de endereço virtual não é real; é basicamente um mapa de toda a memória atualmente alocada para um processo. O limite para o tamanho desse mapa é o mesmo para cada processo (geralmente de 2 a 4 GB) e não é acumulado (ou seja, você pode ter dezenas ou centenas de processos, cada um com seu próprio endereço virtual de 2 a 4 GB) espaço, em um sistema que na verdade possui apenas 512 MB de memória física ).

Os dados não podem realmente ser armazenados ou recuperados do espaço de endereço virtual; dados reais requerem memória física real. O trabalho do kernel é gerenciar um em relação ao outro. As estatísticas de espaço virtual (VirtualSz, Data + Stack e Priv & Write) são úteis para considerar a estrutura de um processo e o relacionamento com o uso de memória física, mas, com relação à quantidade de RAM realmente usada, as estatísticas de memória física (ResidentSz, Share e Proporção) é o que conta.

pmapestá relatando principalmente informações sobre o espaço de endereço virtual . Sua observação de que "os valores estão quase correspondentes" na topsaída presumivelmente se refere à figura VIRT, que é muito diferente da figura RES. Eles correspondem exatamente ao que acima rotulei "VirtualSz" e "ResidentSz" (o VIRT é para virtual, o RES é para residente).

Agora, quando usamos o pmap -x, vejo uma coluna extra Dirty que mostra muito menos uso de memória no processo. Como pode ser visto no exemplo a seguir, o Coloumn sujo mostra 15M em oposição a 379M no primeiro coloumn. Minha pergunta é: O valor em coloumn Dirty é a quantidade 'real' de memória usada ativamente por esse processo?

Não, mas mais ou menos. Memória "suja" refere-se a dados que foram carregados do disco e modificados posteriormente; desde que foi modificado, ele deve fazer parte da memória residente porque essas alterações estão atualmente armazenadas na RAM. No entanto, não é sinônimo dele.

A memória virtual é como números de discagem rápida, exceto que existem cerca de 3 bilhões (ou seja, 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 diretamente, eles têm para ser mapeado para discagem rápida.

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

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