Instabilité de l’auteur AEM et latence sévère dues à des performances de stockage EBS inadéquates (AMS)
Cet article décrit la dégradation et l’instabilité récurrentes des performances sur les instances de création AEM hébergées sur Adobe Managed Services (AMS), où le type de volume EBS sous-jacent ne répond pas aux exigences d’E/S du référentiel TarMK d’AEM.
Description description
Environnement
Déploiements de Adobe Experience Manager à l’aide de référentiels TarMK sur Adobe Managed Services (AMS) pris en charge par le stockage Amazon EBS.
Problème/Symptômes
L’instance d’auteur AEM connaît une instabilité récurrente dans des charges de travail de création normales, y compris une ou plusieurs des situations suivantes :
- Latence importante dans l’interface utilisateur de création, avec des temps de réponse d’une minute ou plus pour les requêtes standard d’éditeur, de shell et de jeton CSRF.
- Délais d’expiration de la passerelle 504 et erreurs 404 signalés par les auteurs.
- Échec ou retard significatif des opérations de publication.
- Le traitement des événements de gestion des ressources numériques distants prend du retard et est bloqué.
Les avertissements et erreurs suivants peuvent apparaître dans error.log pendant ou après des périodes dégradées :
*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 corrélation des request.log par rapport à ces périodes révèle généralement des clusters de requêtes qui s’exécutent au bout de 30 secondes à plusieurs minutes simultanément sur les points d’entrée de contrôle d’intégrité, d’éditeur, d’impulsion et de jeton CSRF. Ce modèle indique un blocage à l’échelle de la JVM plutôt qu’une seule requête lente.
Cause
Le référentiel TarMK d’AEM, stocké sous /mnt/crx, effectue fréquemment des opérations d’E/S séquentielles et aléatoires pour les écritures de magasin de segments, la création de points de contrôle, les mises à jour d’index Lucene et la compression. Ces charges de travail de référentiel nécessitent une latence de stockage cohérente et des IOPS suffisantes.
Les volumes EBS magnétiques standard peuvent ne pas fournir des caractéristiques de performance adéquates pour ces charges de travail. Lorsque le débit de stockage est limité, le système d’exploitation peut subir une attente d’E/S prolongée, ce qui entraîne le blocage simultané de plusieurs pools de threads JVM et entraîne une latence d’application étendue sur des requêtes non liées.
Ce problème est le plus souvent observé dans les environnements AMS hors production qui étaient initialement configurés avec des volumes EBS magnétiques avant que les volumes EBS gp3 ne deviennent l’option de stockage de référentiel standard. Les environnements de production ne sont souvent pas affectés, car ils ont été configurés sur le stockage gp3 ou ont fait l’objet d’une migration ultérieure vers ce dernier.
Résolution resolution
Pour identifier et résoudre les problèmes récurrents d’instabilité de l’auteur AEM, de latence sévère et de performances du référentiel, procédez comme suit :
- Vérifiez le
/mnt/crxde sauvegarde de type de volume Amazon EBS sur l’instance d’auteur concernée. Contactez votre ingénieur du succès client (CSE) pour confirmer la configuration du volume et déterminer si le référentiel est hébergé sur un volume EBS gp3. - Évaluez une migration vers un volume EBS gp3 si le référentiel est hébergé sur un stockage magnétique standard. Examinez tout aspect lié au service ou aux coûts avec votre CSE en fonction de votre accord AMS.
- Demandez une migration du stockage par l’intermédiaire de votre CSE. Collaborez avec l’équipe de l’infrastructure AMS pour créer le plan de migration et confirmer les IOPS et les paramètres de débit cibles en fonction de la taille du référentiel et des exigences en matière de charge de travail.
- Migrez le volume du référentiel vers un volume EBS gp3. L’équipe d’infrastructure AMS effectue généralement ce processus en arrêtant l’instance AEM, en créant un instantané du volume existant, en migrant le stockage et en redémarrant l’instance.
- Incluez les instances d’éditeur concernées dans le plan de migration si elles utilisent la même configuration de stockage.
- Mesurez les performances du système après la migration. Vérifiez que l’attente d’E/S, l’utilisation de la permutation et la moyenne de charge ont diminué au cours d’une activité de création standard.
- Passez en revue les
request.loget vérifiez que les points d’entrée de l’éditeur et de l’utilitaire ne présentent plus de temps de réponse de plusieurs secondes ou minutes. - Passez en revue les
error.loget vérifiez que les messages d’échec des points de contrôle et les avertissements de l’index Lucene ne se reproduisent pas. - Vérifiez que l’éditeur de page de création se charge normalement, que les opérations de publication sont terminées avec succès, que l’indexation asynchrone reste à jour et que les événements de gestion des ressources numériques distants se traitent sans retard.
- Associez la dégradation récurrente des performances à des activités gourmandes en référentiel, telles que des rafales de réplication volumineuses, des déploiements MSM, des déploiements de packages ou une ingestion de ressources à grande échelle, si l’instabilité persiste après la migration.
- Ajustez la planification ou le ralentissement des charges de travail à fort impact lorsque la demande de référentiel maximale continue d’affecter les performances.