Solução de problemas de índices do Oak troubleshooting-oak-indexes

CAUTION
AEM 6.4 chegou ao fim do suporte estendido e esta documentação não é mais atualizada. Para obter mais detalhes, consulte nossa períodos de assistência técnica. Encontre as versões compatíveis here.

Reindexação lenta slow-re-indexing

AEM processo interno de reindexação coleta dados do repositório e os armazena em índices Oak para oferecer suporte à consulta de conteúdo executante. Em circunstâncias excepcionais, o processo pode ficar lento ou mesmo travado. Esta página atua como um guia de solução de problemas para ajudar a identificar se a indexação está lenta, localizar a causa e resolver o problema.

É importante distinguir entre reindexação que leva um tempo inadequadamente longo e reindexação que leva um longo período porque indexa grandes quantidades de conteúdo. Por exemplo, o tempo necessário para indexar escalas de conteúdo com a quantidade de conteúdo, de modo que repositórios de produção grandes levarão mais tempo para reindexar do que repositórios de desenvolvimento pequenos.

Consulte a Práticas recomendadas em consultas e indexação para obter mais informações sobre quando e como reindexar o conteúdo.

Detecção inicial initial-detection

A indexação lenta da detecção inicial requer a revisão da IndexStats MBeans JMX. Na instância de AEM afetada, faça o seguinte:

  1. Abra o Console da Web e clique na guia JMX ou acesse https://<host>:<port>/system/console/jmx (por exemplo, http://localhost:4502/system/console/jmx).

  2. Navegue até o IndexStats Feijão.

  3. Abra o IndexStats MBeans para " async" e " fulltext-async".

  4. Para ambos os MBeans, verifique se a variável Concluído timestamp e LastIndexTime o carimbo de data e hora está a menos de 45 minutos da hora atual.

  5. Para MBean, se o valor de tempo (Concluído ou LastIndexedTime) é maior que 45 minutos a partir do momento atual, então o trabalho de índice está falhando ou demorando muito. Isso faz com que os índices assíncronos sejam obsoletos.

A indexação é pausada após um desligamento forçado indexing-is-paused-after-a-forced-shutdown

Um desligamento forçado resulta em AEM suspensão da indexação assíncrona por até 30 minutos após a reinicialização e normalmente requer mais 15 minutos para concluir a primeira passagem de reindexação, por um total de aproximadamente 45 minutos (ligando de volta ao Detecção inicial período de 45 minutos). Caso suspeite que a indexação esteja pausada após um desligamento forçado:

  1. Em primeiro lugar, determine se a instância de AEM foi encerrada de forma forçada (o processo de AEM foi violado com força, ou ocorreu uma falha de energia) e, em seguida, reiniciada.

  2. Se o desligamento forçado tiver ocorrido, após a reinicialização, o AEM suspende automaticamente a reindexação por até 30 minutos.

  3. Aguarde aproximadamente 45 minutos para AEM retomar as operações normais de indexação assíncrona.

Pool de threads sobrecarregado thread-pool-overloaded

NOTE
Para o AEM 6.1, verifique se AEM 6.1 CFP 11 está instalado.

Em circunstâncias excepcionais, o pool de threads usado para gerenciar a indexação assíncrona pode ficar sobrecarregado. Para isolar o processo de indexação, um conjunto de threads pode ser configurado para impedir que outros AEM trabalho interfiram com a capacidade do Oak de indexar o conteúdo em tempo hábil. Para fazer isso, você deve:

  1. Defina um novo conjunto de encadeamentos isolado para que o Apache Sling Scheduler use para indexação assíncrona:

    • Na instância de AEM afetada, navegue até AEM console da Web OSGi>OSGi>Configuração>Apache Sling Scheduler ou acesse https://<host>:<port>/system/console/configMgr (por exemplo, http://localhost:4502/system/console/configMgr)
    • Adicione uma entrada ao campo "Pools de Threads Permitidos" com o valor de "oak".
    • Clique em Salvar na parte inferior direita para salvar as alterações.

    chlimage_1-119

  2. Verifique se o novo conjunto de encadeamentos do Apache Sling Scheduler está registrado e é exibido no console da Web Apache Sling Scheduler Status .

    • Navegue até AEM console da Web OSGi>Status>Sling Scheduler ou acesse https://<host>:<port>/system/console/status-slingscheduler (por exemplo, http://localhost:4502/system/console/status-slingscheduler)

    • Verifique se as seguintes entradas de pool existem:

      • ApacheSlingoak
      • ApacheSlingdefault

    chlimage_1-120

A fila de observação está cheia observation-queue-is-full

