Obiettivo

Problemi di 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 di AEM sono lenti
  4. AEM non risponde ad alcune richieste
  5. Il request.log su AEM mostra tempi di risposta lenti

Cosa causa problemi di performance

  1. Contenuto del thread: richieste con una tempistica lunga, come ricerche lente, attività in background con scrittura pesante, spostamento di interi rami di contenuto del sito, ecc.
  2. Elevato utilizzo della CPU
  3. Richieste costose, come ricerche costose o codici applicativi inefficienti, componenti, ecc.
  4. Mancanza di una corretta manutenzione
  5. Insufficiente caching del dispatcher
  6. Mancanza di CDN
  7. Mancanza di cache del browser
  8. Troppi script caricati nella pagina e caricati nella parte superiore della pagina
  9. CSS caricati in tutta la pagina, invece che nell’intestazione HTML
  10. Dimensionamento insufficiente del server o architettura errata
  11. Problemi di memoria (vedi sotto)

Come analizzare il problema delle prestazioni

1. Cattura una serie di immagini thread e analizzale

2. Controlla a livello di sistema operativo se il processo Java di AEM sta causando un elevato utilizzo della CPU

    Linux: utilizza il comando superiore per controllare l’utilizzo della CPU.

    Windows: utilizza il Task Manager di Windows

    Se AEM sta causando un elevato utilizzo della CPU, esegui lo strumento di profilazione preconfigurato per alcuni minuti e analizza il risultato.

3. Analizza il file request.log per eventuali richieste lente

4. Rivedi le procedure di manutenzione del sistema e assicurati di effettuare una manutenzione corretta su AEM, che includa i seguenti elementi:

  • Pulizia Revisioni (solo per MongoMK e Database DocumentNodeStore): ogni giorno o più frequentemente
  • Compattazione Tar offline (solo TarMK): bisettimanale
  • Archivio dati raccolta oggetti inattivi (solo sistemi con FileDataStore o S3 DataStore): settimanalmente
  • Pulizia del flusso di lavoro: settimanale
  • Pulizia delle versioni: settimanale
  • Pulizia AuditLog: settimanale

Consulta questo articolo per maggiori dettagli sulla manutenzione di AEM.

5. Revisione delle strategie di caching implementate a livello del dispatcher di AEM.  Il miglior punto di partenza è quello di capire quando e come il dispatcher memorizza e invalida i file nella cache.

6. Controlla la cachedel tuo sito.

7. Utilizza gli strumenti di analisi del sito lato client, come la funzionalità Audits nel pannello Strumenti per sviluppatori del browser Google Chrome.  Questi strumenti ti daranno consigli su come migliorare le prestazioni sul lato client.

Soluzioni a problemi di prestazioni comuni

Problemi di performance di AEM Assets

Sintomi di un problema di prestazioni di un’Assets

  • Caricamento lento dei file su /assets.html o /damadmin UI
  • Le anteprime richiedono troppo tempo per essere generate
  • Le operazioni relative alle Assets, come spostare, cancellare, modificare e aggiornare i metadati, richiedendo troppo tempo

Che cosa causa problemi con le prestazioni delle Assets

  • Mancanza di una corretta manutenzione
  • Non sono stati applicati gli ultimi Fix Pack
  • Non sono state applicate le ottimizzazioni
  • Ridimensionamento inadeguato del server per il carico dell’utente

Come analizzare il problema delle prestazioni delle Assets

Soluzioni ai problemi di prestazioni comuni di Assets

Problemi di memoria

Sintomi di un problema di memoria

  • AEM si blocca in modo casuale e nei registri si verifica l’errore OutOfMemoryError
  • AEM rallenta nel corso del tempo e alla fine si blocca
  • AEM non risponde

Come diagnosticare un problema di memoria

  • Cerca nei file di registro per individuare l’errore OutOfMemoryError; se trovi delle corrispondenze allora sussiste un problema di memoria
  • Rivedi la schermata http://aem-host:port/system/console/memoryusage
    Se l’utilizzo di “Old Generation” (JDK 7 e precedenti) o “Tenured Generation” (JDK8 o successivi) è alto, 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 oggetti heap rimane alto, dopo aver richiesto l’esecuzione di GC, allora c’è probabilmente un problema.  Su un’istanza di AEM con archiviazione Oak Tar, se l’uso tenure è superiore a 3GB allora potrebbe esserci un problema.  L’elevato utilizzo di heap su un sistema con archiviazione Mongo potrebbe essere dovuto alla configurazione della cache in-memory.
  • Prendi le immagini thread e l’output più alto ed esegui l’analisi del thread.  Controlla se i thread che causano un elevato utilizzo della CPU sono thread nativi di JVM Garbage Collection.  Se i thread che utilizzano gran parte del tempo della CPU sono “VM Thread” o qualsiasi altro thread di raccolta di oggetti inattivi, allora c’è probabilmente un problema di memoria.

