Como analisar problemas comuns e críticos do AEM

Saiba mais sobre os problemas críticos mais comuns do AEM e como analisá-los.

Descrição description

Ambiente

Adobe Experience Manager (AEM)

Problema

Este artigo descreve os problemas mais comuns relacionados ao AEM e como analisá-los.

  • Desempenho do AEM Sites
  • Desempenho do AEM Assets
  • Problemas de memória
  • Problemas de indexação
  • Problemas de replicação
  • Problemas de corrupção do TarMK

Resolução resolution

Problemas de desempenho do AEM Sites

Sintomas de um problema de desempenho

  1. Carregamento lento de páginas
  2. Criação ou edição lenta de páginas
  3. Os tempos de resposta do AEM são lentos
  4. O AEM não está respondendo a algumas solicitações
  5. O request.log no AEM mostra tempos de resposta lentos

O que causa problemas de desempenho

  1. Contenção de segmentos - solicitações de longa duração, como pesquisas lentas, tarefas em segundo plano com muita gravação, movimentação de ramificações inteiras do conteúdo do site etc.
  2. Alta utilização da CPU
  3. Solicitações caras, como pesquisas caras ou código de aplicativo, componentes etc. ineficientes.
  4. Falta de manutenção adequada
  5. Armazenamento em cache insuficiente do dispatcher
  6. Falta de CDN
  7. Falta de armazenamento em cache do navegador
  8. Muitos scripts carregados na página e na parte superior da página
  9. CSS carregado pela página em vez de no cabeçalho de HTML
  10. Dimensionamento insuficiente do servidor ou arquitetura incorreta
  11. Problemas de memória (veja abaixo)

Como analisar o problema de desempenho

  1. Capture uma série de despejos de thread e analise-os.

  2. Verifique no nível do SO se o processo java do AEM está causando alta utilização da CPU:        Se o AEM estiver causando alta utilização da CPU, execute a ferramenta de criação de perfil pronta para uso por alguns minutos e analise o resultado.

    • Linux: use o comando top para verificar a utilização da CPU.
    • Janela: use o Gerenciador de tarefas do Windows
  3. Analise o arquivo request.log para qualquer solicitação lenta.

  4. Revise os procedimentos de manutenção do sistema. Consulte este artigo para obter detalhes sobre a manutenção do AEM e garantir que você esteja fazendo a manutenção adequada do AEM, incluindo:

    • Limpeza de revisão (somente no MongoMK e no Database DocumentNodeStore) - diária ou mais frequente
    • Compactação Tar offline (somente TarMK) - quinzenal
    • Coleta de lixo do armazenamento de dados (sistemas somente com FileDataStore ou S3 DataStore) - semanalmente
    • Expurgação do Workflow - semanal
    • Limpeza de versão - semanal
    • Limpeza do AuditLog - semanal
  5. Revise as estratégias de armazenamento em cache implementadas no nível do dispatcher AEM.

  6. Revise o armazenamento em cache do seu site.

  7. Use as ferramentas de análise do site do cliente, como o recurso Auditorias, no painel Ferramentas do Desenvolvedor do navegador Google Chrome.  Essas ferramentas fornecerão recomendações sobre melhorias de desempenho do lado do cliente.

Soluções para problemas comuns de desempenho

Problemas de desempenho do Assets

Sintomas de um problema de desempenho do Assets

  • Uploads lentos de arquivo para /assets.html ou interface do usuário /damadmin
  • As miniaturas estão demorando muito para serem geradas
  • As operações do Assets, como mover, excluir, editar e atualizar metadados, demoram muito

O que causa problemas com o desempenho do Assets

  • Falta de manutenção adequada
  • Pacotes de correção mais recentes não aplicados
  • Otimizações não aplicadas
  • Dimensionamento inadequado do servidor para a carga do usuário

Como analisar o problema de desempenho do Assets

Soluções para problemas comuns de desempenho do Assets

Problemas de memória


Sintomas de um problema de memória

  • O AEM trava aleatoriamente e, nos registros, é observado OutOfMemoryError
  • AEM fica mais lento com o tempo e eventualmente cai
  • O AEM não responde

