Documentazione

Come analizzare i problemi critici comuni dell’AEM

Last update: Tue Jul 23 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

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

Descrizione description

Ambiente

Adobe Experience Manager (AEM)

Problema/Sintomi

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 resolution

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 di scrittura, 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 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 eventuali richieste lente.

  4. Esaminare le procedure di manutenzione del sistema. Consulta questo articolo per informazioni dettagliate sulla manutenzione dell'AEM e assicurati di eseguire la manutenzione corretta 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 a livello di Dispatcher AEM.

  6. Controlla la memorizzazione in cache del tuo sito.

  7. Utilizza gli strumenti di analisi del sito lato client, ad esempio la funzionalità Audit nel browser Google Chrome Strumenti per sviluppatori. Questi strumenti forniscono consigli sui miglioramenti delle prestazioni lato client.

Soluzioni ai problemi di prestazioni comuni

Problemi relativi alle prestazioni di Assets

Sintomi di un problema di prestazioni di Assets

  • Caricamenti lenti dei file in /assets.html o /damadmin UI
  • La generazione delle miniature richiede troppo tempo
  • L'esecuzione di operazioni Assets quali spostamento, eliminazione, modifica e aggiornamento dei metadati richiede 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 di Assets

Soluzioni ai problemi comuni relativi alle prestazioni di Assets

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 la schermata http://aem-host:port/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 le immagini thread e l'output più alto ed esegui l'analisi del 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.

Dopo aver acquisito un file Immagine heap, aprilo nello strumento Eclipse MAT o IBM Memory Analyzer. 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 sul tuning di 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 - Questo URL si applica solo all’AEM6.2 e versioni successive

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

    FailingSince - Indica quando l'indicizzazione è iniziata non riuscendo.

    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 sono 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 Publish 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: durante l'elaborazione degli elementi.

    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 dettagli, consulta qui.

  3. Esaminare 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. Rivedi il file error.log del server da AEMinstall/crx-quickstart/logs; se non riesci a identificare alcun elemento, raccogli questo log e lo presenti 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. Per informazioni sull'amministrazione dei flussi di lavoro consulta.

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

Soluzione ai problemi di replica comuni:

  1. Controlla i problemi della coda di replica.
  2. Se il problema è dovuto a flussi di lavoro non in esecuzione in modo efficiente, è possibile esaminare i suggerimenti per l'elaborazione del flusso di lavoro simultanei.

Problemi di corruzione di TarMK

Sintomi di corruzione TarMK

  • L’istanza non può essere utilizzata dopo la compattazione offline.
  • Istanza bloccata nello stato Avvio in corso.
  • File di log o report di output del comando 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:

  • Rivedi il file error.log e verifica se è presente SegmentNotFoundException o IllegalArgumentException.
  • 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 danneggiamento nell'archivio dati esterno, cercare nel file di registro tutte le occorrenze dell'errore Errore durante l'ottenimento di InputStream per blobId. Questo errore indica che mancano file dalla directory dell’archivio dati AEM.

Soluzione per risolvere i problemi di danneggiamento:

  • Determina l'ultima revisione valida nota dell'archivio segmenti utilizzando la modalità di esecuzione check 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, eseguire i passaggi indicati in questo articolo.
    • Se il controllo non riesce con ConsistencyChecker - Nessuna revisione valida trovata, implementa i passaggi nella 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.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f