Identificando memória física perdida

Question

Estou tendo problemas com um servidor ficando sem memória física e estou tendo problemas para discernir se é do processo Java do meu aplicativo ou de alguma outra coisa no servidor. Vamos pegar o seguinte cenário:

Memória física do servidor: 3747MB
Java -Xms64m
Java -Xmx512m
Java XX: MaxPermSize = 512 m

Quando inicializo o servidor, o sistema operacional (RHEL) informa que 487 MB estão sendo usados, usando sua ferramenta de relatório de memória favorita ( top, cat /proc/meminfo | grep Mem, free -m , etc). Quando inicio meu processo Java (pid 123), ele usa cerca de 215 MB de memória física (conforme relatado pela memória RES em ps -f -p 123 ), levando meu total de memória usada para cerca de 700 MB.

Se eu deixá-lo funcionar por um dia inteiro, a memória RES do meu processo flutua um pouco, mas geralmente é consistente. No entanto, a memória total do servidor aumentou constantemente em torno de 1500MB, levando-o a um total de 2200MB.

Se meu tamanho de heap Java ou heap de perm fosse crescente, ele não seria refletido na memória RES do processo?

Além disso, parece que não consigo contabilizar esses 1500 MB extras em nenhum lugar.

# ps aux | awk '{ RES+=$6 } END { printf("RES: %.2fMB\n", RES/1024) }'
RES: 722.23MB

Alguém pode me ajudar a encontrar essa memória perdida? Eu estou basicamente tentando descobrir se esse é o meu problema com o aplicativo, ou o problema da equipe de infraestrutura com a compilação do seu servidor.

    

Answer 1

O Linux usa a política de recuperar, mas não marcar como "realmente livre" qualquer memória usada recentemente (na teoria de que esfregar custa esforço, deixar as coisas em volta caso alguém as use novamente não custa nada e pode economizar um pacote) . Não se preocupe com relatórios de "memória livre". Observe o quanto (se houver) swap está sendo usado (swap é essencialmente um espaço em disco para requisitos de memória que realmente sobrecarregam a memória física; o disco é extremamente lento, você não precisa dele). Se você está preocupado com o desempenho, instalar e configurar software de monitoramento como o infame sar ( sysstat , certamente há um pacote para o seu sistema), ele registrará o que está acontecendo em detalhes minuciosos para leitura posterior. Com esses relatórios em mãos, você saberá o que (se é que há alguma coisa) é o seu gargalo. O gracejo de que "A otimização prematura é a raiz de todo o mal" é porque as pessoas são notoriamente ruins em adivinhar onde estão os problemas reais de desempenho, e acabam "consertando" algo que está funcionando perfeitamente bem.