L'utilizzo del disco è insolitamente elevato o in rapido aumento sul server AEM

Scopri come identificare le cause dell’utilizzo elevato del disco sul server AEM. Utilizza un logger di debug, acquisisci le immagini thread ed esegui la profilatura della CPU ed esegui il rapporto sull’utilizzo del disco.

Descrizione description

Ambiente

Adobe Experience Manager

Problema/Sintomi

L'utilizzo del disco è insolitamente elevato o in rapida crescita su un server AEM. Con lo spazio su disco esaurito, l'AEM ha smesso di funzionare.

Risoluzione resolution

A. Se l’AEM è in esecuzione e lo spazio su disco è ampio

  1. Configura registrazione traccia scrittura oak Se l’AEM è ancora in esecuzione, possiamo abilitare un logger di debug per indicarci in quali percorsi dell’archivio vengono scritti. Per abilitare questo logger, installa il pacchetto di configurazione del registro allegato di seguito o segui questi passaggi:

    1. Vai a https://aemhost:port/system/console/slinglog
    2. Fai clic su  Aggiungi nuovo logger.
    3. Configurare un logger: File di registro: logs/repgrowth.log Livello registro: traccia, Logger: org.apache.jackrabbit.oak.jcr.operations.writes
    4. Scarica file. Questo pacchetto contiene la configurazione richiesta per la sessione di scrittura di registrazione per Oak. Installa questo pacchetto tramite Gestione pacchetti CRX. Dopo il periodo di installazione del monitor, assicurarsi di disinstallare il pacchetto.

    Attenzione

    • Il registro include informazioni relative a tutte le scritture e ai dettagli della sessione. Se si utilizza questo logger, assicurarsi di disporre di spazio su disco sufficiente.
    • Disinstalla il pacchetto di configurazione del registro o rimuovi la configurazione del registro dopo un breve periodo di attivazione per evitare un ulteriore consumo di spazio su disco.
  2. Eseguire il report sull'utilizzo del disco Puoi anche sfruttare il rapporto Utilizzo disco https://host:port/etc/reports/diskusage.html. Questo report visualizza lo spazio su disco utilizzato dal percorso del repository. Il report è espandibile e consente di visualizzare anche sottostrutture.

  3. Acquisire le immagini thread ed eseguire la profilatura Dopo aver utilizzato il file repgrowth.log per avere un’idea dei dati che vengono scritti, è possibile ottenere informazioni sul codice che scrive tali dati acquisendo immagini thread ed eseguendo la profilatura della CPU. Visita queste pagine:

B. Se l’AEM si è arrestato e/o lo spazio su disco è quasi esaurito

Se è stato necessario arrestare l'AEM per evitare di aumentare lo spazio su disco, utilizzare i comandi riportati di seguito per eseguire un'analisi iniziale.

  • Sulla piattaforma Linux, utilizza du comando per elencare tutte le directory in crx-quickstart con le dimensioni riepilogate di tali directory:

    code language-none
    du -h --max-depth=2 crx-quickstart
    
  • Utilizzare trova e du comandi per trovare i file modificati di recente e ottenerne le dimensioni:

    code language-none
    find crx-quickstart -type f -mtime 1 -exec du -hs {} \; -print
    
  • Per trovare file di grandi dimensioni nell’archivio dati, puoi combinare trova, du, e file comandi per trovare file superiori a 100 MB nel archivio dati e ne identifica automaticamente il tipo di file:

    code language-none
    find crx-quickstart/repository/datastore -type f -size +100M -exec sh -c "du -hs \"{}\"; file \"{}\"" \;
    
  • Se rileva che la crescita è in corso nel segmentstore , il comando seguente potrebbe aiutare a indicare i dati che vengono scritti:

    code language-none
    strings data_xxxxxx.tar | egrep '.?/' | sed 's/.$//;s/.\//\//'
    

Causa

Alcune possibili cause di aumenti insoliti nell'utilizzo dei dischi sono:

  • La manutenzione corretta non è stata eseguita sul sistema.  Consulta questo articolo per informazioni dettagliate sulle varie attività di manutenzione del sistema.
  • L’AEM o l’applicazione sta creando un numero molto elevato di nodi o aggiornamenti alle proprietà dei nodi.  Ciò potrebbe essere dovuto a una configurazione errata o a un bug del codice dell’applicazione.  Poiché lo storage tar in Oak funziona in modalità di sola aggiunta, il salvataggio ripetuto dei nodi contribuisce ulteriormente alla crescita eccessiva dell’archivio.
  • Sono stati caricati file di dimensioni molto grandi in AEM Assets o nel gestore di pacchetti.
  • La registrazione di debug o di traccia è stata lasciata abilitata.
recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f