Come analizzare i problemi critici comuni dell’AEM

Ultimo aggiornamento: 2023-11-16

Scopri i problemi critici più comuni relativi all’AEM e come analizzarli.

Descrizione

Ambiente

Adobe Experience Manager (AEM)

Problema

Questo articolo descrive i problemi critici più comuni dell’AEM e come analizzarli.

  • Prestazioni di AEM Sites
  • Prestazioni di AEM Assets
  • Problemi di memoria
  • Problemi di indicizzazione
  • Problemi di replica
  • Problemi di corruzione di TarMK

Risoluzione

Problemi relativi alle prestazioni di AEM Sites

Sintomi di un problema di prestazioni

  1. Caricamento lento delle pagine
  2. Creazione o modifica lenta delle pagine
  3. I tempi di risposta AEM sono lenti
  4. L’AEM non risponde ad alcune richieste
  5. Il request.log su AEM mostra tempi di risposta lenti

Cause dei problemi di prestazioni

  1. Conflitto di thread: richieste con tempi di esecuzione lunghi, ad esempio ricerche lente, processi in background con sovrascrittura, spostamento di interi rami di contenuto del sito e così via.
  2. Utilizzo CPU elevato
  3. Richieste costose come ricerche costose o codice applicazione inefficiente, componenti, ecc.
  4. Mancanza di manutenzione adeguata
  5. Memorizzazione nella cache del dispatcher insufficiente
  6. Mancanza di CDN
  7. Mancanza di memorizzazione nella cache del browser
  8. Troppi script caricati nella pagina e caricati nella parte superiore della pagina
  9. CSS caricato in tutta la pagina invece che nell’intestazione del HTML
  10. Dimensioni del server insufficienti o architettura errata
  11. Problemi di memoria (vedere di seguito)

Come analizzare il problema di prestazioni

  1. Acquisire una serie di immagini thread e analizzarle.
  2. Controllare a livello del sistema operativo se il processo Java AEM sta causando un elevato utilizzo della CPU: se l’AEM sta causando un elevato utilizzo della CPU, eseguire lo strumento di profiling preconfigurato per alcuni minuti e analizzare il risultato.
    • Linux: usa il comando top per controllare l'utilizzo della CPU.
    • Finestra: utilizzare Gestione attività di Windows
  3. Analizzare il file request.log per individuare eventuali richieste lente.
  4. Esaminare le procedure di manutenzione del sistema. Vedi questo articolo per informazioni dettagliate sulla manutenzione dell’AEM e sulla corretta manutenzione dell’AEM, tra cui:
    • Pulizia revisioni (solo di MongoMK e Database DocumentNodeStore) - giornaliera o più frequente
    • Compattazione catrame offline (solo TarMK): bisettimanale
    • Archivio dati Garbage Collection (solo sistemi con FileDataStore o S3 DataStore) - settimanale
    • Eliminazione flusso di lavoro - settimanale
    • Pulizia delle versioni - settimanale
    • Eliminazione log di controllo - settimanale
  5. Rivedi le strategie di caching implementate in Livello del dispatcher dell’AEM.
  6. Rivedi il sito caching.
  7. Utilizzare strumenti di analisi del sito lato client come Audit funzione nel browser Google Chrome Strumenti per sviluppatori pannello.  Questi strumenti forniscono consigli sui miglioramenti delle prestazioni lato client.

Soluzioni ai problemi di prestazioni comuni


 Problemi relativi alle prestazioni delle risorse

Sintomi di un problema di prestazioni delle risorse

  • Caricamenti lenti dei file in /assets.html o /damadmin UI
  • La generazione delle miniature richiede troppo tempo
  • Le operazioni delle risorse, come spostamento, eliminazione, modifica e aggiornamento dei metadati, richiedono troppo tempo

Cause dei problemi relativi alle prestazioni di Assets

  • Mancanza di manutenzione adeguata
  • Ultimi fix pack non applicati
  • Ottimizzazioni non applicate
  • Dimensioni del server inadeguate per il carico dell'utente

Come analizzare il problema di prestazioni delle risorse

Soluzioni ai problemi comuni di prestazioni delle risorse

Problemi di memoria
 

Sintomi di un problema di memoria

  • L’AEM si arresta in modo casuale e nei registri viene rilevato OutOfMemoryError
  • L’AEM diventa più lento nel tempo e alla fine si arresta
  • L’AEM non risponde

