O processo do CRX/CQ usa 100% da CPU, o sistema não responde ou está lento
Perguntas frequentes
Quais são as situações típicas que causam alto consumo de CPU?
Determinadas atividades de manutenção podem causar um uso de CPU mais alto do que o normal: compactação de tar, coleta de lixo do armazenamento de dados, backup online, ativação de árvore, implantação de uma atualização de aplicativo que faz com que os caches sejam limpos, ...
Qual a razão para um consumo de CPU de 0%?
Um impasse do nível java pode causar tal situação. Nesse caso, faça alguns dumps de encadeamento, crie um ticket de suporte e reinicie a instância do AEM.
Há dicas de ajuste de desempenho disponíveis?
Soluções
Video gem - sessão técnica de mergulho profundo
Sessão de gem video disponível em http://dev.day.com/content/ddc/en/gems/cq-aem-5-6-troubleshooting.html
Adobe Experience Manager 5.6 ou posterior e CRX 2.3 ou posterior
Use o http://localhost:4502/system/console/profiler por pelo menos alguns minutos durante o período de lentidão ou alto uso da CPU. A saída ajuda a determinar quais encadeamentos da JVM estão consumindo a maioria dos ciclos da CPU e seus pacotes e classes associados.
Até o CRX 2.2
Use a ferramenta de criação de perfil de CPU simples incluída no CRX 2.0.x. Para iniciá-lo, abra
http://localhost:7402/crx/diagnostic/prof.jsp
CRX 1.x
Para ajudar a analisar o problema, crie alguns dumps de encadeamento completos. Esses dumps de encadeamento podem ser analisadas. Criação de dumps de encadeamento completos
Obtenha o ID do processo
Para obter o id do processo do seu processo Java, use
jps -l
Se isso não funcionar (caminho não definido, JDK não instalado ou versão mais antiga do Java), use
ps -el | grep java
Full Thread Dumps
Para analisar um problema de desempenho ou um processo bloqueado, crie cerca de dez full thread dumps com um atraso de cerca de um segundo. Se o problema está relacionado ao armazenamento em cluster, crie pelo menos dez dumps de encadeamento completos em cada nó do cluster. Se possível, os dumps de encadeamento devem ser criados aproximadamente ao mesmo tempo (não precisa ser exato).
Um dumps de encadeamento completo começa com essas informações, por exemplo:
2015-07-22 10:26:30
Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.65-b04):
"Thread-76273" daemon prio=3 tid=0x111061 nid=0x111061 running [0x111061]
... pilha e objeto bloqueado DEVE estar presente
If your thread dump doesn't look like above, then it will not be possible to make proper investigations.
É possível usar o "tool" fornecido no pacote como descrito na página. Ele fornece uma ferramenta que permite realizar vários dumps de encadeamento, ele será despejado no formato acima.
Como alterntiva, se instalado, use jstack. Este comando imprime os dumps de encadeamento no sistema:
jstack <pid>
Esse comando acrescenta um dumps de encadeamento completo para um arquivo:
jstack <pid> >> threadDumpNode1.txt
Em alguns sistemas, é possível ter que usar: sudo -u aem jstack -J-d64 -l <pid>
Se isso não funcionar, use kill -QUIT. Este comando imprime os despejos de encadeamento no arquivo de log:
kill -QUIT <pid>
Se não houver dumps de encadeamentos na saída padrão do último comando, maybe add this to the java parameters:
-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=jvm.log
Note: Se os passos acima para obter dumps de encadeamento não funcionarem no seu ambiente, consulte este artigo.
Verifique o uso da CPU
Para analisar o problema, é importante saber se o CRX /CQ está sendo executado em um loop infinito ou se está apenas dormindo. Para descobrir, digite
top
Este comando obtém a lista de processos, classificados por uso da CPU. Se o processo principal for um "Java" e se o PID corresponder ao CRX / CQ, o processo estará em alta velocidade.
Se não houver certeza de como interpretar os resultados, execute a seguinte instrução e inclua o arquivo top.txt em seu relatório de problemas:
top -l5 -s5 > top.txt
Verificar contagem de sessão
Em muitos casos, o problema é o número grande de sessões abertas. Em algum momento, isso retarda o processamento. Para descobrir se esse é o caso, execute
jps -l (para obter o id do processo Java)
jmap -histo <pid> | grep CRXSession (para obter o número de sessões abertas)
Se isto é, de fato, o problema (o número é maior do que algumas centenas de sessões), então ele precisa ser analisado. Possivelmente, um conjunto de sessões é utilizado (dependendo da versão do CRX / CQ, pode haver um hotfix para o problema especificado) ou um cache interno (provavelmente no nível do aplicativo) que referencia as sessões. Para analisar onde essas sessões são abertas, consulte a página "Analisar Sessões Não Fechadas".
Não interrompa o processo
O processo de CRX nunca deve ser interrompido, nem mesmo quando a parada demora muito. Se houver necessidade de interromper um processo que não está respondendo, crie um dump de encadeamento completo primeiro e registre um erro.
Se o processo CRX é interrompido, crie os arquivos backup_.tar na próxima vez que o PM Tar for iniciado.
Ferramentas de suporte
Use a Thread Dump Collection and Analysis tool para obter os dumps de encadeamentos de uma instância CQ em execução para solução de problemas do seguinte:
- desempenho
- contenção de bloqueio
- impasse
- outros problemas relacionados ao encadeamento
Fazer logon em sua conta