Análise de despejo de thread do AEM

Descrição

Ambiente

Adobe Experience Manager

Problema

Analise AEM despejos de threads Java usando IBM Thread Analyzer ferramenta e práticas recomendadas.

Resolução

Siga estas etapas e práticas recomendadas para Analisar AEM despejos de threads Java usando IBM Thread Analyzer ferramenta:

1. Baixe e instale o Analisador de thread da IBM (vamos chamá-lo de IBM TDA para abreviar).

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

3. Abra os despejos de thread no IBM TDA.

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

   

5. Classificar por Profundidade da pilha com as pilhas mais longas no topo.

   

6. Revise as threads com profundidade de pilha de 10 linhas ou mais.  Geralmente são as threads de maior interesse.

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

7. Classificar por thread Estado.

8. Role para baixo até a Executável threads. 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 a Executável threads, você pode ignorar os threads listados no Threads que podem ser ignorados na parte inferior desta página.

9. Encontre encadeamentos executáveis que fazem parte do aplicativo, por exemplo, encadeamentos de tarefas em segundo plano ou encadeamentos de solicitações (os encadeamentos 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.

10. 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 e 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.

11. Depois de revisar os encadeamentos da solicitação, role pelo outro Executável threads.

    Depois de encontrar um thread de interesse Executável, olhe para o painel do meio, Aguardando threads.

    As threads listadas lá estão esperando 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 é o proprietário 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.

12. Se o thread tiver um bloqueio ou monitor em que muitos outros threads estavam aguardando, passe pelo restante dos despejos para ver se é possível encontrar outros threads que tenham o mesmo problema.

    Veja se o mesmo thread ainda existe nos outros despejos (no IBM TDA, você pode selecionar vários despejos de thread e clicar no botão Comparar threads para exibir o estado de um thread em vários despejos de thread.

    

13. Consulte a Serviço de Coletor na captura de tela abaixo:

    

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

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

15. Se você não encontrou muita coisa olhando para o Executável threads, retorne à listagem de threads, selecione um despejo de thread e clique em Detalhes do monitor no painel superior.

O IBM TDA abrirá uma janela mostrando uma visualização em árvore do monitor que possui threads e suas threads em espera.

Observação: Ele pode exibir alguns threads de pool de threads, como o monitor de pool de threads do mecanismo de servlet, os threads ociosos podem ser ignorados.

Você geralmente pode dizer que uma thread é uma thread de pool de thread ociosa porque na maioria das vezes ela tem apenas 10 linhas de pilha ou menos.

Utilização da CPU no nível do thread (somente na plataforma Linux):

1. Se você tiver capturado top -H -b -n1 -p javapid além dos despejos de thread, você pode fazer referência cruzada da utilização da CPU no nível do thread.

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

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

   O ID deve corresponder ao nid de um dos threads.

2. Se o thread correspondente que utiliza a maior parte da CPU for o Thread de VM ou GC threads então você pode ter um problema de memória.

   Repita o mesmo exercício para mais despejos de encadeamento e saída superior. Se houver um padrão desses encadeamentos levando tempo da CPU, você terá um problema de memória.

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

   Veja isso Artigo Analisar problemas de memória para obter mais detalhes sobre como capturar e analisar despejos de heap.

Threads que podem ser ignoradas:

• Thread de VM: é uma thread do sistema de VM.
• Threads que começam com a thread de tarefa de GC: são threads de coleta de lixo.
• Threads com nomes semelhantes a - 1347028691218 in code at java.net.PlainSocketImpl.socketAccept(Native Method): Esses são threads do pool de threads do mecanismo de servlet aguardando novas conexões.

Recursos do Business.Adobe.com