Análise de despejo de thread do AEM

Baixe e instale o IBM Thread Analyzer (vamos chamá-lo de IBM TDA para abreviar).

Capture despejos de thread de uma instância do AEM com problemas de desempenho.

Abra os despejos de thread no IBM TDA.

Para exibir os detalhes de um despejo de thread, selecione o arquivo na listagem e clique no botão Detalhes da Thread.

Classifique por Profundidade da Pilha com as pilhas mais longas no topo.

Revise as threads com profundidade de pilha de 10 linhas ou mais.  Normalmente, esses são os segmentos de maior interesse.

Faça observações sobre threads de interesse.

Classificar por thread Estado.

Role para baixo até as threads Executáveis. As threads executáveis são aquelas que estavam ocupando ativamente o tempo da CPU quando o despejo de thread foi obtido.

Observação: ao revisar as threads Executáveis, você pode ignorar as threads listadas na seção Threads que podem ser ignoradas na parte inferior desta página.

Encontre threads executáveis que fazem parte do aplicativo, por exemplo, threads de tarefas em segundo plano ou threads de solicitações (as threads de solicitações têm nomes como este - 127.0.0.1 [ 1347028187737] GET /content/sites/global/en/sitemap.static-delivery.httpd.html HTTP/1.1).

Depois de encontrá-las, clique nelas uma por uma.

Para cada thread de solicitação, você pode descobrir quando o navegador do usuário fez a solicitação ao servidor observando o carimbo de data e hora no nome da thread.

Por exemplo, no nome do thread acima, o carimbo de data/hora (em milissegundos no formato de época unix) é 1347028187737.

Podemos converter esse número de época em uma data/hora usando www.epochconverter.com.

Cada despejo de thread mostra a data e a hora em que ela foi tirada.

Você pode calcular a diferença no tempo entre o tempo de solicitação e o tempo de despejo de thread para ver por quanto tempo uma solicitação ficou ativa.

Depois de revisar as threads de solicitação, navegue pelas outras threads Executáveis.

Depois de encontrar um thread Executável de interesse, observe o painel do meio, Threads em espera.

O Threads listado lá está aguardando a thread selecionada liberar um monitor.

Se você não vir nenhuma thread em espera, a thread selecionada ainda poderá ser o proprietário de um Bloqueio (consulte as classes de implementação de Bloqueio para obter detalhes).

Por exemplo, com um ReentrantReadWriteLock, não é possível saber qual thread é a proprietária do bloqueio, pois os bloqueios implementam vários monitores internamente.

Portanto, talvez seja necessário examinar o código-fonte para combiná-lo com uma thread que possa ser a proprietária do bloqueio.

Se a thread tiver um bloqueio ou monitor em que muitas outras threads estavam aguardando, passe pelo restante dos despejos para ver se é possível encontrar outras threads com o mesmo problema.

Veja se a mesma thread ainda existe nos outros despejos (no IBM TDA, é possível selecionar vários despejos de thread e clicar no botão Comparar Threads para exibir o estado de uma thread em vários despejos.

Consulte o Serviço Coletor na captura de tela abaixo:

Nesta exibição, você pode ver a thread em vários despejos para ver se é uma thread de execução longa.

Basicamente, se a thread estiver no estado Executável em vários despejos e tiver uma pilha longa, isso geralmente significa que é uma thread de execução longa.

Se você não encontrou muita coisa procurando as threads Executáveis, volte para a lista de threads, selecione um despejo de thread e clique no botão Detalhes do Monitor no painel superior.

Se você capturou a saída top -H -b -n1 -p <javapid> além dos despejos de thread, é possível fazer referência cruzada à utilização da CPU no nível de thread.

Abra a saída superior e obtenha a ID do processo das threads que estão utilizando a CPU.

Converta a ID do processo em hexadecimal e procure esse valor no arquivo de despejo de thread correspondente.

A ID deve corresponder ao nid de um dos threads.

Se a thread correspondente que utiliza mais CPU for a Thread de VM ou qualquer thread GC, talvez você tenha um problema de memória.

Repita o mesmo exercício para mais despejos de thread e saída superior, e se houver um padrão em que essas threads ocupam tempo de CPU, você terá um problema de memória.

Se você confirmou o problema de memória, capture um despejo de heap na próxima vez que o problema ocorrer.

Consulte este artigo Analisar problemas de memória para obter mais detalhes sobre como capturar e analisar despejos de heap.