Cosa causa problemi di memoria

  • Perdita di memoria dell’applicazione Java
  • Sovraccarico di Java Finalizer a causa di un uso non corretto della finalizzazione con codice personalizzato
  • Configurazione max heap insufficiente

Come analizzare la causa del problema di memoria

Consulta questo articolo per i dettagli su come catturare 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 nello strumento Eclipse MAT o IBM Memory Analyzer.  In Eclipse MAT, esegui il rapporto Leak Suspects e apri la vista “Thread Details” per vedere le potenziali cause del problema di memoria.

Soluzioni ai problemi di memoria comuni

  • 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 rispetto alla messa a punto di JVM.
  • Se hai già ottimizzato l’applicazione e sperimenti ancora lunghe pause in GC, allora concentrati sulla messa a punto di JVM.

Problemi di indicizzazione di AEM

Sintomi dei problemi di indicizzazione

I seguenti sono segnali di un problema con l’indicizzazione di AEM/Oak:

  • I risultati della ricerca non vengono aggiornati da oltre 10 minuti
  • Mancano dei risultati della ricerca
  • Vengono restituiti degli errori nell’interfaccia utente o nei registri, durante la ricerca tramite l’interfaccia utente del sito, la ricerca Query Builder o l’esecuzione della query JCR
Come diagnosticare un problema di indicizzazione
  • Per vedere se l’indicizzazione asincrona è lenta o non viene eseguita, procedi come segue:

1. Apri questi URL sulla tua istanza di AEM per visualizzare le statistiche sull’indicizzatore Async

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 ad AEM6.2 e successivi

2. In ciascuna di queste pagine, controlla questi campi:

FailingSince: indica quando l’indicizzazione ha iniziato a non essere eseguita correttamente.

LastError: questa è la traccia della sequenza che mostra cosa sta impedendo l’esecuzione dell’indicizzazione.  Se è vuota, allora l’indicizzazione sta funzionando correttamente.

LastErrorTime: indica l’ultima volta in cui l’indicizzazione ha generato l’errore.

LastIndexedTime: se la data e l’ora di questo campo superano i 5 minuti, l’indicizzazione è troppo lenta.

Cosa causa problemi con l’indicizzazione

  • Manutenzione impropria o mancata manutenzione tramite per esempio Revisione della raccolta di oggetti inattivi, Pulizia del flusso di lavoro, Pulizia Audit, Pulizia delle versioni, ecc.
  • Segmenti corrotti o mancanti nell’archiviazione Tar
  • Revisione della corruzione in un ambiente cluster (DocumentNodeStore - Mongo o Database)
  • Un problema con la topologia del cluster in un ambiente cluster

Come analizzare ciò che sta causando problemi di indicizzazione

  • Consulta questo articolo per l’analisi e la correzione dei problemi di indicizzazione

Problemi di replica

Sintomi dei problemi di replica

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

Cosa causa problemi di replica:

  • L’agente di replica non è configurato correttamente e non può connettersi all’agente di pubblicazione
  • C’è un errore al momento della replica, che causa l’arresto della coda di replica
  • Il sistema è lento e le repliche vengono elaborate lentamente
  • La replica avviene come parte di un flusso di lavoro personalizzato e il problema è generato dall’elaborazione del flusso di lavoro.

Come analizzare i problemi di replica:

1. Controlla lo statodella coda di replica:

        Attivo: quando gli elementi sono in fase di elaborazione.
        Inattivo: quando la coda è vuota.
        Bloccato: quando gli elementi sono in coda, ma non possono essere elaborati; per 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, vedi qui
     
3. Esamina i registri degli agenti di replica all’indirizzo http://host:port/etc/replication/agents.author/AgentName.log.html#end.  Se non riesci a identificare nessun elemento, raccogli questo registro e presentalo al supporto AEM.

