DokumentationAEM 6.5Benutzerhandbuch

Datenspeicherbereinigung data-store-garbage-collection

Last update: Tue Aug 20 2024 00:00:00 GMT+0000 (Coordinated Universal Time)
  • Themen:

Erstellt für:

  • Admin

Wenn ein herkömmliches WCM-Asset entfernt wird, kann der Verweis zum zugrunde liegenden Datenspeichereintrag aus der Knotenhierarchie entfernt werden. Der Datenspeichereintrag selbst bleibt allerdings bestehen. Dieser nicht referenzierte Datenspeichereintrag wird dadurch zu „Ausschussdaten“, die nicht aufbewahrt werden müssen. In Instanzen mit mehreren Garbage-Assets ist es von Vorteil, diese zu beseitigen, um Speicherplatz einzusparen und um die Performance beim Backup sowie bei der Dateisystemwartung zu optimieren.

Meist neigen WCM-Anwendungen dazu, Informationen zu sammeln. Gelöscht werden die Informationen allerdings bei Weitem nicht so oft. Auch wenn neue Bilder hinzugefügt werden und sogar wenn alte Versionen ersetzt werden, behält das Versionskontrollsystem dennoch die alte Version bei und unterstützt die Möglichkeit, bei Bedarf zu dieser Version zurückzukehren. Daher wird der Großteil der Inhalte, die wir zum System hinzufügen, permanent gespeichert. Was ist also die typische Quelle für „Ausschussdaten“ im Repository, die wir bereinigen möchten?

AEM verwendet das Repository als Speicher für verschiedene interne und bereinigungsbezogene Aktivitäten:

  • Zusammengestellte und heruntergeladene Pakete
  • Für die Veröffentlichungsreplikation erstellte temporäre Dateien
  • Workflow-Payloads
  • Während des DAM-Renderings temporär erstellte Assets

Wenn eines dieser temporären Objekte groß genug ist, Speicherplatz im Datenspeicher zu beanspruchen, und wenn das Objekt schließlich nicht mehr genutzt wird, bleibt der Datenspeichereintrag selbst als „Ausschuss“ vorhanden. In einer typischen WCM-Autoren-/Veröffentlichungsanwendung ist die größte Quelle von Ausschussdaten dieser Art in der Regel der Prozess der Aktivierung der Veröffentlichung. Wenn Daten für die Veröffentlichung repliziert werden, werden diese zunächst in einem effizienten Datenformat namens „Durbo“ in Sammlungen erfasst und im Repository unter /var/replication/data gespeichert. Die Datenbundles übersteigen oft den kritischen Größenschwellenwert für den Datenspeicher und werden daher als Datenspeichersätze gespeichert. Wenn die Replikation abgeschlossen ist, wird der Knoten in /var/replication/data gelöscht, doch der Datenspeichersatz bleibt als „Garbage“ bestehen.

Eine weitere Quelle von wiederherstellbaren Ausschussdaten sind Pakete. Paketdaten werden – wie alles andere auch – im Repository und bei Paketen, die größer sind als 4 KB, im Datenspeicher gespeichert. Während eines Entwicklungsprojekts oder im Laufe der Zeit können Pakete bei der Wartung eines Systems viele Male zusammengestellt und neu erstellt werden, wobei jede Version zu einem neuen Datenspeichereintrag führt, durch den der Dateneintrag der vorherigen Version verwaist.

Wie funktioniert die automatische Datenspeicherbereinigung? how-does-data-store-garbage-collection-work

Wenn das Repository mit einem externen Datenspeicher konfiguriert wurde, wird die automatische Datenspeicherbereinigung im Rahmen des wöchentlichen Wartungsfensters automatisch ausgeführt. Die oder der Systemadmin kann bei Bedarf die Datenspeicherbereinigung auch manuell ausführen. Im Allgemeinen wird empfohlen, die Datenspeicherbereinigung regelmäßig durchzuführen, doch sollten die folgenden Faktoren bei der Planung von Datenspeicherbereinigungen berücksichtigt werden:

  • Datenspeicherbereinigungen nehmen Zeit in Anspruch und können die Leistung beeinträchtigen, was entsprechend eingeplant werden sollte.
  • Das Entfernen der „Ausschuss“-Dateneinträge im Datenspeicher hat keinen Einfluss auf die normale Leistung. Es handelt sich also nicht um eine Leistungsoptimierung.
  • Wenn die Speichernutzung und damit verbundene Faktoren wie die Sicherungszeiten kein Problem darstellen, kann die automatische Datenspeicherbereinigung getrost zeitlich verschoben werden.