Diagnosi di un problema di memoria

  • Cerca OutOfMemoryError nei file di registro. Se trovi delle corrispondenze, hai un problema di memoria

  • Controlla il http://aem-host:porta schermata /system/console/memoryusage

    Se l’utilizzo di "Old Generation" (JDK 7 e precedenti) o "Tenured Generation" (JDK 8 o successivi) è elevato, allora questo potrebbe essere un segnale di un problema di utilizzo della memoria heap.  Fai clic su "Esegui Garbage Collector" per richiedere a JVM di eseguire una raccolta completa di oggetti heap inattivi.  Se l’utilizzo di heap rimane elevato dopo aver richiesto GC, allora c’è probabilmente un problema.  Su un’istanza AEM con archiviazione Oak Tar, se l’utilizzo tenure è superiore a 3 GB allora potrebbe esserci un problema.  Un elevato utilizzo dell’heap su un sistema con storage Mongo potrebbe essere dovuto alla configurazione della cache in memoria.

  • Acquisisci immagini thread e output più alto ed eseguire analisi dei thread.  Verifica se i thread che causano un utilizzo elevato della CPU sono thread nativi di JVM Garbage Collection.  Se il thread che utilizza la maggior parte del tempo della CPU è il "Thread VM" o qualsiasi thread di Garbage Collection, è probabile che si verifichi un problema di memoria.

Cause dei problemi di memoria

  • Perdita di memoria dell’applicazione Java
  • Java Finalizer si accumula a causa di un uso errato della finalizzazione nel codice personalizzato
  • Configurazione heap massima insufficiente

Come analizzare la causa del problema di memoria

Consulta questo articolo per informazioni dettagliate su come acquisire un’immagine heap.

Il modo migliore per identificare la causa di un problema di memoria è quello di analizzare un’immagine heap.

Una volta catturato un file Immagine heap, aprilo in Eclipse MAT o IBM Memory Analyzer strumento.  In Eclipse MAT, esegui il rapporto Leak Suspects (Sospetti di perdita) e apri la vista "Thread Details" (Dettagli thread) per vedere le potenziali cause del problema di memoria.

Soluzioni ai problemi comuni di memoria

  • Se noti lunghe pause per la raccolta di oggetti inattivi, ottimizza il codice dell’applicazione per utilizzare meno memoria.  La maggior parte dei problemi di Garbage Collection può essere risolta al meglio ottimizzando l’applicazione anziché ottimizzando la JVM.
  • Se l'applicazione è già stata ottimizzata e si verificano ancora lunghe pause GC, concentrarsi sulla messa a punto della JVM.

Problema di indicizzazione AEM
 

Sintomi dei problemi di indicizzazione

Di seguito sono riportati i segni di un problema di indicizzazione AEM/Oak:

  • I risultati della ricerca non sono più aggiornati di oltre 10 minuti
  • Risultati di ricerca mancanti
  • Gli errori vengono restituiti nell’interfaccia o nei registri durante la ricerca tramite l’interfaccia del sito, la ricerca di Query Builder o l’esecuzione di query JCR

Diagnosi di un problema di indicizzazione
Per verificare se l’indicizzazione asincrona è lenta o non riesce, effettua le seguenti operazioni:

  1. Apri questi URL nell’istanza AEM per visualizzare le statistiche sull’indicizzatore asincrono: http://aemhost:port/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dasync%2Ctype%3DIndexStats http://aemhost:port/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dfulltext-async%2Ctype%3DIndexStats  - This L’URL si applica solo all’AEM6.2 e versioni successive

  2. In ciascuna di queste pagine, seleziona i campi seguenti:

    FailSince - Indica quando l’indicizzazione è iniziata per la prima volta e ha avuto esito negativo.

    LastError : questa è la traccia dello stack che mostra cosa sta impedendo l’esecuzione dell’indicizzazione.  Se questo campo è vuoto, l’indicizzazione non avrà esito negativo.

    LastErrorTime - Indica l’ultima volta che l’indicizzazione ha generato l’errore.

    LastIndexedTime - Se la data e l’ora di questo campo hanno più di 5 minuti, l’indicizzazione è troppo lenta.

Cause dei problemi di indicizzazione

  • Manutenzione non corretta o mancata esecuzione di interventi di manutenzione quali la raccolta di oggetti inattivi di revisione, la rimozione del flusso di lavoro, la rimozione dell’audit, la rimozione della versione e così via.
  • Segmenti danneggiati o mancanti nell’archiviazione Tar
  • Revisione danneggiata in un ambiente cluster (DocumentNodeStore - Mongo o Database)
  • Problema relativo alla topologia del cluster in un ambiente cluster

Come analizzare la causa dei problemi di indicizzazione

  • Consulta questo articolo per analizzare e risolvere i problemi di indicizzazione

Problemi di replica
 

Sintomi dei problemi di replica

  • Le richieste di pubblicazione sono in coda nella coda dell’agente di replica
  • I contenuti pubblicati non vengono visualizzati sul server di pubblicazione
  • Impatto sulle prestazioni del sistema

Cause dei problemi di replica:

  • L’agente di replica non è configurato correttamente e non può connettersi all’agente di pubblicazione
  • Si è verificato un errore al momento della replica che ha causato il blocco della coda di replica
  • Il sistema è lento e le repliche vengono elaborate lentamente
  • La replica viene eseguita come parte di un flusso di lavoro personalizzato e il problema riguarda l’elaborazione del flusso di lavoro.