4. Esamina il server error.log 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 è sullo stato “inattivo” e nessuna delle soluzioni precedenti è applicabile, in questocasoil 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 la dashboard dei flussi di lavoro, per verificare il numero di istanze dei flussi di lavoro in esecuzione. Per saperne di più sull’amministrazione dei flussi di lavoro, leggi qui.

6. Le repliche rallentano quando il sistema è sottoposto a un carico elevato o quando si verificano altri problemi di prestazioni.

Soluzione ai problemi di replica comuni:

1) Rivedi i problemi della coda di replica
2) Se il problema è dovuto ai flussi di lavoro non efficienti, puoi rivedere i suggerimenti per l’elaborazione dei flussi di lavoro concomitanti
3) Per problemi relativi alle prestazioni complessivamente lente di AEM ealla replicapuoi rivedere i Problemi di performance di AEM  

Problemi di corruzione TarMK

Sintomi della corruzione TarMK

  • Istanzainutilizzabile dopo la compattazione offline.
  • Istanza bloccata nello stato di Avvio in corso.
  • File di registro o rapporto di output del comando di compattazione SegmentNotFoundException.

Cosa causa i problemi di corruzione

  • Il segmento viene rimosso con un intervento manuale (ad es. rm -rf).   
  • Il segmento viene rimosso con la revisione della raccolta degli oggetti inattivi o non può essere trovato a causa di qualche bug nel codice.   
  • Impossibile trovare il segmento a causa di un bug nel codice.
  • Le varie operazioni di manutenzione non vengono eseguite in tempo, il che porta alla crescita dell’archivio e alla riduzione dello spazio sul disco.
  • L’arresto forzato di AEM interrompendo l’elaborazione Java.

Come diagnosticare i problemi di corruzione degli archivi:

  • Rivedi il file error.log e verifica se è presente SegmentNotFoundException o IllegalArgument Exception.
  • Per determinare se un segmento è stato rimosso dalla revisione della raccolta di oggetti inattivi, controlla l’output del file org.apache.jackrabbit.oak.plugins.segment.segment.file.TarReaderLogger -GC (registro abilita debug). Il logger registra gli ID di tutti i segmenti rimossi durante la fase di pulizia. Solo quando nell’output di quel logger appare l’ID del segmento causante la corruzione, la causa dell’eccezione è la revisione della raccolta degli oggetti inattivi.    
  • In caso di corruzione nel datastore esterno, cerca nel file di registro tutte le occorrenze dell’errore Errore verificatosi durante l’ottenimento di InputStream per blobId. Questo errore significa che mancano dei file dalla directory del datastore di AEM.

Soluzione per riparare i problemi di corruzione:

  • Determina l’ultima revisione nota andata a buon fine dell’archivio dei segmenti, utilizzando la modalità di esecuzione controllo di oak-run.  Ripristina manualmente il segmento corrotto che è stato archiviato alla sua ultima revisione andata a buon fine. Questa operazione riporta l’archivio Oak a uno stato precedente nel tempo.  Devi effettuare il backup completo dell’archivio, prima di eseguire questa operazione.
    • Per eseguireil controlloed effettuare il ripristino, segui i passaggi menzionati in questo articolo.
    • Se il controllo non riesce e mostra il messaggio ConsistencyChecker - Non sono state trovate revisioni andate a buon fine, implementa i passaggi della parte B di questo articolo.
  • Se stai già utilizzando un datastore e si verifica l’errore “Errore verificatosi durante l’ottenimento di InputStream per blobId”, è probabile che nel datastore manchino dei file. Leggi questo articolo per risolvere il problema.
  • Se non stai utilizzando un datastore, utilizza un file esterno, S3 o Azure datastore, al postodell’archivio segmenti predefinito.
    • L’utilizzo di un datastore fornisce prestazioni migliori.
    • Migra l’istanza a una con un datastore utilizzando crx2oak.
  • Applica l’ultimo Service Pack, Cumulative Fix Pack e Oak Cumulative Fix Pack.

Questo prodotto è concesso in licenza in base alla licenza di Attribuzione-Non commerciale-Condividi allo stesso modo 3.0 Unported di Creative Commons.  I post su Twitter™ e Facebook non sono coperti dai termini di Creative Commons.

Note legali   |   Informativa sulla privacy online