Der Datenspeicherbereiniger merkt sich zunächst den aktuellen Zeitstempel, wenn der Prozess beginnt. Die Sammlung der Daten wird mithilfe eines Multi-Pass-Mark-/Sweep-Pattern-Algorithmus durchgeführt.

In der ersten Phase unternimmt der Datenspeicherbereiniger einen umfassenden Durchlauf durch den gesamten Repository-Inhalt. Zu jedem Inhaltsobjekt mit einem Verweis zum Datenspeichereintrag sucht er die Datei im Dateisystem, führt eine Metadatenaktualisierung durch und ändert das „Zuletzt geändert“- oder MTIME-Attribut. An diesem Punkt erhalten Dateien, auf die in dieser Phase zugegriffen wurde, einen neueren Zeitstempel als den ursprünglichen Basiszeitstempel.

In der zweiten Phase durchläuft der Datenspeicherbereiniger die physische Verzeichnisstruktur des Datenspeichers auf eine sehr ähnliche Weise wie eine Suche. Er untersucht das „Zuletzt geändert“- oder MTIME-Attribut der Datei und bestimmt Folgendes:

  • Wenn das MTIME neuer als der ursprüngliche Basiszeitstempel ist, wurde die Datei entweder in der ersten Phase gefunden oder es handelt sich um eine völlig neue Datei, die während des laufenden Bereinigungsprozesses zum Repository hinzugefügt wurde. In beiden Fällen wird der Dateneintrag als aktiv betrachtet und die Datei nicht gelöscht.
  • Wenn das MTIME-Attribut vor dem ursprünglichen Basiszeitstempel liegt, handelt es sich bei der Datei nicht um eine aktiv referenzierte Datei und sie wird als entfernbarer „Datenausschuss“ betrachtet.

Dieser Ansatz funktioniert bei einem einzelnen Knoten mit einem privaten Datenspeicher sehr gut. Handelt es sich jedoch um einen gemeinsam genutzten Datenspeicher, bedeutet dies, dass potenziell aktive Live-Verweise auf Datenspeichereinträge von anderen Repositorys nicht geprüft werden und dass aktive referenzierte Dateien gegebenenfalls fälschlicherweise entfernt werden. Deswegen müssen Systemadmins vor der Planung jedweder Datenspeicherbereinigungen auf jeden Fall über eine gemeinsame Nutzung des Datenspeichers Bescheid wissen. Sie dürfen nur dann den einfachen integrierten Prozess zur Datenspeicherbereinigung verwenden, wenn bekannt ist, dass der Datenspeicher nicht gemeinsam genutzt wird.

NOTE
Wenn Sie die automatische Bereinigung für einen eingerichteten Cluster- oder freigegebenen Speicher (mit Mongo oder Segment-Tar) durchführen, werden im Protokoll möglicherweise Warnungen angezeigt, wonach bestimmte Blob-IDs nicht gelöscht werden können. Dies geschieht, weil während einer vorherigen automatischen Bereinigung gelöschte Blob-IDs fälschlicherweise erneut von anderen Cluster- oder Freigabeknoten referenziert werden, denen die Informationen zu den ID-Löschungen fehlen. Daher wird bei der automatischen Bereinigung eine Warnung protokolliert, wenn versucht wird, eine bereits im vorherigen Durchgang gelöschte ID zu entfernen. Dieses Verhalten wirkt sich weder auf die Leistung noch auf die Funktionalität aus.

Ausführen der Datenspeicherbereinigung running-data-store-garbage-collection

Die Datenspeicherbereinigung kann je nach dem Setup des Datenspeichers, mit dem AEM ausgeführt wird, auf drei Arten erfolgen:

  1. Über die Revisionsbereinigung – ein Bereinigungsmechanismus, der in der Regel für die Bereinigung des Knotenspeichers verwendet wird

  2. Über die Datenspeicherbereinigung – ein Bereinigungsmechanismus speziell für externe Datenspeicher, der im Vorgangs-Dashboard verfügbar ist.

  3. Über die JMX-Konsole.

Wenn TarMK sowohl als Knotenspeicher als auch als Datenspeicher verwendet wird, kann die Revisionsbereinigung für die Bereinigung beider Speicher eingesetzt werden. Wenn jedoch ein externer Datenspeicher wie der Dateisystemdatenspeicher konfiguriert ist, muss die Datenspeicherbereinigung explizit und separat von der Revisionsbereinigung ausgelöst werden. Die Speicherbereinigung kann über das Vorgangs-Dashboard oder die JMX-Konsole ausgelöst werden.

