Dicas, Java, JVM, Tools

Colhendo envidências em caso de erro (crash) na JVM

Sabe aquela situação em que a equipe responsável pelo ambiente de produção chega pra você e diz: “o servidor X está caindo toda hora… já olhamos os recursos da máquina (rede, memória, cpu e disco), inclusive o log do servidor, mas não identificamos nada…”

Isso mesmo! Há casos em que seu processo caiu sem dar explicações e sem deixar pista alguma.

Já tive a oportunidade de passar por essa situação algumas vezes… Trata-se de uma situação complicada, pois quase sempre ocorre em um momento e ambiente crítico onde o tempo para solução é o seu pior inimigo. Bem, após bater cabeça com esse tipo de problema, posso afirmar que a melhor opção é preparar o seu ambiente para colher algumas evidências quando o problema voltar a ocorrer. Como quase tudo na TI esse tipo de situação é inevitável. Softwares e Hardware podem falhar por “n” motivos. Nesse post deixo algumas dicas que podem lhe ajudar na investigação “pós queda” de um processo Java (rodando em cima de uma JVM).

Existem dois casos em que é bastante comum o processo da JVM cair:

  1. insuficiência de memória
  2. algum erro fatal da jvm

O tipo de erro relacionado à insuficiência de memória é o conhecido por OutOfMemoryError (OOM) e ocorre devido à algum memory leak no código da aplicação. Para analisar a causa desse tipo de erro é interessante ter em mãos o estado (snapshot) do Heap da JVM no momento em que o erro ocorre. Para isso é necessário habilitar alguns parâmetros na JVM conforme abaixo:

Geração do Dump (formato hprof) do Heap da JVM.

Adicionar as seguintes propriedades no comando que inicia a JVM. Caso o comando seja parametrizado em um arquivo de configuração, basta usar uma variável JAVA_OPTS como no exemplo abaixo.

# HeapDUMP e Core DUMP
# registra a data e hora de início do processo
DATE_START=`date  +%d-%m-%Y-%k%M`

# Habilita a geração do DUMP de memória (HPROF)
JAVA_OPTS="$JAVA_OPTS -XX:+HeapDumpOnOutOfMemoryError "
JAVA_OPTS="$JAVA_OPTS -XX:OnOutOfMemoryError=<execute algum comando shell aqui (ex: 'kill -9%p')> "
JAVA_OPTS="$JAVA_OPTS -XX:HeapDumpPath=/var/log/jvm/heapdump_$DATE_START.hprof "

 

NOTA:

  • Recentemente encontrei uma implementação alternativa à opção ‘-XX:OnOutOfMemoryError’ interessante. Vale a pena testar!
  • o arquivo de dump no formato .hprof pode ser aberto com os utilizatários jVisualvm (fornecido pelo JDK Sun/Oracle Hotspot) ou Eclipse Memory Analizer (MAT). É necessário que a versão e arquitetura do JDK utilizado na análise dump seja idêntica à JVM utilizada pelo servidor de aplicação onde o erro ocorreu.

O segundo caso de erro pode ser gerado por algum problema entre a JVM e SO. Um caso típico é o erro de estouro de pilha conhecido como StackOverflowError. Esse tipo de erro pode ocorrer caso a aplicação utilize algum tipo de loop infinito ou uma recursividade muito profunda. O tamanho da pilha alocada pela JVM durante a criação de uma thread java é de 1024KB (1mb) em um sistema Linux x64. É possível alterar esse valor para mais ou para menos a depender da necessidade da aplicação. O parâmetro da JVM -Xss:<n>k altera o valor da pilha, sendo que <n> é um valor inteiro.

Geração do coredump (threads e memória) da JVM

Adicionar as seguintes propriedades no comando que inicia a JVM.

# Habilita a geração de coredump (BIN)
JAVA_OPTS="$JAVA_OPTS -XX:OnError='gcore -o /var/log/jvm/jboss_PID%p_$DATE_START.coredump %p' "
JAVA_OPTS="$JAVA_OPTS -XX:ErrorFile=/var/log/jvm/hs_err_jboss_PID%p_$DATE_START.log "

NOTAS:

  • A opção ‘-XX:OnError‘ é executada apenas quando  a causa raiz do erro for Nativo devido a alguma falha fora da JVM – JVM Native Crash.
  • o arquivo de dump no formato hprof pode ser aberto com os utilizatários jVisualvm (fornecido pelo JDK) ou Eclipse Memory Analizer (MAT).  É necessário que a versão e arquitetura do JDK utilizado na análise dump seja idêntica à JVM utilizada pelo servidor de aplicação onde o erro ocorreu.
  • Para que o comando gcore (invocado pela JVM após o evento de erro) funcione é necessário que o pacote gdb (A GNU source-level debugger for C, C++, Fortran and other languages) esteja devidamente instalado no Sistema Operacional.

Uma opção mais eficiente para geração de Dumps em JVMs com Heaps grandes (>= 2gb)

Utilizar o jmap em heap muito grandes pode demorar horas para concluir. Em algumas situações é necessário reiniciar o serviço imediatamente após a falha para diminuir o tempo em que ele fica fora do ar. Uma excelente alternativa é descrita nesse artigo disponível no Blog da Atlassian: So you want your JVM’s heap…

Gerando dumps da JVM em tempo de runtime manualmente

O formato binário pode ser aberto com as ferramentas: jstack (JDK), jVisualVM (JDK), Eclipse MAT ou qualquer outro profiler Java que reconheça o formato HPROF.

jmap -dump:live,format=b,file=jvm_heap.bin <PID>

O formato texto pode ser aberto com as ferramentas: jVisualVM (JDK), IBM Thread Analizer ou qualquer outro profiler Java que reconheça dump de threads Java.

jstack -F -l <PID> > /tmp/jvm_thread.dump

NOTA: os procedimentos acima causam o travamento das threads (equivalente ao efeito Stop The World do FullGC). Portanto utilize com cautela em ambiente de produção!

A análise dos dumps citados neste post é assunto para um novo post. Existem várias ferramentas que podem ser utilizadas na análise. Além das ferramentas é importante ter conhecimento da arquitertura da Máquina Virtual Java utilizada. No caso do dump de memória (heap) é importante conhecer a divisão geracional dos pools de memória da JVM , bem como os vários mecanismos de coleta de lixo. Para o dump de threads é importante conhecer um pouco sobre a execução de threads na plataforma Java: sincronização, pilha de execução, thread monitor, thread status (WAINTING, RUNNING, BLOCKED, etc). Com a ferramenta certa e com um pouco de paciência é possível chegar a tão desejada causa raiz do problema: nome da classe, nome do método, nome da biblioteca ou até mesmo a linha de código que causa ou influência o crash do processo Java.

Anúncios

3 comentários sobre “Colhendo envidências em caso de erro (crash) na JVM

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s