DocumentaçãoKCS da Experience Cloud

Instabilidade do autor do AEM e latência grave causadas por desempenho inadequado do armazenamento de dados EBS (AMS)

Última atualização: 24 de julho de 2026

Este artigo descreve a degradação recorrente do desempenho e a instabilidade em instâncias do AEM Author hospedadas no Adobe Managed Services (AMS), onde o tipo de volume EBS subjacente não atende aos requisitos de E/S do repositório TarMK da AEM.

Descrição description

Ambiente

Implantações do Adobe Experience Manager usando repositórios TarMK no Adobe Managed Services (AMS) apoiados pelo armazenamento Amazon EBS.

Problema/Sintomas

A instância do Autor do AEM apresenta instabilidade recorrente em cargas de trabalho de criação normais, incluindo um ou mais dos seguintes itens:

  • Latência grave na interface do autor, com tempos de resposta de um minuto ou mais para solicitações padrão do editor, shell e token CSRF.
  • 504 tempos limite de gateway e erros 404 relatados pelos autores.
  • Operações de publicação falhadas ou significativamente atrasadas.
  • Processamento de evento DAM remoto atrasado e bloqueado.

Os seguintes avisos e erros podem aparecer em error.log durante ou após períodos degradados:

*WARN* [ sling-oak-N-org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate-async]
org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler
Failed to create checkpoint <uuid> in 10 seconds.

*WARN* [ oak-lucene-N]
org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory
Couldn't compute safe timestamp to delete files from NIOFSDirectory@/mnt/crx/.../index/.../data

*WARN* [ oak-lucene-N]
org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopier
File <segment> doesn't exist in /mnt/crx/.../repository/index/.../data

*WARN* [ sling-default-N-Registered Service.NNNNN]
com.adobe.cq.remotedam.internal.lifecycle.event.consumer.impl.LifecycleEventConsumerImpl
This sites instance is lagging far too behind Remote DAM. Pulling events is blocked

A correlação de request.log com esses períodos geralmente revela clusters de solicitações concluídas após 30 segundos a vários minutos entre pontos de extremidade de verificação de integridade, editor, pulso e token CSRF simultaneamente. Esse padrão indica uma paralisação em todo o JVM em vez de uma única solicitação lenta.

Causa

O repositório TarMK da AEM, armazenado em /mnt/crx, executa operações de E/S sequenciais e aleatórias frequentes para gravações do armazenamento de segmentos, criação de pontos de verificação, atualizações de índice Lucene e compactação. Essas cargas de trabalho de repositório exigem latência de armazenamento consistente e IOPS suficiente.

Os volumes EBS magnéticos padrão podem não fornecer características de desempenho adequadas para essas cargas de trabalho. Quando o throughput do armazenamento se torna restrito, o sistema operacional pode experimentar uma espera sustentada de E/S, fazendo com que vários pools de threads da JVM travem simultaneamente e resultando em uma ampla latência de aplicativos em solicitações não relacionadas.

Esse problema é observado com mais frequência em ambientes AMS de não produção que foram originalmente provisionados com volumes EBS magnéticos antes de os volumes EBS gp3 se tornarem a opção padrão de armazenamento de repositório. Os ambientes de produção geralmente não são afetados porque foram provisionados no armazenamento gp3 ou depois migrados para ele.

Resolução resolution

Para identificar e resolver problemas recorrentes de instabilidade, latência grave e desempenho do repositório do AEM Author, siga estas etapas:

  1. Verifique o tipo de volume EBS do Amazon /mnt/crx na instância de Autor afetada. Entre em contato com o engenheiro de sucesso do cliente (CSE) para confirmar a configuração do volume e determinar se o repositório está hospedado em um volume GP3 EBS.
  2. Avaliar uma migração para um volume EBS gp3 se o repositório estiver hospedado no armazenamento magnético padrão. Analise quaisquer considerações de serviço ou custo com seu CSE com base em seu contrato AMS.
  3. Solicite uma migração de armazenamento por meio do CSE. Coordene com a equipe de infraestrutura do AMS para criar o plano de migração e confirmar as configurações de IOPS e taxa de transferência de destino com base no tamanho do repositório e nos requisitos de carga de trabalho.
  4. Migre o volume do repositório para um volume EBS gp3. A equipe de infraestrutura do AMS normalmente executa esse processo interrompendo a instância do AEM, criando um instantâneo do volume existente, migrando o armazenamento e reiniciando a instância.
  5. Inclua as instâncias do Editor afetadas no plano de migração se elas usarem a mesma configuração de armazenamento.
  6. Meça o desempenho do sistema após a migração. Verifique se a espera de E/S, o uso da troca e a média de carga diminuíram durante a atividade de criação típica.
  7. Revise request.log e confirme se os pontos de extremidade do editor e do utilitário não exibem mais tempos de resposta de vários segundos ou minutos.
  8. Revise error.log e verifique se as mensagens de falha do ponto de verificação e os avisos do índice Lucene não se repetem.
  9. Valide se o editor de página do autor é carregado normalmente, as operações de publicação são concluídas com êxito, a indexação assíncrona permanece atual e os eventos do DAM remoto são processados sem atraso.
  10. Correlacione a degradação recorrente do desempenho com atividades de repositório intensivo, como grandes picos de replicação, implantações de MSM, implantações de pacotes ou assimilação de ativos em grande escala, se a instabilidade persistir após a migração.
  11. Ajuste a programação ou a limitação de cargas de trabalho de alto impacto quando o pico de demanda do repositório continuar a afetar o desempenho.
recommendation-more-help
experience-cloud-kcs-help-kbarticles