Die folgende Tabelle zeigt den Datenspeicherbereinigungstyp, der für alle unterstützten Datenspeicherbereitstellungen in AEM 6 verwendet werden muss:

Knotenspeicher
Datenspeicher
Bereinigungsmechanismus
TarMK
TarMK
Revisionsbereinigung (Binärdateien sind mit dem Segmentspeicher abgestimmt)
TarMK
Externes Dateisystem

Aufgabe zur automatischen Datenspeicherbereinigung über das Vorgangs-Dashboard

JMX-Konsole

MongoDB
MongoDB

Aufgabe zur automatischen Datenspeicherbereinigung über das Vorgangs-Dashboard

JMX-Konsole

MongoDB
Externes Dateisystem

Aufgabe zur automatischen Datenspeicherbereinigung über das Vorgangs-Dashboard

JMX-Konsole

Ausführen der automatischen Datenspeicherbereinigung über das Vorgangs-Dashboard running-data-store-garbage-collection-via-the-operations-dashboard

Das integrierte, über das Vorgangs-Dashboard verfügbare wöchentliche Wartungsfenster beinhaltet die integrierte Aufgabe, die Datenspeicherbereinigung sonntags um 1 Uhr nachts durchzuführen.

Wenn Sie die Datenspeicherbereinigung zu einem anderen Zeitpunkt ausführen müssen, kann diese auch manuell über das Vorgangs-Dashboard ausgelöst werden.

Vor der Ausführung der Datenspeicherbereinigung sollten Sie sicherstellen, dass zu dem Zeitpunkt keine Sicherungen ausgeführt werden.

  1. Öffnen Sie das Vorgangs-Dashboard über Navigation > Tools > Vorgänge > Wartung.

  2. Klicken Sie auf die Seite Wöchentliches Wartungsfenster.

    chlimage_1-64

  3. Wählen Sie die Aufgabe Automatische Datenspeicherbereinigung aus und klicken Sie dann auf das Symbol Ausführen.

    chlimage_1-65

  4. Die automatische Datenspeicherbereinigung wird ausgeführt und der Status wird im Dashboard angezeigt.

    chlimage_1-66

NOTE
Die Aufgabe zur Durchführung der automatischen Datenspeicherbereinigung wird nur angezeigt, wenn Sie einen externen Dateidatenspeicher konfiguriert haben. Informationen zum Einrichten eines Dateidatenspeichers finden Sie unter Konfigurieren von Knotenspeichern und Datenspeichern in AEM 6.

Ausführen der Datenspeicherbereinigung über die JMX-Konsole running-data-store-garbage-collection-via-the-jmx-console

In diesem Abschnitt wird das manuelle Ausführen der Datenspeicherbereinigung über die JMX-Konsole beschrieben. Wenn Ihre Installation ohne einen externen Datenspeicher eingerichtet ist, betrifft dies Ihre Installation nicht. Sehen Sie sich stattdessen die Anweisungen zum Ausführen der Revisionsbereinigung unter Warten des Repositorys an.

NOTE
Wenn Sie TarMK mit einem externen Datenspeicher ausführen, müssen Sie zunächst die Versionsbereinigung ausführen, damit die Speicherbereinigung effektiv sein kann.

