servidor CentOS. O que significa quando o total de RAM usado não é igual à soma de RES?

2

Estou tendo um problema com um servidor virtual hospedado executando o CentOS. No mês passado, um processo (baseado em java) que estava sendo executado corretamente começou a ter problemas ao obter memória quando a JVM foi iniciada.

Uma coisa estranha que eu notei é que quando eu começo o processo, o PID diz que está usando 470mb de RAM enquanto a memória 'usada' cai imediatamente em mais de 1GB. Se eu correr 'top', o RES total usado em todos os processos fica aquém do 'usado' listado no topo por quase 700mb.

A pessoa de suporte diz que isso significa que tenho um vazamento de memória com o meu processo. Eu não sei em que acreditar porque eu esperaria que um vazamento de memória simplesmente desperdiçasse a memória que o processo está alocado - não consumir memória adicional que não aparece usando 'top'.

Sou um desenvolvedor e não um servidor, por isso estou apelando para os especialistas. Para mim, se a memória total do RES não resultar no total 'usado', isso indica que algo está errado com a configuração do meu servidor virtual. Devo suspeitar de um processo java com vazamento de memória neste caso?

Se eu usar free antes:

             total       used       free     shared    buffers     cached  
Mem:       2097152     149264    1947888          0          0          0  
-/+ buffers/cache:     149264    1947888  
Swap:            0          0          0 

free depois:

             total       used       free     shared    buffers     cached  
Mem:       2097152    1094116    1003036          0          0          0  
-/+ buffers/cache:    1094116    1003036  
Swap:            0          0          0  

Portanto, parece que o processo está usando (ou fazendo com que seja usado) quase 1 GB de RAM. Como o processo (baseado em top está usando apenas 470mb, isso significa que o kernel está repentinamente usando um adicional de 500MB?

Editar: saída adicionada de cat proc/meminfo - com o aplicativo java em execução:

MemTotal:      2097152 kB
MemFree:       1112672 kB
Buffers:             0 kB
Cached:              0 kB
SwapCached:          0 kB
Active:              0 kB
Inactive:            0 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:      2097152 kB
LowFree:       1112672 kB
SwapTotal:           0 kB
SwapFree:            0 kB
Dirty:               0 kB
Writeback:           0 kB
AnonPages:           0 kB
Mapped:              0 kB
Slab:                0 kB
PageTables:          0 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:         0 kB
Committed_AS:        0 kB
VmallocTotal:        0 kB
VmallocUsed:         0 kB
VmallocChunk:        0 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB
    
por rilkeanmind 25.06.2011 / 05:24

2 respostas

4

O campo "usado" em top reflete a quantidade total de RAM utilizada, incluindo processos, buffers de arquivos e cache. Mas o número RES mostra apenas a quantidade de RAM usada por um processo, exclusiva dos buffers de arquivo.

Para ver realmente o quanto de RAM está sendo usado sem os buffers, use o comando free e observe a linha -/+ buffers/cache . O número na coluna "usado" mostra a quantidade de RAM que está sendo usada pelos processos.

Veja um exemplo:

$ free
             total       used       free     shared    buffers     cached
Mem:       2057196    1812352     244844          0     344768     833660
-/+ buffers/cache:     633924    1423272
Swap:      2097148          0    2097148

Esta saída mostra que o sistema tem 2GB de RAM, dos quais 1.8GB estão sendo usados. No entanto, 344 MB disso são usados pelos buffers e 833 MB são usados pelo cache. Subtrair isso deixa apenas 633MB sendo usado pelos processos e pelo kernel.

Execute o comando free antes e depois de iniciar seu aplicativo Java para ter uma ideia melhor do que está acontecendo.

Editar: removeu referências à memória do kernel, que não são relatadas por essas ferramentas.

    
por 25.06.2011 / 05:44
1

Não deixe que o cache e os zeros de troca o preocupem, pois é um host VPS.

O cache e a troca de E / S são provavelmente manipulados pelo host de virtualização subjacente e eles provavelmente decidiram que a troca e o armazenamento em cache de i / o em guests, com sua configuração, impõe uma penalidade de desempenho ou algo assim, o que pode ser uma boa coisa significa que você recebe 2 GB de RAN apenas para seus processos. Normalmente, os engenheiros de provedores de hospedagem sabem o que estão fazendo.

Esta também pode ser a razão pela qual as coisas não se encaixam muito, já que, devido à forma como o seu VPS é preso (se eles usam algo como o OpenVZ) você pode não ver todas as coisas que usam sua RAM no topo, mas são necessários para que seus processos sejam executados e, portanto, são contados contra sua cota.

Além disso, você não está obtendo toda a imagem, se tudo o que você está comparando é o seu único processo Java, pois o aplicativo pode iniciar processos adicionais, até mesmo um monte deles, que se somam. Essa quantidade de memória não sendo contabilizada, por exemplo, poderia facilmente ser um vazamento de memória do aplicativo Java. Ele está gerando processos e alocando RAM sem retorná-los de volta ao SO, provavelmente.

Seu aplicativo inicia ou usa algum processo nativo? Isso gera outros processos ou threads?

    
por 30.06.2011 / 12:33