Instabilität der AEM-Autoren und hohe Latenz aufgrund unzureichender EBS-Speicherleistung (AMS)
In diesem Artikel werden wiederkehrende Leistungseinbußen und Instabilität bei auf Adobe Managed Services (AMS) gehosteten AEM-Autoreninstanzen beschrieben, bei denen der zugrunde liegende EBS-Volume-Typ die I/O-Anforderungen des TarMK-Repositorys von AEM nicht erfüllt.
Beschreibung description
Umgebung
Adobe Experience Manager-Bereitstellungen mithilfe von TarMK-Repositorys auf Adobe Managed Services (AMS), die durch den Amazon EBS-Speicher unterstützt werden.
Problem/Symptome
Die AEM-Autoreninstanz weist unter normalen Authoring-Workloads wiederkehrende Instabilität auf, einschließlich einer oder mehrerer der folgenden Situationen:
- Starke Latenz in der Authoring-Benutzeroberfläche mit Antwortzeiten von einer Minute oder mehr für Standard-Editor-, Shell- und CSRF-Token-Anfragen.
- Von Autoren wurden 504 Gateway-Zeitüberschreitungen und 404 Fehler gemeldet.
- Fehlgeschlagene oder erheblich verzögerte Veröffentlichungsvorgänge.
- Die Remote-DAM-Ereignisverarbeitung fällt zurück und wird blockiert.
Die folgenden Warnhinweise und Fehler können in error.log während oder nach einem eingeschränkten Zeitraum auftreten:
*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
Die Korrelation der request.log mit diesen Zeiträumen zeigt in der Regel Cluster von Anfragen, die nach 30 Sekunden bis zu mehreren Minuten abgeschlossen sind, über Konsistenzprüfungs-, Editor-, Impuls- und CSRF-Token-Endpunkte hinweg gleichzeitig. Dieses Muster weist auf einen JVM-weiten Stopp hin statt auf eine einzelne langsame Anfrage.
Ursache
Das TarMK-Repository von AEM, das unter /mnt/crx gespeichert ist, führt häufige sequenzielle und zufällige I/O-Vorgänge für Segmentspeicher-Schreibvorgänge, Checkpoint-Erstellung, Lucene-Indexaktualisierungen und Komprimierung durch. Diese Repository-Workloads erfordern eine konsistente Speicherlatenz und ausreichend IOPS.
Die standardmäßigen magnetischen EBS-Volumes bieten möglicherweise keine ausreichenden Leistungsmerkmale für diese Arbeitslasten. Wenn der Speicherdurchsatz eingeschränkt wird, kann es im Betriebssystem zu anhaltenden E/A-Wartezeiten kommen, wodurch mehrere JVM-Thread-Pools gleichzeitig angehalten werden, was zu einer breiten Anwendungslatenz bei nicht verwandten Anforderungen führt.
Dieses Problem tritt am häufigsten in Nicht-Produktions-AMS-Umgebungen auf, die ursprünglich mit magnetischen EBS-Volumes bereitgestellt wurden, bevor gp3 EBS-Volumes zur standardmäßigen Repository-Speicheroption wurden. Produktionsumgebungen sind häufig nicht betroffen, da sie im gp3-Speicher bereitgestellt oder später dorthin migriert wurden.
Lösung resolution
Gehen Sie wie folgt vor, um die wiederkehrenden Probleme mit der AEM-Autoreninstanz, der schwerwiegenden Latenz und der Repository-Leistung zu identifizieren und zu beheben:
- Überprüfen Sie die Amazon EBS-
/mnt/crxauf der betroffenen Autoreninstanz. Wenden Sie sich an Ihren Customer Success Engineer (CSE), um die Volume-Konfiguration zu bestätigen und festzustellen, ob das Repository auf einem gp3 EBS-Volume gehostet wird. - Ermitteln Sie eine Migration auf ein gp3 EBS-Volume, wenn das Repository auf einem standardmäßigen magnetischen Speicher gehostet wird. Überprüfen Sie etwaige Service- oder Kostenüberlegungen mit Ihrem CSE auf Grundlage Ihrer AMS-Vereinbarung.
- Fordern Sie eine Speichermigration über Ihren CSE an. Stimmen Sie sich mit dem AMS-Infrastrukturteam ab, um den Migrationsplan zu erstellen und die Ziel-IOPS und Durchsatzeinstellungen basierend auf der Repository-Größe und den Anforderungen an den Arbeitsaufwand zu bestätigen.
- Migrieren des Repository-Volumes auf ein gp3 EBS-Volume. Das AMS-Infrastrukturteam führt diesen Prozess in der Regel durch, indem es die AEM-Instanz stoppt, einen Snapshot des vorhandenen Volumes erstellt, den Speicher migriert und die Instanz neu startet.
- Betroffene Publisher-Instanzen in den Migrationsplan einbeziehen, wenn sie dieselbe Speicherkonfiguration verwenden.
- Messen der Systemleistung nach der Migration. Stellen Sie sicher, dass I/O-Wartezeiten, Swap-Nutzung und durchschnittliche Auslastung während der typischen Authoring-Aktivität abgenommen haben.
- Überprüfen Sie die
request.logund bestätigen Sie, dass die Editor- und Dienstprogramm-Endpunkte keine Antwortzeiten von mehreren Sekunden oder Minuten mehr aufweisen. - Überprüfen Sie die
error.logund stellen Sie sicher, dass Checkpoint-Fehlermeldungen und Lucene-Index-Warnungen nicht wiederholt werden. - Überprüfen Sie, ob der Seiteneditor der Autoreninstanz normal geladen wird, Veröffentlichungsvorgänge erfolgreich abgeschlossen werden, die asynchrone Indizierung aktuell bleibt und Remote-DAM-Ereignisse verzögerungsfrei verarbeitet werden.
- Korrelieren Sie wiederkehrende Leistungseinbußen mit Repository-intensiven Aktivitäten wie großen Replikations-Bursts, MSM-Rollouts, Paketbereitstellungen oder der Aufnahme großer Assets, wenn die Instabilität nach der Migration bestehen bleibt.
- Passen Sie die Planung oder Drosselung von Arbeitslasten mit starken Auswirkungen an, wenn die maximale Repository-Nachfrage weiterhin die Leistung beeinträchtigt.