Diagnosticando um problema de memória

  • Procure nos arquivos de log por OutOfMemoryError. Se você encontrar alguma correspondência, você terá um problema de memória

  • Revise a tela http://aem-host:port/system/console/memoryusage

    Se o uso da "Geração antiga" (JDK 7 e anterior) ou "Geração com Garantia" (JDK 8 ou posterior) estiver alto, isso pode ser um sinal de um problema de uso de memória de heap.  Clique em "Executar Coletor de Lixo" para solicitar que a JVM execute uma coleta de lixo de heap completo.  Se a alta utilização de heap permanecer alta depois de solicitar o GC, provavelmente há um problema.  Em uma instância do AEM com armazenamento Oak Tar, se o uso garantido for superior a 3 GB, poderá haver um problema.  A alta utilização de heap em um sistema com armazenamento Mongo pode ser devido à configuração do cache na memória.

  • Faça despejos de thread e saída superior e execute a análise de thread.  Verifique se as threads que estão causando alta utilização da CPU são threads nativos de Coleta de Lixo da JVM.  Se a thread que está usando o maior tempo de CPU for a "Thread de VM" ou qualquer thread de coleta de lixo, provavelmente haverá um problema de memória.

O que causa problemas de memória

  • Vazamento de memória do aplicativo Java
  • O Java Finalizer se acumula devido ao uso incorreto da finalização no código personalizado
  • Configuração máxima de heap insuficiente

Como analisar a causa do problema de memória

Consulte este artigo para obter detalhes sobre como capturar um despejo de heap.

A melhor maneira de identificar a causa de um problema de memória é analisar um despejo de heap.

Depois de capturar um arquivo de despejo de heap, abra-o na ferramenta Eclipse MAT ou IBM Memory Analyzer.  No Eclipse MAT, execute o relatório Leak Suspects e abra a visualização "Thread Details" para ver as possíveis causas do problema de memória.

Soluções para problemas comuns de memória

  • Otimize o código do aplicativo para utilizar menos memória se notar longas pausas na coleta de lixo.  A maioria dos problemas da Coleta de Lixo pode ser melhor resolvida por meio da otimização da aplicação, em vez do ajuste da JVM.
  • Se você já tiver otimizado seu aplicativo e ainda experimentar longas pausas de GC, concentre-se em ajustar a JVM.

Problema de indexação do AEM


Sintomas de problemas de indexação

Veja a seguir sinais de um problema com a indexação do AEM/Oak:

  • Os resultados da pesquisa estão desatualizados em mais de 10 minutos
  • Faltam resultados de pesquisa
  • Os erros são retornados na interface ou nos logs durante a pesquisa por meio da interface do usuário do site, da pesquisa do Construtor de consultas ou da execução de consultas JCR

Diagnosticando um problema de indexação
Para ver se a indexação assíncrona está lenta ou falhando, faça o seguinte:

  1. Abra esses URLs na instância do AEM para exibir estatísticas sobre o indexador assíncrono: http://aemhost:port/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dasync%2Ctype%3DIndexStats http://aemhost:port/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dfulltext-async%2Ctype%3DIndexStats  - Este URL se aplica somente ao AEM 6.2 e versões posteriores

  2. Em cada uma dessas páginas, verifique estes campos:

    FailedSince - Indica quando a indexação começou a falhar pela primeira vez.

    LastError - Este é o rastreamento de pilha que mostra o que está causando a falha da indexação.  Se estiver vazio, a indexação não falhará.

    LastErrorTime - Indica a última vez que a indexação lançou o erro.

    LastIndexedTime - Se a data e a hora deste campo tiverem mais de 5 minutos, a indexação estará muito lenta.

O que causa problemas com a indexação

  • Manutenção incorreta ou falha na execução da manutenção, como Coleta de Lixo de Revisão, Expurgação de Workflow, Expurgação de Auditoria, Expurgação de Versão etc.
  • Segmentos corrompidos ou ausentes no armazenamento TAR
  • Corrupção de revisão em um ambiente clusterizado (DocumentNodeStore - Mongo ou Database)
  • Um problema com a topologia de cluster em um ambiente em cluster

Como analisar o que está causando problemas de indexação

  • Consulte este artigo para analisar e corrigir problemas de indexação

Problemas de replicação


Sintomas de problemas de replicação

  • As solicitações do Publish estão na fila do agente de replicação
  • O conteúdo publicado não é exibido no servidor de publicação
  • Impacto no desempenho do sistema

O que causa problemas de Replicação:

  • O agente de replicação está configurado incorretamente e não pode se conectar ao agente de publicação
  • Há um erro no momento da replicação que causa o travamento da fila de replicação
  • O sistema está lento e as replicações estão sendo processadas lentamente
  • A replicação está acontecendo como parte de um fluxo de trabalho personalizado e o problema está no processamento do fluxo de trabalho.