So führen Sie die Speicherbereinigung durch:

  1. Markieren Sie in der Apache Felix OSGi Management Console die Registerkarte Main und wählen Sie JMX aus dem folgenden Menü aus.

  2. Suchen Sie dann nach dem MBean Repository Manager und klicken Sie darauf (oder gehen Sie zu https://<host>:<port>/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Drepository+manager%2Ctype%3DRepositoryManagement).

  3. Klicken Sie auf startDataStoreGC(boolean markOnly).

  4. Geben Sie ggf. true für den Parameter markOnly ein:

    table 0-row-2 1-row-2
    Option Beschreibung
    boolesches markOnly Setzen Sie diesen Wert auf true, um beim Markierungs- und Sweep-Vorgang nur Referenzen zu markieren und nicht zu sweepen. Dieser Modus wird verwendet, wenn der zugrunde liegende BlobStore für mehrere verschiedene Repositorys freigegeben ist. Verwenden Sie in allen anderen Fällen „false“, um eine vollständige Speicherbereinigung durchzuführen.

  5. Klicken Sie auf Invoke. CRX führt die Speicherbereinigung durch und zeigt an, wenn diese abgeschlossen ist.

NOTE
Die automatische Datenspeicherbereinigung erfasst keine Dateien, die in den letzten 24 Stunden gelöscht wurden.
NOTE
Die Aufgabe zur Durchführung der automatischen Datenspeicherbereinigung startet nur, wenn Sie einen externen Dateidatenspeicher konfiguriert haben. Wenn kein externer Dateidatenspeicher konfiguriert wurde, gibt die Aufgabe, nachdem sie aufgerufen wurde, die Meldung Cannot perform operation: no service of type BlobGCMBean found aus. Informationen zum Einrichten eines Dateidatenspeichers finden Sie unter Konfigurieren von Knotenspeichern und Datenspeichern in AEM 6.

Automatisieren der Datenspeicherbereinigung automating-data-store-garbage-collection

Falls möglich, sollte die Datenspeicherbereinigung ausgeführt werden, wenn das System nicht stark ausgelastet ist – beispielsweise am frühen Morgen.

Das integrierte, über das Vorgangs-Dashboard verfügbare wöchentliche Wartungsfenster beinhaltet die integrierte Aufgabe, die Datenspeicherbereinigung sonntags um 1 Uhr morgens durchzuführen. Sie sollten auch sicherstellen, dass zu dem Zeitpunkt keine Sicherungen ausgeführt werden. Der Start des Wartungsfensters kann bei Bedarf über das Dashboard angepasst werden.

NOTE
Es sollte nicht beides gleichzeitig ausgeführt werden, damit alte (und nicht verwendete) Datenspeicherdateien ebenfalls gesichert werden. Auf diese Weise sind die Binärdateien nach wie vor in der Sicherung vorhanden, wenn das Zurücksetzen auf eine alte Revision erforderlich sein sollte.

Wenn Sie die Datenspeicherbereinigung nicht mit dem wöchentlichen Wartungsfenster im Vorgangs-Dashboard ausführen möchten, kann sie auch mithilfe der wget- oder curl-HTTP-Clients automatisiert werden. Es folgt ein Beispiel für eine Automatisierung der Speicherbereinigung mit „curl“:

CAUTION
Im folgenden Beispiel müssen gegebenenfalls verschiedene Parameter des curl-Befehls für Ihre Instanz konfiguriert werden, so zum Beispiel Hostname (localhost), Port (4502), Admin-Kennwort (xyz) und verschiedene Parameter für die tatsächliche automatische Datenspeicherbereinigung.

Dies ist ein Beispiel für einen curl-Befehl zum Aufrufen der automatischen Datenspeicherbereinigung über die Befehlszeile:

curl -u admin:admin -X POST --data markOnly=true  https://localhost:4503/system/console/jmx/org.apache.jackrabbit.oak"%"3Aname"%"3Drepository+manager"%"2Ctype"%"3DRepositoryManagement/op/startDataStoreGC/boolean

Der curl-Befehl wird sofort zurückgegeben.

Überprüfen der Datenspeicherkonsistenz checking-data-store-consistency

Die Konsistenzprüfung für den Datenspeicher meldet alle Binärdateien des Datenspeichers, die fehlen, aber noch referenziert werden. Gehen Sie wie folgt vor, um eine Konsistenzprüfung zu starten:

  1. Gehen Sie zur JMX-Konsole. Weitere Informationen zur Nutzung der JMX-Konsole finden Sie unter Überwachen von Server-Ressourcen mit der JMX-Konsole.
  2. Suchen Sie nach dem MBean BlobGarbageCollection und klicken Sie darauf.
  3. Klicken Sie auf den Link checkConsistency().

Nach dem Abschluss der Konsistenzprüfung wird eine Meldung mit der Zahl der als fehlend gemeldeten Binärdateien angezeigt. Ist die Zahl größer als 0, prüfen Sie das error.log, um weitere Details zu fehlenden Binärdateien anzuzeigen.

Im Folgenden finden Sie ein Beispiel dafür, wie die fehlenden Binärdateien in den Protokollen gemeldet werden:

11:32:39.673 INFO [main] MarkSweepGarbageCollector.java:600 Consistency check found [1] missing blobs

11:32:39.673 WARN [main] MarkSweepGarbageCollector.java:602 Consistency check failure intheblob store : DataStore backed BlobStore [org.apache.jackrabbit.oak.plugins.blob.datastore.OakFileDataStore], check missing candidates in file /tmp/gcworkdir-1467352959243/gccand-1467352959243
recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2