IBM HeapAnalyzer

Problemas de java core e dumps em ambientes WebSphere Application Server são bem comuns.
Isso deve-se pois o WebSphere Application Server roda em cima de uma JDK devido produto ser interpretado, diferente de outros produtos que são executados.
Os problemas apresentados são os mais diversos tanto com o próprio WebSphere Application quanto das aplicações que estão rodando no ambiente.
Problemas do produto logo são detectados e lançados fixpacks ou ifix de correção. Porém, quando se trata de aplicações é onde mora o maior problema.
O administrador por sua vez deve ter a habilidade de detectar o problema, investigar e dizer onde se encontra. É comum colocar a culpa no produto, mas em sua grande maioria o problema está na aplicação de terceiro. Neste post, vou mostrar como o administrador pode identificar e analisar um heapdump.

Out of Memory
Este é um dos problemas mais comuns que ocorrem. Um Out of memory ocorre devido a falta de memória principal onde os objetos não podem ser mais alocados para uso no sistema operacional. No caso do WebSphere o problema ocorre pois o máximo size de java alocado ultrapassou o limite. Neste caso o garbage collection não conseguiu limpar os objetos desalocados que não mais estão sendo utilizados na memória gerando um IBM java heapdum.

IBM Java heapdump
IBM Java virtual machine gera um dump de todos os objetos alocados (vivos) que estão em um Java heap, ou seja, aqueles objetos que estão sendo utilizados pelo aplicativo Java. Esse descarregamento é chamado de IBM Java heap dump. Ele exibe os objetos que estão utilizando espaço de memória em um Java heap.

O javacore e heapdump se localizam na profile do servidor. was_profile.

São dois arquivos gerados: javacore e dump.

Javacore: Possui a extensão .txt e sua estrutura é definida como:

Cabeçalho

Exibe a identificação do dump com sua versão e sistema operacional.

Corpo

Endereço do objeto
Tamanho dos objetos
Nome do objeto
As referências de objetos

Dump: Possui a extensão .phd. Seu tamanho é referente ao tamanho especificado no Maximum heap size no WAS.

O Java heap dump é gerado automaticamente quando existe a exaustão de uso da JVM.

Formato do arquivo Heap dump.

Windows: heapdump.YYYYMMDD.HHMMSS.PID.txt
Linux e AIX: heapdumpPID.TIME.txt
z/OS: HEAPDUMP.YYYYMMDD.HHMMSS.PID.txt

Nota: PID é o número do processo Java.

Verificando a fragmentação de objetos
Muitos problemas de Out of memory estão relacionados a falha na fragmentação de objetos mesmo possuindo espaço suficiente na JVM. Isso ocorre porque a JVM não consegue encontrar espaço contíguos no heap para alocar objetos. A solução é agrupar objetos que podem ser movidos em grupos para que eles não fragmentem um Java heap.

A partir da versão JDK 1.4.2 já é possível ajustar o tamanho destes objetos com a opção -Xk.

Para verificar o tamanho necessário, execute o comando java -jar ClassCount.jar

A saída do comando ficará da seguinte forma: set -Xk to 15528 or greater.

Ajuste esse parâmetro no Generic JVM Arguments
Application servers > server1 > Process Definition > Java Virtual Machine > Generic JVM arguments > -Xk15528

Se o problema for de fragmentação, essa pode ser a solução. Ative o “Verbose garbage collection” e acompanhe como está o uso da JVM. Caso ainda continue a gerar heap, será necessário uma análise mais detalhada no arquivo .phd.

Analisando um heapdump
Para analisar um heapdump, a ferramenta a ser utilizada é a IBM HeapAnalyzer.
Com essa ferramenta é possível carregar um arquivo phd sendo possível visualizar todos os seus objetos.

Requisitos
Java 1.5 ou 1.6

Para carregar a ferramenta execute o comando java -jar -Xmx1000m ha413.jar.

Caso receba a mensagem “java.lang.OutOfMemoryError“, aumente o tamanho do valor do heap size -Xmx.

1 – Após iniciar a ferramenta, clique em “File > Open“
2 – Procure pelo arquivo .phd.
3 – Após carregar o dump, será exibido tres janelas.
3.1 – A primeira janela mostra as propriedades do arquivo como a versão do Java, número de classes,    objetos, arrays, etc.
3.2 – Na segunda janela logo abaixo estão as referências de todos os objetos, sendo pai e filho.
3.3 – Ao lado, está a propriedade de cada objeto.

O objetivo é procurar por leaks (vazamentos) que possam estar causando o estouro de JVM. Veja que logo ao carregar o dump, já é exibido o número de leaks existentes no arquivo phd.