fork: Recurso temporariamente indisponível rodando JVM

Question

Estou executando uma instância do Tomcat 6 em uma instância de 34 GB do EC2. Eu tenho lutado para manter a memória baixa, mas essa coisa atende a muitas solicitações e a pilha frequentemente recebe até 13 GB. Mas o monte é outra história.

O problema real agora é que depois de algum tempo o servidor pára de responder e os comandos do console são atendidos com uma mensagem "bifurcação: Recurso temporariamente indisponível".

Como o servidor está com problemas neste ponto e nada está no console do EC2 ou do ssh, não sei como diagnosticar isso. Depois de reiniciar e sair por algum tempo, o topo parece com isso:

Mem:  35847580k total, 28719420k used,  7128160k free,   221432k buffers
Swap:        0k total,        0k used,        0k free, 11103780k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                   
 xxxx tomcat    25   0 19.9g  15g 9832 S   86 44.1  36:01.69 java        

Tenho certeza de que meus ulimits estão altos o suficiente e nada em /etc/security.conf limitaria o processo Java. Eu tenho cerca de 30.000 threads e um número igual de FDs. Nada no syslog, além de algumas mensagens de SYN flodding (isso acontece quando o GC da JVM e nós estamos sob carga pesada)

Mais alguma coisa que eu deveria olhar? ( 2.6.21.7-2.fc8xen-ec2-v1.0 btw)

    

Answer 1

Soa muito como se você estivesse ficando sem memória. fork () basicamente falhará apenas por causa dos limites de ulimit (número de descritores de processo ou arquivo) ou falta de memória. Então, se você não está acertando seus ulimits, isso significa que você está sem memória.

O

root geralmente é excede os limites, como no máximo # de processos, mas verifique seu limits.conf para ter certeza. Dependendo da configuração do EC2, você pode não conseguir fazer login diretamente como root, então, nesse caso, você provavelmente terá que manter um shell de root aberto na caixa ...

Um sistema com problemas pode não conseguir fazer o log no disco, então a única maneira de saber o que está acontecendo provavelmente é através do "dmesg" (que imprime o buffer de anel do kernel). Tente manter um shell de root aberto na caixa com a seguinte execução:

while true ; do dmesg -c ; sleep 0.1 ; done

Além disso, manter um vmstat 1 em exibição pode revelar algo interessante, como, por exemplo, troca pesada ...

Você usou seu syslog para "oom-killer"?