Die Festplattenauslastung ist ungewöhnlich hoch oder nimmt schnell auf AEM Server zu

Erfahren Sie, wie Sie die Ursachen für eine hohe Festplattenauslastung auf AEM Server ermitteln können. Verwenden Sie einen Debugging-Logger, erfassen Sie Thread-Dumps und führen Sie CPU-Profiling durch und führen Sie den Bericht zur Festplattenauslastung aus.

Beschreibung description

Umgebung

Adobe Experience Manager

Problem/Symptome

Die Festplattenauslastung ist ungewöhnlich hoch oder nimmt auf einem AEM schnell zu. Da der Speicherplatz ausgeht, funktioniert AEM nicht mehr.

Auflösung resolution

A. Wenn AEM ausgeführt wird und genügend Festplattenspeicher vorhanden ist

  1. Konfigurieren der Protokollierung von Oak-Schreib-Traces Wenn AEM noch ausgeführt wird, können wir einen Debug-Logger aktivieren, der uns mitteilt, in welche Repository-Pfade geschrieben wird. Um diese Protokollfunktion zu aktivieren, installieren Sie unten das angehängte Protokollkonfigurationspaket oder führen Sie die folgenden Schritte aus:

    1. Navigieren Sie zu https://aemhost:port/system/console/slinglog
    2. Klicken Sie auf  Hinzufügen neuer Logger.
    3. Konfigurieren einer Protokollfunktion: Protokolldatei: logs/repgrowth.log, Protokollebene: Trace, Loggers: org.apache.jackrabbit.oak.jcr.operations.writes
    4. Herunterladen file. Dieses Paket enthält die erforderliche Konfiguration für die Protokollierungsschreibsitzung für Oak. Installieren Sie dieses Paket über den CRX Package Manager. Nach Ablauf des Anzeigezeitraums müssen Sie das Paket deinstallieren.

    Vorsicht

    • Das Protokoll enthält Informationen zu allen Schreibvorgängen und Sitzungsdetails. Wenn Sie diesen Logger verwenden, stellen Sie sicher, dass Sie über ausreichend Speicherplatz verfügen.
    • Deinstallieren Sie das Protokollkonfigurationspaket oder entfernen Sie die Protokollkonfiguration nach einer kurzen Zeitspanne, wenn dies aktiviert ist, um weiteren Speicherplatzverbrauch zu vermeiden.
  2. Ausführen des Berichts zur Festplattenauslastung Sie können auch den Bericht zur Festplattenauslastung https://host:port/etc/reports/diskusage.html nutzen. Dieser Bericht zeigt den vom Repository-Pfad verwendeten Speicherplatz. Der Bericht ist ausführbar, sodass Sie auch Unterbäume anzeigen können.

  3. Erfassen von Thread-Sicherheitskopien und Durchführen von Profiling Nachdem wir mit repGrowth.log eine Vorstellung davon erhalten haben, welche Daten geschrieben werden, können wir Informationen darüber erhalten, welcher Code diese Daten schreibt, indem wir Thread-Dumps erfassen und CPU-Profiling ausführen. Besuchen Sie diese Seiten:

B. Wenn AEM angehalten wurde und/oder der Festplattenspeicher fast voll ist

Wenn Sie AEM beenden mussten, um zu vermeiden, dass der Speicherplatz vergrößert wird, verwenden Sie die folgenden Befehle, um eine erste Analyse durchzuführen.

  • Verwenden Sie auf der Linux-Plattform die du Befehl zum Auflisten aller Ordner unter crx-quickstart mit der zusammengefassten Größe dieser Verzeichnisse:

    code language-none
    du -h --max-depth=2 crx-quickstart
    
  • Verwendung find und du -Befehle zum Auffinden kürzlich geänderter Dateien und zum Abrufen ihrer Größe:

    code language-none
    find crx-quickstart -type f -mtime 1 -exec du -hs {} \; -print
    
  • Um große Dateien im Datenspeicher zu finden, können Sie find, du, und file Befehle zum Auffinden von Dateien über 100 MB im Datenspeicher Verzeichnis erstellen und ihren Dateityp automatisch identifizieren:

    code language-none
    find crx-quickstart/repository/datastore -type f -size +100M -exec sh -c "du -hs \"{}\"; file \"{}\"" \;
    
  • Wenn Sie feststellen, dass das Wachstum im segmentstore -Verzeichnis, kann der folgende Befehl dazu beitragen, anzugeben, welche Daten geschrieben werden:

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

Ursache

Einige mögliche Ursachen für ungewöhnliche Erhöhungen der Festplattenauslastung sind:

  • Auf dem System wurde keine ordnungsgemäße Wartung durchgeführt.  Weitere Informationen zu verschiedenen Systemwartungsaktivitäten finden Sie in diesem Artikel .
  • AEM oder die Anwendung erstellt eine sehr große Anzahl von Knoten oder Aktualisierungen an Knoteneigenschaften.  Dies kann auf eine Fehlkonfiguration oder einen Fehler im Anwendungs-Code zurückzuführen sein.  Da die Tar-Speicherung in Oak nur im Anlagenmodus ausgeführt wird, trägt das wiederholte Speichern von Knoten weiter zu einem übermäßigen Repository-Wachstum bei.
  • Sehr große Dateien wurden in AEM Assets oder Package Manager hochgeladen.
  • Die Protokollierung von Debug oder Trace wurde aktiviert.
recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f