OOM-Killer, jboss e kernel panic

Question

Estamos executando o RedHat 3.4.6 (x32) no VMWareEsx3.5 (x64) com 6 GB de RAM. Alguns processos java (incluindo o jboss) estão sendo executados em segundo plano.

O problema é que os processos java consomem muita memória e, às vezes, são mortos pelo OOM-killer. Quando OOM-killer está prestes a agir, a memória física livre é muito baixa, 100MB-200MB, mas a troca não é usada (99% livre). Às vezes isso causa um pânico no kernel também.

• Então, por que o swap não é usado?
• Como investigar este pânico do kernel?
• Está usando 6GB de memória em 32bit Redhat sábio?

Obrigado

    

Answer 1

Em link

Máquinas virtuais RHEL4 executando o Oracle / Java matam aleatoriamente processos por matador de OOM Detalhes O OTM killer elimina os aplicativos, embora o ESX não esteja sob carga de memória. O topo do comando mostra que muita memória está sendo armazenada em cache e o swap está sendo mal utilizado. Solução

Quando o tamanho dos dados a serem copiados excede o tamanho da memória física, o oom-killer inicia processos de eliminação 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 da 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, fornecendo assim mais 'proteção' para as zonas. Esse problema é identificado no RHEL pelo Redhat e eles forneceram uma solução alternativa para isso nos seguintes artigos:

    

Answer 2

Pessoalmente, eu nunca usaria o PAE (mais de 4G de RAM em um sistema de 32 bits). Você obterá uma quilometragem muito melhor executando um kernel e um sistema reais de 64 bits.

OOM só deve ser acionado quando um malloc falhar. (não quando você tem muita troca disponível)

O kernel de 32 bits provavelmente faz parte da causa. A PAE usa diferentes zonas de memória e pode ser que uma zona não seja permitida a malloc de outra.

Você modificou seu swappiness? (Com que facilidade 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 pânico do kernel? (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 no Monit)

Melhor da sorte