Estamos executando RedHat 3.4.6(x32) em VMWareEsx3.5(x64) com 6 GB de RAM. Alguns processos java (incluindo jboss) estão sendo executados em segundo plano.
O problema é que os processos Java consomem muita memória e às vezes são eliminados pelo OOM-killer. Quando o OOM-killer está prestes a agir, a memória física livre é muito baixa, 100 MB-200 MB, mas a troca não é usada (99% livre). Às vezes, isso também causa pânico no kernel.
- Então, por que a troca não é usada?
- Como investigar esse kernel panic?
- Está usando 6 GB de memória no Redhat de 32 bits?
Obrigado
Responder1
Pessoalmente, eu nunca usaria PAE (mais de 4G de RAM em um sistema de 32 bits). Você obterá uma quilometragem muito melhor executando um kernel e sistema reais de 64 bits.
O OOM só deve ser acionado quando um malloc falhar. (não quando você tem muitas trocas disponíveis)
O kernel de 32 bits provavelmente é parte da causa. O PAE usa zonas de memória diferentes e pode ser que uma zona não tenha permissão para fazer malloc de outra.
Você modificou sua troca? (Com que rapidez o kernel usará swap.) cat /proc/sys/vm/swappiness ?
Você também pode investigar o ajuste de vm.dirty_ratio ou vm.lower_zone_protection = 100.
Você capturou o kernel panic? (um console serial geralmente é uma boa maneira de fazer isso)
Você também pode tentar antecipar o OOM-Killer com seu próprio software de monitoramento de processo. (dê uma olhada em Monit)
Boa sorte
Responder2
Máquinas virtuais RHEL4 executando Oracle/Java eliminam processos aleatoriamente pelo OOM killer Detalhes O OOM killer elimina aplicativos mesmo que o ESX não esteja sob carga de memória. O comando top mostra que muita memória está sendo armazenada em cache e a troca quase não está sendo usada. Solução
Quando o tamanho dos dados a serem copiados excede o tamanho da memória física, o oom-killer começa a eliminar processos aleatoriamente.
Isso pode ser corrigido executando:
sysctl -w vm.lower_zone_protection 100
Quando lower_zone_protection é definido como 100, ele aumenta o limite de página livre em 100, iniciando assim a recuperação de página mais cedo e evitando que o NFS (Network File System) fique muito atrás das demandas de memória do kernel. Isso faz com que a recuperação da página aconteça mais cedo, proporcionando assim mais “proteção” para as zonas. Este problema é identificado no RHEL pela Redhat e eles forneceram uma solução alternativa para isso nos seguintes artigos: