Revisionsbereinigung revision-cleanup
Einführung introduction
Bei jeder Repository-Aktualisierung wird eine neue Inhaltsrevision erstellt. Daher wächst das Repository nach jeder Aktualisierung. Um ein unkontrolliertes Repository-Wachstum zu vermeiden, müssen alte Revisionen bereinigt werden, um Festplattenressourcen freizugeben. Diese Wartungsfunktionalität wird als Revisionsbereinigung bezeichnet. Sie ist seit AEM 6.0 als Offline-Routine verfügbar.
Mit AEM 6.3 wurde eine Online-Version dieser Funktion namens Online-Revisionsbereinigung eingeführt. Verglichen mit der Offline-Revisionsbereinigung, bei der die AEM-Instanz beendet werden muss, kann die Online-Revisionsbereinigung ausgeführt werden, wenn die AEM-Instanz online ist. Die Online-Revisionsbereinigung ist standardmäßig aktiviert und ist die empfohlene Methode zur Durchführung der Revisionsbereinigung.
Hinweis: Im Video finden Sie eine Einführung in die Verwendung der Online-Revisionsbereinigung.
Der Revisionsbereinigungsprozess besteht aus drei Phasen: Schätzung, Komprimierung und Bereinigung. Die Schätzung bestimmt, ob die nächste Phase (Komprimierung) ausgeführt werden soll oder nicht, je nachdem, wie viel Speicherabfall möglicherweise erfasst wird. Während der Komprimierungsphase werden Segmente und TAR-Dateien neu geschrieben, wobei nicht verwendete Inhalte ausgeschlossen werden. In der Bereinigungsphase werden anschließend die alten Segmente entfernt, einschließlich des möglicherweise vorhandenen Speicherabfalls. Der Offline-Modus kann in der Regel mehr Speicherplatz zurückgewinnen, da der Online-Modus das AEM-Arbeits-Set berücksichtigen muss, in dem zusätzliche Segmente nicht erfasst werden.
Weitere Informationen zur Revisionsbereinigung finden Sie unter den folgenden Links:
Weitere Informationen finden Sie in der offiziellen Oak-Dokumentation.
Wann sollte die Online-Revisionsbereinigung anstelle der Offline-Revisionsbereinigung verwendet werden? when-to-use-online-revision-cleanup-as-opposed-to-offline-revision-cleanup
Die Online-Revisionsbereinigung ist die empfohlene Methode zur Durchführung der Revisionsbereinigung. Die Offline-Revisionsbereinigung sollte nur in Ausnahmefällen erfolgen, beispielsweise bei der Migration zu einem neuen Speicherformat oder auf Anforderung der Adobe-Kundenunterstützung.
Ausführen der Online-Revisionsbereinigung how-to-run-online-revision-cleanup
Die Online-Revisionsbereinigung ist standardmäßig so konfiguriert, dass sie einmal täglich sowohl in der Autoren- als auch in der Veröffentlichungsinstanz von AEM ausgeführt wird. Sie müssen lediglich das Wartungsfenster während eines Zeitraums mit der geringsten Benutzeraktivität definieren. Sie können die Online-Revisionsbereinigung wie folgt konfigurieren:
-
Wechseln Sie im AEM-Hauptfenster zu Tools > Vorgänge > Dashboard > Wartung oder öffnen Sie im Browser die URL:
https://serveraddress:serverport/libs/granite/operations/content/maintenance.html
-
Zeigen Sie mit der Maus auf Tägliches Wartungsfenster und klicken Sie auf das Symbol für Einstellungen.
-
Geben Sie die gewünschten Werte (Wiederholung, Startzeit, Endzeit) ein und klicken Sie auf Speichern.
Wenn Sie die Revisionsbereinigung manuell durchführen möchten, gehen Sie wie folgt vor:
-
Wechseln Sie zu Tools > Vorgänge > Dashboard > Wartung oder direkt zu
https://serveraddress:serverport/libs/granite/operations/content/maintenance.html
. -
Klicken Sie auf Tägliches Wartungsfenster.
-
Zeigen Sie mit der Maus auf das Symbol für Revisionsbereinigung.
-
Klicken Sie auf Ausführen.
Ausführen der Online-Revisionsbereinigung nach der Offline-Revisionsbereinigung running-online-revision-cleanup-after-offline-revision-cleanup
Der Revisionsbereinigungsprozess gewinnt alte Revisionen generationsweise zurück. Das bedeutet, dass jedes Mal, wenn Sie die Revisionsbereinigung ausführen, eine neue Generierung erstellt und auf der Festplatte gespeichert wird. Die beiden Typen der Revisionsbereinigung unterscheiden sich: Bei der Offline-Revisionsbereinigung wird eine Generation aufbewahrt, während bei der Online-Revisionsbereinigung zwei Generationen aufbewahrt werden. Wenn Sie also nach einer Offline-Revisionsbereinigung eine Online-Revisionsbereinigung durchführen, passiert Folgendes:
- Nach dem ersten Durchlauf der Online-Revisionsbereinigung verdoppelt sich die Größe des Repositorys. Dies geschieht, weil jetzt zwei Generationen auf der Festplatte aufbewahrt werden.
- Während der nachfolgenden Ausführungen wächst das Repository, solange die neue Generation erstellt wird, und stabilisiert sich dann wieder bei der Größe, die es nach dem ersten Durchlauf hatte, sobald der Online-Revisionsbereinigungsprozess die vorherige Generation zurückgewinnt.
Beachten Sie außerdem, dass je nach Typ und Anzahl der Commits jede Generierung im Vergleich zum vorherigen unterschiedlich groß sein kann, sodass die endgültige Größe von einer Ausführung zur anderen variieren kann.
Es empfiehlt sich deswegen, eine Festplatte zu wählen, die mindestens zwei- oder dreimal so groß ist wie die ursprünglich geschätzte Repository-Größe.
Vollständiger und Tail-Komprimierungsmodus full-and-tail-compaction-modes
Mit AEM 6.4 werden zwei neue Modi für die Komprimierungsphase des Online-Revisionsbereinigungsprozesses eingeführt:
- Der Modus für die vollständige Komprimierung schreibt alle Segmente und TAR-Dateien im gesamten Repository neu. Die nachfolgende Bereinigungsphase kann somit die maximale Menge an Speicherabfall im Repository entfernen. Da die vollständige Komprimierung sich auf das gesamte Repository auswirkt, ist eine beträchtliche Menge an Systemressourcen und Zeit zum Abschluss erforderlich. Die vollständige Komprimierung entspricht der Komprimierungsphase in AEM 6.3.
- Der Modus Tail-Komprimierung schreibt nur die aktuellsten Segmente und TAR-Dateien im Repository neu. Die neuesten Segmente und TAR-Dateien sind diejenigen, die seit der letzten vollständigen oder Tail-Komprimierung hinzugefügt wurden. Die nachfolgende Bereinigungsphase kann daher nur den im aktuellen Teil des im Repository enthaltenen Speicherabfall entfernen. Da die Tail-Komprimierung nur einen Teil des Repositorys betrifft, benötigt sie erheblich weniger Systemressourcen und Zeit als eine vollständige Komprimierung.
Diese Komprimierungsmodi stellen einen Kompromiss zwischen Effizienz und Ressourcenverbrauch dar: Die Tail-Komprimierung ist zwar weniger effektiv, hat dafür aber weniger Auswirkungen auf den normalen Systembetrieb. Die vollständige Komprimierung ist effektiver, hat aber auch wesentlich größere Auswirkungen auf den normalen Systembetrieb.
AEM 6.4 bietet bei der Komprimierung außerdem einen effizienteren Mechanismus für die Deduplizierung des Inhalts, was den Speicherbedarf des Repositorys weiter verringert.
Die beiden folgenden Diagramme enthalten die Ergebnisse aus internen Laborversuchen, die die Reduzierung der durchschnittlichen Ausführungszeiten und des durchschnittlichen Festplattenspeicherbedarfs in AEM 6.4 im Vergleich zu AEM 6.3 aufzeigen:
Konfigurieren der vollständigen und Tail-Komprimierung how-to-configure-full-and-tail-compaction
Bei der Standardkonfiguration wird eine Tail-Komprimierung an Wochentagen und eine vollständige Komprimierung an Sonntagen durchgeführt. Die Standardkonfiguration kann über den neuen Konfigurationswert full.gc.days
der RevisionCleanupTask
-Wartungsaufgabe geändert werden.
Wenn Sie den Wert full.gc.days
konfigurieren, beachten Sie, dass die vollständige Komprimierung während der mit diesem Wert definierten Tage ausgeführt wird und die Tail-Komprimierung während der nicht mit diesem Wert definierten Tage. Wenn Sie beispielsweise die vollständige Komprimierung so konfigurieren, dass sie am Sonntag ausgeführt wird, wird die Tail-Komprimierung von Montag bis Samstag ausgeführt. Wenn Sie beispielsweise die vollständige Komprimierung so konfigurieren, dass sie an jedem Wochentag ausgeführt wird, wird die Tail-Komprimierung überhaupt nicht ausgeführt.
Berücksichtigen Sie zusätzlich Folgendes:
- Die Tail-Komprimierung ist weniger effektiv und hat weniger Auswirkungen auf den normalen Systembetrieb. Sie sollte daher an den Werktagen ausgeführt werden.
- Die vollständige Komprimierung ist effektiver, hat aber auch wesentlich größere Auswirkungen auf den normalen Systembetrieb. Sie ist daher zur Verwendung außerhalb der Werktage vorgesehen.
- Sowohl die Tail-Komprimierung als auch die vollständige Komprimierung sollte außerhalb der Spitzenzeiten ausgeführt werden.
Fehlerbehebung troubleshooting
Beachten Sie bei der Verwendung der neuen Komprimierungsmodi Folgendes:
- Sie können die Eingabe/Ausgabe-Aktivität (I/O) überwachen, z. B.: I/O-Vorgänge, CPU wartet auf IO, Commit-Warteschlangengröße. Auf diese Weise können Sie feststellen, ob das System I/O-gebunden wird und eine Vergrößerung erforderlich ist.
- Der
RevisionCleanupTaskHealthCheck
zeigt den Gesamtzustand der Online-Revisionsbereinigung. Es funktioniert genauso wie in AEM 6.3 und unterscheidet nicht zwischen vollständiger und Tail-Komprimierung. - Die Protokollmeldungen enthalten relevante Informationen über die Komprimierungsmodi. Wenn beispielsweise die Online-Revisionsbereinigung beginnt, zeigen die entsprechenden Protokollmeldungen den Komprimierungsmodus an. In einigen Fällen wird das System außerdem zur vollständigen Komprimierung zurückgesetzt, wenn eine Tail-Komprimierung geplant ist. Die Protokollmeldungen zeigen diese Änderung an. Die folgenden Protokollbeispiele zeigen den Komprimierungsmodus und den Wechsel von der Tail-Komprimierung zur vollständigen Komprimierung an:
TarMK GC: running tail compaction
TarMK GC: no base state available, running full compaction instead
Bekannte Einschränkungen known-limitations
In einigen Fällen verzögert der Wechsel zwischen dem Tail- und dem vollständigen Komprimierungsmodus den Bereinigungsprozess. Genauer gesagt wächst das Repository nach einer vollständigen Komprimierung (es verdoppelt sich die Größe). Der zusätzliche Speicherplatz wird bei der nachfolgenden Tail-Komprimierung zurückgewonnen, wenn das Repository unter die Größe vor der vollständigen Komprimierungsgröße fällt. Das parallele Durchführen von Wartungsaufgaben sollte ebenfalls vermieden werden.
Es empfiehlt sich, eine Festplatte zu wählen, die mindestens zwei- oder dreimal so groß ist wie die ursprünglich geschätzte Repository-Größe.
Häufig gestellte Fragen zur Online-Revisionsbereinigung online-revision-cleanup-frequently-asked-questions
Aspekte der AEM 6.4-Aktualisierung aem-upgrade-considerations
Migrieren zum Oak-Segment-TAR migrating-to-oak-segment-tar
Ausführen der Online-Revisionsbereinigung running-online-revision-cleanup
Überwachen der Online-Revisionsbereinigung monitoring-online-revision-cleanup
Fehlerbehebung bei der Online-Revisionsbereinigung troubleshooting-online-revision-cleanup
Fehlerbehebung basierend auf Fehlermeldungen troubleshooting-based-on-error-messages
Die error.log-Einträge sind ausführlich, falls es bei der Online-Revisionsbereinigung Probleme gab. In der folgenden Matrix werden die häufigsten Fehlermeldungen und mögliche Lösungen erläutert:
Ausführen der Offline-Revisionsbereinigung how-to-run-offline-revision-cleanup
-
Für Oak-Versionen 1.0.0 bis 1.0.11 oder 1.1.0 bis 1.1.6 verwenden Sie die oak-run-Version 1.0.11.
-
Für neuere Oak-Versionen verwenden Sie die oak-run-Version, die dem Oak-Core der AEM-Installation entspricht.
Adobe stellt das Tool oak-run für das Ausführen der Revisionsbereinigung bereit. Es kann unter folgender URL heruntergeladen werden:
https://repo1.maven.org/maven2/org/apache/jackrabbit/oak-run/
Das Tool ist eine ausführbare JAR-Datei, die manuell ausgeführt werden kann, um das Repository zu komprimieren. Dieser Vorgang wird als Offline-Revisionsbereinigung bezeichnet, da das Repository zum korrekten Ausführen des Tools heruntergefahren werden muss. Planen Sie die Bereinigung entsprechend Ihrem Wartungsfenster.
Tipps, wie Sie die Leistung des Bereinigungsvorgangs steigern können, finden Sie unter Steigern der Leistung der Offline-Revisionsbereinigung.
-
Stellen Sie stets sicher, dass Sie über eine aktuelle Sicherung der AEM-Instanz verfügen.
Fahren Sie AEM herunter.
-
(Optional) Verwenden Sie das Tool, um alte Checkpoints zu finden:
code language-xml java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore
-
(Optional) Löschen Sie dann die nicht referenzierten Checkpoints:
code language-xml java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore rm-unreferenced
-
Führen Sie die Komprimierung aus und warten Sie, bis sie abgeschlossen ist:
code language-xml java -jar -Dsun.arch.data.model=32 oak-run.jar compact install-folder/crx-quickstart/repository/segmentstore
Erhöhen der Leistung der Offline-Revisionsbereinigung increasing-the-performance-of-offline-revision-cleanup
Das Oak-run-Tool führt mehrere Funktionen ein, die die Leistung des Revisionsbereinigungsprozesses steigern und das Wartungsfenster so weit wie möglich minimieren sollen.
Die Liste enthält mehrere Befehlszeilenparameter, wie unten beschrieben:
-
-mmap. Sie können für diese Option „true“ oder „false“ festlegen. Wenn dies auf „true“ festgelegt ist, wird der Zugriff mit Speicherzuordnung verwendet. Wenn dies auf „false“ festgelegt ist, wird der Dateizugriff verwendet. Wenn kein Wert angegeben ist, wird auf 64-Bit-Systemen der Zugriff mit Speicherzuordnung und auf 32-Bit-Systemen der Dateizugriff verwendet. Unter Windows wird immer der reguläre Dateizugriff erzwungen, sodass diese Option ignoriert wird. Dieser Parameter ersetzt den Parameter -Dtar.memoryMapped.
-
-Dupdate.limit. Definiert den Schwellenwert für das Leeren einer temporären Transaktion auf die Festplatte. Der Standardwert ist 10.000.
-
-Dcompress-interval. Anzahl der Komprimierungszuordnungseinträge, die bis zum Komprimieren der aktuellen Zuordnung beibehalten werden sollen. Der Standardwert ist 1.000.000. Sie sollten diesen Wert auf eine noch höhere Zahl erhöhen, um einen schnelleren Durchsatz zu erzielen, wenn ausreichend Heap-Speicher verfügbar ist. Dieser Parameter wurde in der Oak-Version 1.6 entfernt und hat keine Auswirkung.
-
-Dcompaction-progress-log. Die Anzahl der komprimierten Knoten, die protokolliert werden. Der Standardwert ist 150.000, d. h., die ersten 150.000 komprimierten Knoten werden bei einem Vorgang protokolliert. Verwenden Sie dies in Verbindung mit dem nächsten Parameter, der im Folgenden dokumentiert ist.
-
-Dtar.PersistCompactionMap. Legen Sie für diesen Parameter „true“ fest, um Festplattenspeicher statt Heap-Speicher für eine persistente Komprimierungszuordnung zu verwenden. Erfordert Version 1.4 und höher des Tools „oak-run“. Weitere Informationen finden Sie unter Frage 3 im Abschnitt Häufig gestellte Fragen zur Offline-Revisionsbereinigung. Dieser Parameter wurde in der Oak-Version 1.6 entfernt und hat keine Auswirkung.
-
–force. Erzwingt die Komprimierung und ignoriert eine nicht übereinstimmende Segmentspeicherversion.
--force
wird der Segmentspeicher auf die neueste Version aktualisiert, die nicht mit älteren Oak-Versionen kompatibel ist. Beachten Sie auch, dass kein Downgrade möglich ist. In der Regel sollten Sie diese Parameter mit Vorsicht verwenden und sie nur nutzen, wenn Sie sich mit ihrer Verwendung auskennen.Ein Beispiel für die verwendeten Parameter:
java -Dupdate.limit=10000 -Dcompaction-progress-log=150000 -Dlogback.configurationFile=logback.xml -Xmx8g -jar oak-run-*.jar checkpoints <repository>
Zusätzliche Methoden zum Auslösen der Revisionsbereinigung additional-methods-of-triggering-revision-cleanup
Zusätzlich zu den oben beschriebenen Methoden können Sie den Revisionsbereinigungsmechanismus auch wie folgt mithilfe der JMX-Konsole auslösen:
- Öffnen Sie die JMX-Konsole, indem Sie zu http://localhost:4502/system/console/jmx wechseln.
- Klicken Sie auf MBean RevisionGarbageCollection.
- Klicken Sie im nächsten Fenster auf startRevisionGC() und dann auf Invoke, um den Vorgang der Revisionsbereinigung zu starten.