Instabilità dell’authoring di AEM e latenza grave causata da prestazioni di archiviazione EBS (AMS) inadeguate
Questo articolo descrive il deterioramento ricorrente delle prestazioni e l’instabilità sulle istanze AEM Author ospitate su Adobe Managed Services (AMS), in cui il tipo di volume EBS sottostante non soddisfa i requisiti di I/O dell’archivio TarMK di AEM.
Descrizione description
Ambiente
Distribuzioni Adobe Experience Manager utilizzando archivi TarMK su Adobe Managed Services (AMS) supportati dallo storage Amazon EBS.
Problema/Sintomi
L’istanza Autore AEM presenta instabilità ricorrente con carichi di lavoro di authoring normali, tra cui uno o più dei seguenti:
- Latenza severa nell’interfaccia utente di authoring, con tempi di risposta di un minuto o più per le richieste di token di editor, shell e CSRF standard.
- 504 timeout del gateway ed errori 404 segnalati dagli autori.
- Operazioni di pubblicazione non riuscite o notevolmente ritardate.
- Elaborazione remota degli eventi DAM in ritardo e bloccata.
Le avvertenze e gli errori seguenti possono comparire in error.log durante o dopo i periodi degradati:
*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 correlazione di request.log rispetto a questi periodi rivela in genere cluster di richieste che vengono completate dopo 30 secondi o diversi minuti tra endpoint di controllo integrità, editor, pulse e token CSRF contemporaneamente. Questo modello indica uno stall a livello di JVM piuttosto che una singola richiesta lenta.
Causa
L’archivio TarMK di AEM, memorizzato in /mnt/crx, esegue frequenti operazioni di I/O sequenziali e casuali per le scritture dell’archivio segmenti, la creazione di punti di controllo, gli aggiornamenti dell’indice Lucene e la compattazione. Questi carichi di lavoro dell’archivio richiedono una latenza di archiviazione coerente e IOPS sufficienti.
I volumi magnetici standard EBS potrebbero non fornire caratteristiche di prestazioni adeguate per questi carichi di lavoro. Quando il throughput di storage diventa limitato, il sistema operativo può subire un’attesa di I/O prolungata, causando l’arresto simultaneo di più pool di thread JVM e determinando un’ampia latenza delle applicazioni su richieste non correlate.
Questo problema è più comunemente osservato in ambienti AMS non di produzione che originariamente erano forniti con volumi EBS magnetici prima che i volumi EBS gp3 diventassero l’opzione di storage standard dell’archivio. Gli ambienti di produzione spesso non subiscono modifiche perché sono stati predisposti per lo storage gp3 o sono stati successivamente migrati ad esso.
Risoluzione resolution
Per identificare e risolvere i problemi ricorrenti di instabilità di AEM Author, latenza grave e prestazioni dell’archivio, effettua le seguenti operazioni:
- Verificare il tipo di volume Amazon EBS che supporta
/mnt/crxnell’istanza Autore interessata. Contatta il Customer Success Engineer (CSE) per confermare la configurazione del volume e determinare se l’archivio è ospitato su un volume EBS gp3. - Valutare una migrazione a un volume EBS gp3 se l’archivio è ospitato su un supporto magnetico standard. Rivedi eventuali considerazioni sui servizi o sui costi con il tuo CSE in base al tuo contratto AMS.
- Richiedi una migrazione dello storage tramite il CSE. Coordinati con il team dell’infrastruttura AMS per creare il piano di migrazione e confermare le impostazioni IOPS e di velocità effettiva di destinazione in base alle dimensioni dell’archivio e ai requisiti del carico di lavoro.
- Migrare il volume del repository a un volume EBS gp3. In genere, il team dell’infrastruttura AMS esegue questo processo arrestando l’istanza di AEM, creando un’istantanea del volume esistente, eseguendo la migrazione dello storage e riavviando l’istanza.
- Includi le istanze di Publisher interessate nel piano di migrazione se utilizzano la stessa configurazione di archiviazione.
- Misura le prestazioni del sistema dopo la migrazione. Verificare che l’attesa di I/O, l’utilizzo di swap e la media di carico siano diminuiti durante le tipiche attività di authoring.
- Rivedere
request.loge verificare che gli endpoint dell’editor e dell’utilità non presentino più tempi di risposta di più secondi o minuti. - Esaminare
error.loge verificare che i messaggi di errore del punto di controllo e gli avvisi dell’indice Lucene non si ripresentino. - Verifica che l’editor pagina di authoring venga caricato correttamente, che le operazioni di pubblicazione vengano completate correttamente, che l’indicizzazione asincrona rimanga corrente e che gli eventi DAM remoto vengano elaborati senza ritardi.
- Se l’instabilità persiste dopo la migrazione, è possibile correlare il deterioramento ricorrente delle prestazioni con attività che richiedono un uso intensivo dell’archivio, come ad esempio i burst di replica di grandi dimensioni, i rollout MSM, le distribuzioni di pacchetti o l’acquisizione di risorse su larga scala.
- Regolare la pianificazione o la limitazione dei carichi di lavoro ad alto impatto quando il picco della domanda dell’archivio continua a influire sulle prestazioni.