Inestabilidad del autor de AEM y latencia grave causada por un rendimiento de almacenamiento EBS (AMS) inadecuado
En este artículo se describe la degradación y la inestabilidad del rendimiento recurrentes en instancias de autor de AEM alojadas en Adobe Managed Services (AMS), donde el tipo de volumen EBS subyacente no cumple los requisitos de E/S del repositorio TarMK de AEM.
Descripción description
Entorno
Implementaciones de Adobe Experience Manager mediante repositorios TarMK en Adobe Managed Services (AMS) respaldados por el almacenamiento EBS de Amazon.
Problema/Síntomas
La instancia de autor de AEM experimenta una inestabilidad recurrente en las cargas de trabajo normales de creación, incluidas una o más de las siguientes:
- Latencia grave en la IU de creación, con tiempos de respuesta de un minuto o más para las solicitudes de editor estándar, shell y token CSRF.
- 504 tiempos de espera de puerta de enlace y errores 404 notificados por los autores.
- Operaciones de publicación fallidas o con un retraso significativo.
- El procesamiento de eventos DAM remotos se retrasa y se bloquea.
Las siguientes advertencias y errores pueden aparecer en error.log durante o después de 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
La correlación de request.log con estos períodos generalmente revela clústeres de solicitudes que se completan después de 30 segundos a varios minutos en los extremos de comprobación de estado, editor, pulso y token CSRF simultáneamente. Este patrón indica una detención en todo el JVM en lugar de una sola solicitud lenta.
Causa
El repositorio TarMK de AEM, almacenado bajo /mnt/crx, realiza operaciones de E/S secuenciales y aleatorias frecuentes para escrituras en almacenes de segmentos, creación de puntos de comprobación, actualizaciones de índices de Lucene y compactación. Estas cargas de trabajo del repositorio requieren una latencia de almacenamiento uniforme y suficientes IOPS.
Es posible que los volúmenes EBS magnéticos estándar no proporcionen características de rendimiento adecuadas para estas cargas de trabajo. Cuando el rendimiento del almacenamiento se ve restringido, el sistema operativo puede experimentar una espera de E/S sostenida, lo que provoca que varios grupos de subprocesos de JVM se detengan simultáneamente y da como resultado una latencia de aplicación amplia en solicitudes no relacionadas.
Este problema se observa más comúnmente en entornos AMS que no son de producción y que originalmente se aprovisionaron con volúmenes EBS magnéticos antes de que los volúmenes EBS gp3 se convirtieran en la opción de almacenamiento de repositorio estándar. Los entornos de producción no suelen verse afectados porque se han aprovisionado en el almacenamiento gp3 o se han migrado posteriormente a él.
Resolución resolution
Para identificar y resolver los problemas recurrentes de inestabilidad de autor de AEM, latencia grave y rendimiento del repositorio, siga estos pasos:
- Compruebe el tipo de volumen de Amazon EBS que realiza la copia de seguridad de
/mnt/crxen la instancia de autor afectada. Póngase en contacto con su ingeniero de éxito del cliente (Customer Success Engineer, CSE) para confirmar la configuración del volumen y determinar si el repositorio está alojado en un volumen Gp3 EBS. - Evaluar una migración a un volumen EBS gp3 si el repositorio está alojado en un almacenamiento magnético estándar. Revise cualquier consideración de servicio o de coste con su CSE en función de su acuerdo de AMS.
- Solicite una migración de almacenamiento a través de su CSE. Coordine con el equipo de infraestructura de AMS para crear el plan de migración y confirmar la configuración de IOPS y rendimiento de destino en función del tamaño del repositorio y los requisitos de carga de trabajo.
- Migre el volumen del repositorio a un volumen EBS gp3. El equipo de infraestructura de AMS suele realizar este proceso deteniendo la instancia de AEM, creando una instantánea del volumen existente, migrando el almacenamiento y reiniciando la instancia.
- Incluya las instancias de publicador afectadas en el plan de migración si utilizan la misma configuración de almacenamiento.
- Mida el rendimiento del sistema después de la migración. Compruebe que la espera de E/S, el uso de intercambio y el promedio de carga hayan disminuido durante la actividad de creación típica.
- Revise
request.logy confirme que los puntos de conexión de utilidad y editor ya no muestran tiempos de respuesta de varios segundos o minutos. - Revise
error.logy compruebe que los mensajes de error de punto de comprobación y las advertencias de índice de Lucene no se repiten. - Compruebe que el editor de páginas de creación se carga con normalidad, que las operaciones de publicación se completan correctamente, que la indexación asíncrona permanece actualizada y que los eventos DAM remotos se procesan sin retraso.
- Correlacione la degradación recurrente del rendimiento con actividades que requieren gran cantidad de repositorios, como ráfagas de replicación grandes, despliegues de MSM, implementaciones de paquetes o ingesta de recursos a gran escala si la inestabilidad persiste después de la migración.
- Ajuste la programación o la limitación de las cargas de trabajo de alto impacto cuando la demanda máxima del repositorio siga afectando al rendimiento.