Se muitas alterações e compromissos forem feitas no repositório em um curto período, a indexação pode ser atrasada devido a uma fila de observação completa. Primeiro, determine se a fila de observação está cheia:

  1. Vá para o Console da Web e clique na guia JMX ou vá para https://<host>:<port>/system/console/jmx (por exemplo, http://localhost:4502/system/console/jmx)

  2. Abra o MBean de estatísticas do repositório do Oak e determine se existe algum ObservationQueueMaxLength for maior que 10.000.

    • Em operações normais, esse valor máximo sempre deve reduzir para zero (especialmente no per second (seção) para verificar se a variável ObservationQueueMaxLengthAs métricas de segundos da são 0.
    • Se os valores forem 10.000 ou mais e aumentarem continuamente, isso indica que pelo menos uma (possivelmente mais) fila não poderá ser processada tão rápido quanto novas alterações (commits) ocorrerem.
    • Cada fila de observação tem um limite (10.000 por padrão) e se a fila atingir esse limite, seu processamento será degradado.
    • Ao usar o MongoMK, à medida que os comprimentos da fila aumentam, o desempenho interno do cache do Oak diminui. Esta correlação pode ser vista em um aumento de missRate para DocChildren no Consolidated Cache estatísticas MBean.
  3. Para evitar exceder os limites aceitáveis da fila de observação, recomenda-se:

Identificação e correção de um processo de reindexação travado identifying-and-remediating-a-stuck-re-indexing-process

A reindexação pode ser considerada como "completamente presa" sob duas condições:

  • A reindexação é muito lenta, até o ponto em que nenhum progresso significativo é relatado nos arquivos de log em relação ao número de nós atravessados.

    • Por exemplo, se não houver mensagens ao longo de uma hora, ou se o progresso for tão lento que levará uma semana ou mais para ser concluído.
  • A reindexação fica presa em um loop infinito se exceções repetidas aparecerem nos arquivos de log (por exemplo, OutOfMemoryException) no thread de indexação. A repetição das mesmas exceções no log indica que o Oak tenta indexar a mesma coisa repetidamente, mas falha no mesmo problema.

Para identificar e corrigir um processo de reindexação travado, faça o seguinte:

  1. Para identificar a causa da indexação paralisada, as seguintes informações devem ser coletadas:

  2. Depois de coletar todas as informações descritas na Etapa 1, reinicie o AEM.

    • Reiniciar AEM pode resolver o problema em caso de alta carga simultânea (estouro da fila de observação ou similar).
    • Se uma reinicialização não resolver o problema, abra um problema com Atendimento ao cliente do Adobe e fornecer todas as informações coletadas na Etapa 1.

Interromper com segurança a reindexação assíncrona safely-aborting-asynchronous-re-indexing

A reindexação pode ser abortada com segurança (interrompida antes de ser concluída) por meio do async, async-reindexe f ulltext-async vias de indexação ( IndexStats Feijão). Para obter mais informações, consulte também a documentação do Apache Oak em Como abortar a reindexação. Além disso, ter em conta que:

  • A reindexação dos Índices de Propriedades Lucene e Lucene pode ser abortada, pois são naturalmente assíncronas.
  • A reindexação de índices de propriedades do Oak só pode ser abortada se a reindexação tiver sido iniciada por meio do PropertyIndexAsyncReindexMBean.

Para interromper a reindexação com segurança, siga estas etapas:

  1. Identifique o MBean IndexStats que controla a faixa de reindexação que precisa ser interrompida.

    • Navegue até o IndexStats MBean apropriado por meio do console JMX, acessando AEM console da Web OSGi>Main>JMX ou https://<host>:<port>/system/console/jmx (por exemplo, http://localhost:4502/system/console/jmx)

    • Abra o IndexStats MBean baseado na faixa de reindexação que você deseja parar ( async, async-reindexou fulltext-async)

      • Para identificar a faixa apropriada e, portanto, a instância MBean IndexStats, verifique a propriedade "async" dos Índices Oak. A propriedade "async" conterá o nome da faixa: async, async-reindexou fulltext-async.
      • A faixa também está disponível acessando AEM Gerenciador de Índice na coluna "Assíncrono". Para acessar o Gerenciador de índice, navegue até Operations>Diagnosis>Index Manager.

    chlimage_1-121

  2. Chame o abortAndPause() no comando adequado IndexStats MBean.

  3. Marque a definição do índice Oak apropriadamente para impedir a reindexação quando a faixa de indexação for retomada.

    • Ao reindexar um existente , defina a propriedade reindex como false

      • /oak:index/someExistingIndex@reindex=false
    • Ou senão, para um novo índice:

      • Defina a propriedade type como disabled

        • /oak:index/someNewIndex@type=disabled
      • ou remover a definição de índice totalmente

    Confirme as alterações no repositório ao concluir.

  4. Finalmente, retome a indexação assíncrona na faixa de indexação abortada.

    • No IndexStats MBean que emitiu o abortAndPause() na Etapa 2, chame o resume()comando.

Impedindo a reindexação lenta preventing-slow-re-indexing

É melhor reindexar durante períodos silenciosos (por exemplo, não durante uma assimilação de conteúdo grande) e idealmente durante janelas de manutenção quando AEM carga é conhecida e controlada. Além disso, assegure-se de que a reindexação não ocorra durante outras atividades de manutenção.

recommendation-more-help
6a71a83d-c2e0-4ce7-a6aa-899aa3885b56