Come analizzare i problemi di replica:

  1. Controlla la coda di replica stato:

    Attivo: quando gli elementi vengono elaborati.

    Inattivo: quando la coda è vuota.

    Bloccato: quando gli elementi sono in coda, ma non possono essere elaborati; ad esempio, quando l’agente punta a un host inattivo o inesistente.

  2. Rivedi le configurazioni di replica se il server è clonato o se l’agente è stato configurato di recente. Per ulteriori informazioni, consulta qui.

  3. Esamina i registri dell’agente di replica in http://host:port/etc/replication/agents.author/AgentName.log.html#end.  Se non riesci a identificare alcun elemento, raccogli questo registro e presentalo al supporto AEM.

  4. Controlla il file error.log del server da AEMinstall/crx-quickstart/logs; Se non riesci a identificare alcun elemento, raccogli questo registro e presentalo al supporto AEM.

  5. Se la coda di replica è nello stato "inattivo" e nessuna delle condizioni precedenti è applicabile, in questo caso il problema è probabilmente causato dai flussi di lavoro. Se i flussi di lavoro non vengono elaborati, l’elemento di replica non arriva mai alla coda di replica. Per monitorare lo stato dei flussi di lavoro, puoi controllare il dashboard del flusso di lavoro per verificare il numero di istanze del flusso di lavoro in esecuzione. Informazioni sull’amministrazione dei flussi di lavoro qui.

  6. Le repliche rallentano quando il sistema è sotto carico o si verificano altri problemi di prestazioni.

Soluzione ai problemi comuni di replica:

  1. Esamina i problemi della coda di replica.
  2. Se il problema è dovuto a flussi di lavoro non efficienti, è possibile esaminare suggerimenti per l’elaborazione del flusso di lavoro.

Problemi di corruzione di TarMK
 

Sintomi della corruzione di TarMK

  • L’istanza non può essere utilizzata dopo la compattazione offline.
  • Istanza bloccata in Avvio in corso stato.
  • Rapporto di output dei file di registro o dei comandi di compattazione SegmentNotFoundException.

Cause dei problemi di corruzione

  • Il segmento viene rimosso con un intervento manuale (ad esempio, rm -rf ).
  • Il segmento viene rimosso dalla raccolta di oggetti inattivi di revisione o il segmento non viene trovato a causa di un bug nel codice.
  • Non è possibile trovare il segmento a causa di un bug nel codice.
  • Varie attività di manutenzione non vengono eseguite in tempo, determinando la crescita dell'archivio e la riduzione dello spazio su disco.
  • Fermare con forza l'AEM uccidendo il processo Java.

Problemi di danneggiamento dell’archivio di diagnostica:

  • Esamina il file error.log e verifica se è presente SegmentNotFoundException o Eccezione IllegalArgument.
  • Per determinare se un segmento è stato rimosso dalla raccolta di oggetti inattivi di revisione, controlla l’output del logger org.apache.jackrabbit.oak.plugins.segment.file.TarReader-GC (abilita registro di debug). Il logger registra gli ID di tutti i segmenti rimossi durante la fase di pulizia. Solo quando l’ID del segmento che genera l’infrazione viene visualizzato nell’output del logger, la causa dell’eccezione è la raccolta di oggetti inattivi di revisione.
  • In caso di corruzione nel datastore esterno, cerca nel file di registro tutte le occorrenze dell’errore Si è verificato un errore durante il recupero di InputStream per blobId. Questo errore indica che mancano file dalla directory dell’archivio dati AEM.

Soluzione per risolvere i problemi di danneggiamento:

  • Determinare l’ultima revisione valida nota dell’archivio segmenti utilizzando spunta modalità di esecuzione di oak-run.  Ripristina manualmente l’archivio segmenti danneggiato alla sua ultima revisione valida. Con questa operazione l’archivio Oak torna a uno stato precedente nel tempo.  Prima di eseguire questa operazione, è necessario eseguire il backup completo dell'archivio.
    • Per eseguire il controllo e il ripristino, seguire i passaggi indicati in questo articolo.
    • Se il controllo ha esito negativo con ConsistencyChecker - Nessuna revisione valida trovata quindi implementare i passaggi della parte B di questo articolo.
  • Se non utilizzi un archivio dati, utilizza un file esterno, S3 o Azure, invece di segmentstore predefinito.
    • L’utilizzo di un archivio dati offre prestazioni migliori.
    • Esegui la migrazione dell’istanza a un’istanza con un archivio dati utilizzando crx2oak.
  • Applica il Service Pack e il Cumulative Fix Pack più recenti e Oak Cumulative Fix Pack.

In questa pagina