Como analisar problemas de Replicação:

  1. Verifique a fila de replicação status:

    Ativo: quando os itens estão sendo processados.

    Ocioso: quando a fila está vazia.

    Bloqueado: quando itens estão na fila, mas não podem ser processados; por exemplo, quando o agente aponta para um host inativo ou inexistente.

  2. Revise as configurações de replicação se o servidor estiver clonado ou se o agente tiver sido configurado recentemente. Para obter detalhes, consulte aqui.

  3. Examine os logs do agente de replicação em http://host:port/etc/replication/agents.author/AgentName.log.html#end.  Se você não conseguir identificar itens que coletam esse log e os apresentam ao suporte para AEM.

  4. Revise o error.log do servidor em AEMinstall/crx-quickstart/logs; Se você não conseguir identificar nenhum item, colete esse log e apresente ao suporte para AEM.

  5. Se a fila de replicação estiver no estado "ocioso" e nenhuma das opções acima se aplicar, nesse caso, o problema provavelmente será causado pelos workflows. Se os workflows não estiverem sendo processados, o item de replicação nunca chegará à fila de replicação. Para monitorar o status dos workflows, você pode verificar o painel do workflow para verificar o número de instâncias de workflow em execução. Você pode ler sobre como administrar fluxos de trabalho aqui.

  6. A replicação fica lenta quando o sistema está sobrecarregado ou apresenta outros problemas de desempenho.

Solução para problemas comuns de replicação:

  1. Revise os problemas da fila de replicação.
  2. Se o problema se deve ao fato de os fluxos de trabalho não funcionarem de forma eficiente, você poderá revisar as dicas de processamento do fluxo de trabalho simultâneas.

Problemas de corrupção de TarMK


Sintomas de corrupção de TarMK

  • A instância está inoperante após a compactação offline.
  • Instância presa no estado Inicialização em andamento.
  • Arquivos de log ou saída de comando de compactação SegmentNotFoundException.

O que causa problemas de corrupção

  • O segmento é removido por intervenção manual (por exemplo, rm -rf ).
  • O segmento é removido pela coleção de lixo de revisão ou o segmento não pode ser encontrado devido a algum erro no código.
  • O segmento não pode ser encontrado devido a algum erro no código.
  • Várias tarefas de manutenção não são executadas a tempo, resultando no crescimento do repositório e no baixo espaço em disco.
  • Interromper o AEM à força matando o processo java.

Diagnosticando problemas de corrupção de repositório:

  • Revise o arquivo error.log e verifique se há SegmentNotFoundException ou IllegalArgument Exception.
  • Para determinar se um segmento foi removido pela coleção de lixo de revisão,  verifique a saída do logger org.apache.jackrabbit.oak.plugins.segment.file.TarReader-GC (enable debug log). Esse agente de log registra as IDs de segmento de todos os segmentos removidos pela fase de limpeza. Somente quando a id de segmento incorreta aparece na saída desse agente é que a coleta de lixo de revisão é a causa da exceção.
  • Em caso de corrupção no armazenamento de dados externo, o arquivo de log de pesquisa para todas as ocorrências do erro Ocorreu um erro ao obter InputStream para blobId. Esse erro significa que estão faltando arquivos no diretório de armazenamento de dados AEM.

Solução para reparar problemas de corrupção:

  • Determine a última revisão válida do armazenamento de segmentos usando o modo de execução check de oak-run.  Reverta manualmente o armazenamento de segmento corrompido para sua última revisão válida. Essa operação reverterá o repositório do Oak para um estado anterior no tempo.  Você deve fazer backup completo do repositório antes de executar essa operação.

    • Para executar a verificação e restauração, siga as etapas mencionadas em este artigo.
    • Se a verificação falhar com ConsistencyChecker - Nenhuma revisão válida encontrada, implemente as etapas da parte B de este artigo.
  • Se você não estiver usando um armazenamento de dados, use um arquivo externo, o armazenamento de dados S3 ou do Azure, em vez do armazenamento de segmentos padrão.

    • O uso de um armazenamento de dados oferece melhor desempenho.
    • Migre a instância para uma com um armazenamento de dados usando crx2oak.
  • Aplique o Service Pack e o Cumulative Fix Pack mais recentes e o Oak Cumulative Fix Pack.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f