Objetivo

Analisar os despejos de threads do AEM Java com a ferramenta IBM Thread Analyzer.

Etapas

  1. Baixar e instalar o IBM Thread Analyzer (vamos chamá-lo de IBM TDA para encurtar)
  2. Capturar despejos de threads de uma instância do AEM com problemas de desempenho.
  3. Abra os despejos de thread no IBM TDA.
  4. Para visualizar os detalhes de um despejo de thread, selecione o arquivo na listagem e clique no botão "Detalhes do thread" *.
tda-threaddetail
  1. Classifique por "Profundidade da pilha" com as pilhas mais longas no topo.
tda-image1
  1. Revise os threads com uma profundidade de pilha de 10 linhas ou mais.  Esses são geralmente os threads de maior interesse.  Tome notas sobre threads que são de interesse.
  2. Ordenar por "Estado" do thread
  3. Role para baixo até os threads "Executáveis". Os threads executáveis são aqueles que estavam ocupando ativamente o tempo da CPU quando o despejo ocorreu.

Nota: ao revisar os threads "Executáveis", é possível ignorar os threads listados na seção Threads que podem ser ignorados na parte inferior desta página.

  1. Localize threads executáveis que fazem parte do aplicativo, por exemplo, threads de tarefas em segundo plano ou de solicitação (os threads de solicitação 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á-los, clique neles um por um.
  2. Em cada thread de solicitação, é possível descobrir quando o navegador do usuário fez a solicitação ao servidor observando o registro de data e hora no nome do thread.  Por exemplo, no nome do thread acima, o registro de data e hora (em milissegundos no formato de época unix) é 1347028187737.  Podemos converter esse número de época em uma data/hora usando o www.epochconverter.com.  Cada despejo de thread mostra a data e a hora em que foi tirado.  Calcule a diferença entre o tempo de solicitação e o tempo de despejo do thread para ver por quanto tempo uma solicitação ficou ativa.
  3. Depois de revisar os threads de solicitação, role pelos outros threads "Executáveis".  Depois de encontrar um thread de interesse "Executável", olhe para o painel do meio, "Threads em espera".  Os threads listados lá estão aguardando a liberação de um monitor pelo thread selecionado.  Se não houver threads em espera, o thread selecionado ainda pode ser o proprietário de um Bloqueio (veja as classes de implementação de Bloqueio para 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.  Por isso, pode ser necessário verificar o código-fonte para combiná-lo com um thread que possa ser o proprietário do bloqueio.
  4. Se o thread tiver um bloqueio ou monitor aguardado por muitos outros threads, percorra o 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, é possível selecionar vários despejos de threads e clicar no botão "Comparar threads" * para visualizar o estado de um thread em vários despejos.
tda-comparethreads
  1. Veja o Collector Service na captura de tela abaixo:
tda-Image2
  1. Nesta exibição, você pode ver o thread em vários despejos para ver se é um thread de longa execução.  Basicamente, se o thread estiver no estado Executável em vários despejos e tiver uma pilha longa, isso geralmente significa que é um thread de execução longa.
  2. Se você não encontrou muita coisa procurando os threads executáveis, volte à lista de threads, selecione um despejo e clique no botão "Detalhes do monitor" * no painel superior. O IBM TDA abrirá uma janela mostrando uma visualização em árvore do monitor que possui threads e dos threads em espera. Nota: ele pode exibir alguns threads de pool, como o monitor do pool de threads do mecanismo de servlet. Threads inativos podem ser ignorados.  Você pode geralmente dizer que é um thread de pool de thread ocioso porque, na maioria das vezes, ele tem apenas 10 linhas de pilha ou menos.
tda-monitordetail
 
Utilização de CPU no nível do thread (somente na plataforma Linux):
  1. Se você capturou a saída "top -H -b -n1 -p <javapid> " além de despejos de threads, pode fazer referência cruzada à utilização da CPU no nível do thread.  Abra a saída superior e obtenha o ID do processo dos threads que estão utilizando a CPU.  Converta o ID do processo em hexadecimal e procure esse valor no arquivo de despejo de thread correspondente.  O ID deve corresponder ao "nid" de um dos threads.
  2. Se o thread correspondente utilizando a maior parte da CPU for o "VM Thread" ou qualquer thread "GC", você poderá ter um problema de memória.  Repita o mesmo exercício para mais despejos de thread e saída superior. Se houver um padrão desses threads que ocupam tempo de CPU, você tem um problema de memória.
  3. Se você confirmar o problema de memória, capture um despejo de heap na próxima vez em que o problema ocorrer.  Consulte este artigo para obter mais detalhes sobre como capturar e analisar despejos de heap.

Threads que podem ser ignorados:

  • VM Thread: este é um thread do sistema VM.
  • Threads iniciando com o thread da tarefa do GC: esses são os threads da coleta de lixo.
  • Threads com nomes semelhantes a - [1347028691218] no código em java.net.PlainSocketImpl.socketAccept (Método Nativo): são threads do pool de threads do mecanismo de servlet que aguardam novas conexões.

Esta obra está licenciada sob uma licença não adaptada da Creative Commons Attribution-Noncommercial-Share Alike 3.0  As publicações do Twitter™ e do Facebook não são cobertas pelos termos do Creative Commons.

Avisos legais   |   Política de privacidade online