Revisionsbereinigung

Letzte Aktualisierung: 2024-02-21

Einführung

Jede Aktualisierung des Repositorys erzeugt eine Inhaltsrevision. Daher wächst das Repository nach jeder Aktualisierung. Alte Revisionen müssen bereinigt werden, um Festplattenressourcen freizugeben - dies ist wichtig, um ein unkontrolliertes Repository-Wachstum zu vermeiden. Diese Wartungsfunktionalität wird als Revisionsbereinigung bezeichnet. Es ist seit Adobe Experience Manager (AEM) 6.0 als Offline-Routine verfügbar.

Mit AEM 6.3 und höher 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, compaction, und bereinigen. 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 dann die alten Segmente entfernt, einschließlich aller darin enthaltenen Speicherbereinigungen. Der Offline-Modus kann in der Regel mehr Speicherplatz zurückgewinnen, da der Online-Modus AEM Arbeitsset berücksichtigen muss, in dem zusätzliche Segmente nicht erfasst werden.

Weitere Informationen zur Revisionsbereinigung finden Sie unter den folgenden Links:

Sie können auch die offizielle Oak-Dokumentation.

Wann sollte die Online-Revisionsbereinigung anstelle der Offline-Revisionsbereinigung verwendet werden?

Die Online-Revisionsbereinigung ist die empfohlene Methode zur Durchführung der Revisionsbereinigung. Die Offline-Revisionsbereinigung sollte nur in Ausnahmefällen verwendet werden, z. B. vor der Migration zum neuen Speicherformat oder auf Anforderung der Adobe-Kundenunterstützung.

Ausführen der Online-Revisionsbereinigung

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:

  1. 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

    chlimage_1-90

  2. Zeigen Sie mit der Maus auf Tägliches Wartungsfenster und klicken Sie auf das Symbol für Einstellungen.

    chlimage_1-91

  3. Geben Sie die gewünschten Werte (Wiederholung, Startzeit, Endzeit) ein und klicken Sie auf Speichern.

    chlimage_1-92

Wenn Sie die Revisionsbereinigung manuell durchführen möchten, gehen Sie wie folgt vor:

  1. Wechseln Sie zu Tools > Vorgänge > Dashboard > Wartung oder direkt zu https://serveraddress:serverport/libs/granite/operations/content/maintenance.html.

  2. Klicken Sie auf Tägliches Wartungsfenster.

  3. Zeigen Sie mit der Maus auf das Symbol für Revisionsbereinigung.

  4. Klicken Sie auf Ausführen.

    chlimage_1-93

Ausführen der Online-Revisionsbereinigung nach der Offline-Revisionsbereinigung

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:

  1. Nach der ersten Online-Revisionsbereinigung verdoppelt sich die Repository-Größe. Dies geschieht, weil jetzt zwei Generationen auf der Festplatte aufbewahrt werden.
  2. 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

Mit AEM 6.5 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, erfordert sie eine beträchtliche Menge an Systemressourcen und Zeit zum Abschluss. 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, sind deutlich weniger Systemressourcen und Zeit zum Abschluss erforderlich als die 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.5 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.5 im Vergleich zu AEM 6.3 aufzeigen:

onrc-duration-6_4vs63 segmentstore-6_4vs63

Konfigurieren der vollständigen und Tail-Komprimierung

Die Standardkonfiguration führt eine Tail-Komprimierung an Werktagen und eine vollständige Komprimierung an Sonntagen durch. Die Standardkonfiguration kann über den neuen Konfigurationswert full.gc.days der RevisionCleanupTask-Wartungsaufgabe geändert werden.

Wenn Sie die full.gc.days -Wert, wird die vollständige Komprimierung während der in der Wert definierten Tage ausgeführt und die Tail-Komprimierung wird während der Tage ausgeführt, die nicht im Wert definiert sind. 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.

Beachten Sie außerdem Folgendes:

  • Die Tail-Komprimierung ist weniger effektiv und hat weniger Auswirkungen auf den normalen Systembetrieb. Sie sollte daher an den Werktagen ausgeführt werden.
  • Vollständige Komprimierung ist effektiver, hat aber auch 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

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 kehrt das System außerdem zur vollständigen Komprimierung zurück, wenn eine Tail-Komprimierung geplant war. 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

Manchmal 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 in der Größe). Der zusätzliche Speicherplatz wird bei der nachfolgenden Tail-Komprimierung zurückgewonnen, wenn das Repository unter die vorausgefüllte 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

Aspekte der AEM 6.5-Aktualisierung

Fragen Antworten
Was muss ich beachten, wenn ich auf AEM 6.5 aktualisiere?

Das Persistenzformat von TarMK ändert sich mit AEM 6.5. Für diese Änderungen ist kein proaktiver Migrationsschritt erforderlich. Vorhandene Repositorys durchlaufen eine rollierende Migration, die für den Benutzer transparent ist. Der Migrationsprozess wird initiiert, wenn AEM 6.5 (oder zugehörige Tools) zum ersten Mal auf das Repository zugreifen.

Nachdem die Migration zum Persistenzformat AEM 6.5 eingeleitet wurde, kann das Repository nicht mehr auf das Persistenzformat AEM 6.3 zurückgesetzt werden.

Migrieren zum Oak-Segment-TAR

Fragen Antworten
Warum muss ich das Repository migrieren?

In AEM 6.3 mussten Änderungen am Speicherformat durchgeführt werden, um insbesondere die Leistung und die Effektivität der Online-Revisionsbereinigung zu verbessern. Diese Änderungen sind nicht abwärtskompatibel, und Repositorys, die mit dem alten Oak-Segment (AEM 6.2 und früher) erstellt wurden, müssen migriert werden.

Weitere Vorteile der Änderung des Speicherformats:

  • Bessere Skalierbarkeit (optimierte Segmentgröße).
  • Schnellere Datenspeicherbereinigung.
  • Grundlage für zukünftige Verbesserungen.
Wird das vorherige TAR-Format weiterhin unterstützt? Nur das neue Oak Segment Tar wird von AEM 6.3 oder höher unterstützt.
Ist die Migration des Inhalts immer obligatorisch? Ja. Wenn Sie nicht mit einer neuen Instanz beginnen, müssen Sie den Inhalt immer migrieren.
Kann ich auf 6.3 oder höher aktualisieren und die Migration zu einem späteren Zeitpunkt durchführen (zum Beispiel in einem anderen Wartungsfenster)? Nein, wie oben beschrieben, ist die Migration obligatorisch.
Kann die Ausfallzeit für die Migration vermieden werden? Nein. Dies ist ein einmaliger Aufwand, der nicht auf einer laufenden Instanz ausgeführt werden kann.
Was passiert, wenn ich versehentlich das falsche Repository-Format verwende? Wenn Sie versuchen, das Oak-Segment-Modul für ein Oak-Segment-Tar-Repository auszuführen (oder umgekehrt), schlägt der Start mit einem IllegalStateException mit der Meldung "Ungültiges Segmentformat". Es gibt keine Datenbeschädigung.
Müssen die Suchindizes neu indiziert werden? Nein. Bei der Migration vom Oak-Segment-Format zum Oak-Segment-Tar-Format findet eine Änderung des Container-Formats statt. Die enthaltenen Daten sind davon nicht betroffen und werden nicht geändert.
Wie kann ich den während und nach der Migration erforderlichen Speicherplatz am besten berechnen? Die Migration entspricht der Neuerstellung des Segmentspeichers in dem neuen Format. Auf Basis dieser Annahme können Sie den zusätzlich für die Migration erforderlichen Festplattenspeicher berechnen. Nach der Migration kann der alte Segmentspeicher gelöscht werden, um Speicherplatz zurückzugewinnen.
Wie kann ich die Dauer der Migration am besten abschätzen? Die Migrationsleistung kann erheblich verbessert werden, wenn vor der Migration eine Offline-Revisionsbereinigung durchgeführt wird. Allen Kunden wird empfohlen, diese als Voraussetzung für die Aktualisierung auszuführen. Im Allgemeinen sollte die Dauer der Migration der Dauer der Aufgabe zur Bereinigung der Offline-Revision ähnlich sein, vorausgesetzt, dass die Aufgabe zur Bereinigung der Offline-Revision vor der Migration ausgeführt wurde.

Ausführen der Online-Revisionsbereinigung

Fragen Antworten
Wie oft sollte die Online-Revisionsbereinigung durchgeführt werden? Einmal pro Tag. Dies ist die Standardkonfiguration im Vorgangs-Dashboard.
Wie kann ich die Startzeit der Wartungsaufgabe für die Online-Revisionsbereinigung konfigurieren? Hierzu finden Sie Informationen im Abschnitt Ausführen der Online-Revisionsbereinigung.
Gibt es für die Online-Revisionsbereinigung eine maximale Frequenz, die nicht überschritten werden sollte? Es wird empfohlen, die Online-Revisionsbereinigung einmal täglich auszuführen, wie dies standardmäßig konfiguriert ist.
Welche Indikatoren sind für die Frequenz entscheidend, in der die Online-Revisionsbereinigung ausgeführt werden sollte? Es ist nicht notwendig, die Frequenz zu ermitteln, da die Online-Revisionsbereinigung als Wartungsaufgabe konfiguriert ist und täglich automatisch ausgeführt wird.
Warum gewinnt die Online-Revisionsbereinigung keinen Speicherplatz zurück, wenn sie das erste Mal ausgeführt wird? Die Online-Revisionsbereinigung gewinnt alte Revisionen generationsweise zurück. Bei jeder Ausführung der Revisionsbereinigung wird eine neue Generierung erzeugt. Nur Inhalte, die mindestens zwei Generationen alt sind, werden zurückgewonnen, was bedeutet, dass bei einem ersten Durchlauf nichts zurückgewonnen werden kann.
Warum gewinnt die erste Online-Revisionsbereinigung keinen Speicherplatz zurück, wenn sie nach der Offline-Revisionsbereinigung ausgeführt wird?

Die Offline-Revisionsbereinigung gewinnt alles zurück bis auf die neueste Generierung, im Vergleich zu den letzten zwei Generierungen für die Online-Revisionsbereinigung. Wenn ein neues Repository vorhanden ist, wird bei der Online-Revisionsbereinigung kein Speicherplatz zurückgewonnen, wenn sie zum ersten Mal nach der Offline-Revisionsbereinigung ausgeführt wird, da keine Generation alt genug ist, um zurückgewonnen zu werden.

Lesen Sie auch den Abschnitt "Ausführen der Online-Revisionsbereinigung nach der Offline-Revisionsbereinigung"von dieses Kapitels.

Haben Autoren- und Veröffentlichungsumgebungen in der Regel verschiedene Fenster für die Online-Revisionsbereinigung? Dies hängt von den Arbeitszeiten und den Traffic-Mustern der Online-Präsenz für Kunden ab. Die Wartungsfenster sollten außerhalb der Hauptproduktionszeiten liegen, um die Bereinigung so effizient wie möglich durchzuführen. Bei mehreren AEM-Veröffentlichungsinstanzen (TarMK-Farm) empfiehlt es sich, die Wartungsfenster für die Online-Revisionsbereinigung zu staffeln.
Müssen vor dem Ausführen der Online-Revisionsbereinigung irgendwelche Voraussetzungen erfüllt sein?

Die Online-Revisionsbereinigung ist nur mit AEM 6.3 und höheren Versionen verfügbar. Wenn Sie eine ältere Version von AEM verwenden, müssen Sie zum neuen Oak-Segment-Tar.

Welche Faktoren bestimmen die Dauer der Online-Revisionsbereinigung? Die Faktoren sind:
  • Repository-Größe
  • Systemlast (Anforderungen pro Minute, insbesondere Schreibvorgänge)
  • Aktivitätsmuster (Lese- und Schreibvorgänge)
  • Hardware-Spezifikationen (CPU-Leistung, Speicher, IOPS)
Können Autoren weiterarbeiten, während die Online-Revisionsbereinigung läuft? Ja, die Online-Revisionsbereinigung kann gleichzeitige Schreibvorgänge handhaben. Die Online-Revisionsbereinigung funktioniert jedoch schneller und effizienter ohne gleichzeitige Schreibvorgänge. Adobe empfiehlt, die Wartungsaufgabe für die Online-Revisionsbereinigung auf eine relativ ruhige Zeit ohne viel Traffic zu planen.
Welche Mindestanforderungen gelten für Festplatten- und Heap-Speicher, wenn die Online-Revisionsbereinigung ausgeführt wird?

Der Festplattenspeicher wird während der Online-Revisionsbereinigung kontinuierlich überwacht. Wenn der verfügbare Speicherplatz unter einen kritischen Wert fällt, wird der Prozess abgebrochen. Dieser kritische Wert beträgt 25 % des aktuell belegten Speicherplatzes des Repositorys und kann nicht konfiguriert werden.

Adobe empfiehlt, die Festplatte mindestens zwei- oder dreimal größer als die ursprünglich geschätzte Repository-Größe zu gestalten.

Der verfügbare Heap-Speicher wird während des Bereinigungsprozesses kontinuierlich überwacht. Wenn der freie Heap-Speicher unter einen kritischen Wert fällt, wird der Prozess abgebrochen. Der kritische Wert wird über org.apache.jackrabbit.oak.segment.SegmentNodeStoreService#MEMORY_THRESHOLD konfiguriert. Der Standardwert ist 15 %.

Es gibt keine separaten Empfehlungen für die Mindestkomprimierung der Heap-Speichergröße zusätzlich zu den Empfehlungen für die AEM-Speichergröße. Allgemein: Wenn eine AEM Instanz so groß ist, dass sie die Anwendungsfälle und die erwartete Nutzlast bewältigen kann, erhält der Bereinigungsprozess genügend Arbeitsspeicher.

Mit welcher Auswirkung auf die Leistung muss beim Ausführen der Online-Revisionsbereinigung gerechnet werden? Die Online-Revisionsbereinigung ist ein Hintergrundprozess, der gleichzeitig aus dem Repository liest und in das Repository schreibt, parallel zu den normalen Systemvorgängen. Insbesondere muss sie möglicherweise für einen kurzen Zeitraum exklusiven Zugriff auf das Repository erhalten, wodurch verhindert wird, dass andere Threads in das Repository schreiben.
Wie lange dauert die Ausführung der Online-Revisionsbereinigung erwartungsgemäß? Es sollte nicht länger als zwei Stunden dauern, bis das Adobe gemäß den neuesten Leistungstests durchgeführt wird, die intern durchgeführt wurden.
Was muss getan werden, wenn die Online-Revisionsbereinigung länger dauert?
  • Stellen Sie sicher, dass sie täglich ausgeführt wird.
  • Stellen Sie sicher, dass sie bei minimaler Repository-Aktivität ausgeführt wird, indem Sie die Wartungsfenster im Vorgangs-Dashboard entsprechend konfigurieren.
  • Vergrößern Sie die Systemressourcen (CPU, Arbeitsspeicher, E/A).
Was passiert, wenn die Online-Revisionsbereinigung das konfigurierte Wartungsfenster überschreitet? Stellen Sie sicher, dass andere Wartungsaufgaben die Ausführung nicht verzögern. Dies kann der Fall sein, wenn innerhalb desselben Wartungsfensters noch andere Wartungsaufgaben als die Online-Revisionsbereinigung ausgeführt werden. Wartungsaufgaben werden nacheinander ohne konfigurierbare Reihenfolge ausgeführt.
Warum wird die Revisionsbereinigung übersprungen?

Die Revisionsbereinigung beruht auf einer Schätzungsphase, in der entschieden wird, ob ausreichend Datenabfall zur Bereinigung vorhanden ist. Bei der Schätzung wird die aktuelle Größe mit der Größe des Repositorys nach der letzten Komprimierung verglichen. Wenn die Größe das konfigurierte Delta überschreitet, wird die Bereinigung ausgeführt. Der Deltawert für die Größe beträgt 1 GB. Dies bedeutet im Grunde, dass die neue Revisionsbereinigungs-Iteration übersprungen wird, wenn die Repository-Größe seit dem letzten Bereinigungsvorgang nicht um 1 GB gewachsen ist.

Unten sehen Sie die für die Schätzungsphase relevanten Protokolleinträge:

  • Revisionsbereinigung wird ausgeführt: Delta-Größe ist N% oder N/N (N/N Byte), daher laufende Komprimierung
  • Revision GC führt not run: Delta-Größe ist N% oder N/N (N/N Byte), daher wird die Komprimierung für jetzt übersprungen
Kann die automatische Komprimierung abgebrochen werden, falls die Auswirkung auf die Leistung zu groß ist? Ja. Seit AEM 6.3 kann sie über das Wartungsaufgaben-Fenster im Vorgangs-Dashboard oder über JMX sicher angehalten werden.
Wenn die AEM-Instanz während einer geplanten Bereinigungsaufgabe heruntergefahren wird, wird der Prozess dann sicher abgebrochen oder wird das Herunterfahren blockiert, bis die Komprimierung abgeschlossen ist? Die Revisionsbereinigung wird unterbrochen und das Repository wird sicher heruntergefahren.
Was passiert, wenn das System während der Online-Revisionsbereinigung abstürzt? In solchen Fällen besteht keine Gefahr einer Datenbeschädigung. Abfallreste werden durch einen nachfolgenden Lauf bereinigt.
Welche Folgen hat es, wenn die Online-Revisionsbereinigung nicht ausgeführt wird? Die Leistung verschlechtert sich mit der Zeit.
Welche Revisionen werden erfasst? Standardmäßig erfasst die Online-Revisionsbereinigung nur Revisionen, die mindestens 24 Stunden alt sind.
Was passiert, wenn zu viele Interferenzen von gleichzeitigen Schreibvorgängen in das Repository auftreten?

Wenn im System gleichzeitige Schreibvorgänge stattfinden, benötigt die Online-Revisionsbereinigung möglicherweise einen exklusiven Schreibzugriff, um die Änderungen am Ende eines Komprimierungszyklus zu übermitteln. Das System wird forceCompact-Modus, wie im Abschnitt Oak-Dokumentation. Während der erzwungenen Komprimierung wird eine exklusive Schreibsperre erworben, um die Änderungen endgültig zu übernehmen, ohne dass gleichzeitig Schreibvorgänge stören. Um die Auswirkungen auf die Antwortzeiten zu begrenzen, kann ein Zeitlimitwert definiert werden. Dieser Wert wird standardmäßig auf eine Minute gesetzt. Wenn die erzwungene Komprimierung nicht innerhalb einer Minute abgeschlossen ist, wird der Komprimierungsprozess zugunsten gleichzeitiger Commits abgebrochen.

Die Dauer der erzwungenen Komprimierung hängt von folgenden Faktoren ab:

  • Hardware: speziell IOPS. Die Dauer nimmt mit zunehmenden IOPS ab.
  • Segmentspeichergröße: Die Dauer steigt mit der Größe des Segmentspeichers.

Wie wird die Online-Revisionsbereinigung auf einer Standby-Instanz ausgeführt?

Bei einem Cold-Standby-Setup muss nur die primäre Instanz für die Ausführung der Online-Revisionsbereinigung konfiguriert werden. Auf der Standby-Instanz muss die Online-Revisionsbereinigung nicht explizit geplant werden.

Der entsprechende Vorgang auf der Standby-Instanz ist die automatische Bereinigung; diese entspricht der Bereinigungsphase der Online-Revisionsbereinigung. Die automatische Bereinigung wird auf der Standby-Instanz ausgeführt, nachdem die Online-Revisionsbereinigung auf der primären Instanz ausgeführt wurde.

Schätzungs- und Komprimierungsphasen werden nicht auf einer Standby-Instanz ausgeführt.

Kann die Offline-Revisionsbereinigung mehr Speicherplatz freigeben als die Online-Revisionsbereinigung?

Bei der Offline-Revisionsbereinigung können alte Revisionen sofort entfernt werden, während bei der Online-Revisionsbereinigung alte Revisionen berücksichtigt werden müssen, auf die noch vom Anwendungsstapel verwiesen wird. Ersteres kann so den Müll aggressiver beseitigen als Letzteres, wo der Effekt über einige Speicherbereinigungszyklen amortisiert wird.

Lesen Sie auch den Abschnitt "Ausführen der Online-Revisionsbereinigung nach der Offline-Revisionsbereinigung"von dieses Kapitels.

Gibt es Aspekte, die bei Dateioperationen mit Speicherzuordnung beachtet werden müssen?
  • In Windows-Umgebungen wird immer der reguläre Dateizugriff erzwungen, weshalb keine Speicherzuordnung verwendet wird. Ganz allgemein sollte der gesamte verfügbare RAM-Speicher dem Heap zugewiesen und die segmentCache-Größe erhöht werden. Um die segmentCache-Größe zu erhöhen, fügen Sie die Option segmentCache.size zu org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config hinzu (z. B. segmentCache.size=20480). Denken Sie daran, auch RAM für das Betriebssystem und andere Prozesse einzuplanen.
  • In Nicht-Windows-Umgebungenerhöhen Sie die Größe des physischen Speichers, um die Speicherzuordnung des Repositorys zu verbessern.

Überwachen der Online-Revisionsbereinigung

Was muss während der Online-Revisionsbereinigung überwacht werden?
  • Wenn die Online-Revisionsbereinigung aktiviert ist, sollte der Festplattenspeicher überwacht werden. Die Bereinigung wird nicht ausgeführt oder sie wird vorzeitig beendet, wenn nicht genügend Festplattenspeicher vorhanden ist.
  • Überprüfen Sie die Protokolldateien auf die Ausführungsdauer der Online-Revisionsbereinigung. Sie sollte nicht länger als zwei Stunden in Anspruch nehmen.
  • Anzahl der Prüfpunkte. Falls bei der Komprimierung mehr als drei Prüfpunkte auftreten, wird empfohlen, die Prüfpunkte zu bereinigen.
Wie kann überprüft werden, ob die Online-Revisionsbereinigung erfolgreich abgeschlossen wurde?

Sie können überprüfen, ob die Online-Revisionsbereinigung erfolgreich abgeschlossen wurde, indem Sie die Protokolle überprüfen.

Beispiel: „TarMK GC #{}: compaction completed in {} ({} ms), after {} cycles“ bedeutet, dass der Komprimierungsschritt erfolgreich abgeschlossen wurde, es sei denn, vorher wurde die Meldung „TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles“ angezeigt. Sie bedeutet, dass die gleichzeitige Last zu hoch war.

Dementsprechend gibt es die Meldung „TarMK GC #{}: cleanup completed in {} ({} ms“ für den erfolgreichen Abschluss des Bereinigungsschritts.

Wo finden wir die Statistiken der letzten Online-Revisionsbereinigungen?

Status, Fortschritt und Statistiken werden über JMX (SegmentRevisionGarbageCollection MBean) Weitere Informationen zu MBean SegmentRevisionGarbageCollection finden Sie im folgenden Absatz.

Der Fortschritt kann wie folgt verfolgt werden: über das Attribut EstimatedRevisionGCCompletion von SegmentRevisionGarbageCollection MBean.

Sie können eine MBean-Referenz mit ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection" abrufen.

Die Statistiken sind erst seit dem letzten Systemstart verfügbar. Mit externen Überwachungstools können die Daten über AEM Betriebszeit hinaus aufbewahrt werden. In der AEM-Dokumentation finden Sie Informationen zum Anhängen von Konsistenzprüfungen an Nagios als Beispiel für ein externes Überwachungs-Tool.

Welche Protokolleinträge sind relevant?
  • Die Online-Revisionsbereinigung wurde gestartet/beendet
    • Die Online-Revisionsbereinigung besteht aus drei Phasen: Schätzung, Komprimierung und Bereinigung. In der Schätzungsphase kann das Überspringen der Komprimierung und Bereinigung erzwungen werden, falls das Repository nicht ausreichend viele alte Daten enthält. In der neuesten Version von AEM markiert die Meldung „TarMK GC #{}: estimation started“ den Beginn der Schätzung, „TarMK GC #{}: compaction started, strategy={}“ markiert den Beginn der Komprimierung und „TarMK GC #{}: cleanup started. Current repository size is {} ({} bytes“ markiert den Beginn der Bereinigung.
  • Durch die Revisionsbereinigung gewonnener Speicherplatz
    • Der Speicherplatz wird erst nach Abschluss der Bereinigungsphase zurückgewonnen. Der Abschluss der Bereinigungsphase wird durch die Protokollmeldung „TarMK GC #{}: cleanup completed in {} ({} ms“ markiert. Größe nach der Bereinigung ist {} ({} Bytes) und zurückgewonnener Platz {} ({} Bytes). Gewicht/Tiefe der Verdichtungskarte ist {}/{} ({} Bytes/{}).".
  • Während der Revisionsbereinigung ist ein Problem aufgetreten
    • Es gibt viele Fehlerbedingungen. Alle sind durch WARN- oder ERROR-Protokollmeldungen gekennzeichnet, die mit „TarMK GC“ beginnen.

Siehe auch Fehlerbehebung basierend auf Fehlermeldungen unten.

Wie kann ich überprüfen, wie viel Speicherplatz nach Abschluss der Online-Revisionsbereinigung zurückgewonnen wurde? Am Ende des Bereinigungszyklus wird im Protokoll die Meldung „TarMK GC #3: cleanup completed“ angezeigt. Sie enthält die Größe des Repositorys und die Menge des zurückgewonnenen Speicherplatzes.
Wie kann die Integrität des Repositorys nach Abschluss der Online-Revisionsbereinigung überprüft werden?

Nach der Online-Revisionsbereinigung ist keine Repository-Integritätsprüfung erforderlich.

Sie können jedoch die folgenden Aktionen ausführen, um den Repository-Status nach der Bereinigung zu überprüfen:

  • Eine Traversal-Überprüfung für das Repository
  • Verwenden Sie das Tool „oak-run“ nach Abschluss des Bereinigungsprozesses, um nach Inkonsistenzen zu suchen. Weitere Informationen hierzu finden Sie in der Apache-Dokumentation. Sie müssen AEM nicht beenden, um das Tool auszuführen.
Wie kann ich feststellen, ob die Online-Revisionsbereinigung fehlgeschlagen ist, und welche Wiederherstellungsschritte sind erforderlich? Fehlerbedingungen sind durch WARN- oder ERROR-Protokollmeldungen gekennzeichnet, die mit „TarMK GC“ beginnen. Siehe auch Fehlerbehebung basierend auf Fehlermeldungen unten.
Welche Daten werden einer Konsistenzprüfiung bei der Online-Revisionsbereinigung unterzogen? Wie und wann tragen sie zu den farbcodierten Statuswerten bei?

Die Konsistenzprüfung der Revisionsbereinigung ist Teil des Vorgangs-Dashboards.

Der Status lautet GRÜNE wenn die letzte Ausführung der Online-Revisionsbereinigung erfolgreich abgeschlossen wurde.

Es ist GELB wenn die Wartungsaufgabe für die Online-Revisionsbereinigung einmal abgebrochen wurde.

Es ist RED wenn die Wartungsaufgabe für die Online-Revisionsbereinigung dreimal hintereinander abgebrochen wurde. In diesem Fall ist eine manuelle Interaktion erforderlich oder die Online-Revisionsbereinigung schlägt wahrscheinlich wieder fehl. Weitere Informationen finden Sie im Abschnitt Fehlerbehebung unten.

Außerdem wird der Status der Konsistenzprüfung nach einem Neustart des Systems zurückgesetzt. Eine neu gestartete Instanz zeigt daher einen grünen Status bei der Konsistenzprüfung der Revisionsbereinigung an. Mit externen Überwachungstools können die Daten über AEM Betriebszeit hinaus aufbewahrt werden. In der AEM-Dokumentation finden Sie Informationen zum Anhängen von Konsistenzprüfungen an Nagios als Beispiel für ein externes Überwachungs-Tool.

Wie wird die automatische Bereinigung auf einer Standby-Instanz überwacht?

Status, Fortschritt und Statistiken werden über JMX mithilfe der Variablen SegmentRevisionGarbageCollection MBean. Siehe auch die folgende Oak-Dokumentation.

Sie können eine MBean-Referenz mit ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection" abrufen.

Die Statistiken sind erst seit dem letzten Systemstart verfügbar. Mit externen Überwachungstools können die Daten über die AEM hinaus aufbewahrt werden. In der AEM-Dokumentation finden Sie Informationen zum Anhängen von Konsistenzprüfungen an Nagios als Beispiel für ein externes Überwachungs-Tool.

Die Protokolldateien können auch verwendet werden, um den Status, den Fortschritt und die Statistiken der automatischen Bereinigung zu überprüfen.

Was muss während der automatischen Bereinigung auf einer Standby-Instanz überwacht werden?

  • Der Festplattenspeicher sollte überwacht werden, wenn die automatische Bereinigung ausgeführt wird.
  • Die Ausführungsdauer (siehe Protokolle) sollte zwei Stunden nicht überschreiten.
  • Die Größe des Segmentspeichers nach der automatischen Bereinigung. Der Segmentspeicher auf der Standby-Instanz sollte ungefähr so groß wie der auf der primären Instanz sein.

Fehlerbehebung bei der Online-Revisionsbereinigung

Was kann schlimmstenfalls passieren, falls die Online-Revisionsbereinigung nicht ausgeführt wird? Der AEM Instanz fehlt der Speicherplatz, was zu Produktionsausfällen führt.
Ist ein hoher Benutzer-Traffic problematisch, wenn ich die Online-Revisionsbereinigung auf einer Veröffentlichungsinstanz ausführen möchte? Hoher Benutzer-Traffic wirkt sich darauf aus, ob die Komprimierungsphase erfolgreich abgeschlossen wird oder nicht.
Gemäß Konsistenzprüfung und Protokolleinträgen ist die Online-Revisionsbereinigung dreimal in Folge fehlgeschlagen. Was ist erforderlich, um die Online-Revisionsbereinigung erfolgreich abzuschließen? Sie können mehrere Schritte ausführen, um das Problem zu finden und zu beheben:
  • Überprüfen Sie zunächst die Protokolleinträge.
  • Gehen Sie je nach den Informationen in den Protokollen wie folgt vor:
    • Falls in den Protokolldateien fünf übersprungene Komprimierungszyklen und eine Zeitüberschreitung beim forceCompact-Zyklus angezeigt werden, planen Sie das Wartungsfenster für einen ruhigen Zeitraum, in dem wenige Schreibvorgänge im Repository erfolgen. Sie können Repository-Schreibvorgänge im Monitoring-Tool für Repository-Metriken unter https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.html
    • Wenn die Bereinigung am Ende des Wartungsfensters angehalten wurde, stellen Sie sicher, dass die Konfiguration des Wartungsfensters in der Benutzeroberfläche für Wartungsaufgaben groß genug ist
    • Wenn der verfügbare Heap-Speicher nicht ausreicht, stellen Sie sicher, dass die Instanz über ausreichend Speicher verfügt.
    • Wenn es zu spät kommt, kann der Segmentspeicher zu stark anwachsen, um die Online-Revisionsbereinigung selbst innerhalb eines längeren Wartungsfensters abzuschließen. Wenn beispielsweise in der letzten Woche keine erfolgreiche Online-Revisionsbereinigung abgeschlossen wurde, wird empfohlen, eine Offline-Wartung zu planen und die Offline-Revisionsbereinigung auszuführen, um den Segmenstore wieder auf eine überschaubare Größe zu bringen.
Was muss getan werden, wenn der Warnhinweis zur Konsistenzprüfung aktiviert ist? Siehe vorherigen Punkt.
Was passiert, wenn die Zeit bei der Online-Revisionsbereinigung in einem geplanten Wartungsfenster überschritten wird? Die Online-Revisionsbereinigung wird abgebrochen und die Reste werden entfernt. Er wird beim nächsten geplanten Wartungsfenster erneut gestartet.
Was verursacht SegmentNotFoundException-Instanzen im error.log-Protokoll und wie erreiche ich eine Wiederherstellung?

A SegmentNotFoundException wird vom TarMK protokolliert, wenn versucht wird, auf eine Speichereinheit (ein Segment) zuzugreifen, die nicht gefunden werden kann. Es gibt drei Szenarien, die dieses Problem verursachen können:

  1. Eine Anwendung, die die empfohlenen Zugriffsmechanismen (wie Sling und die JCR-API) umgeht und eine API/SPI der unteren Ebene verwendet, um auf das Repository zuzugreifen, und dann die Aufbewahrungsdauer eines Segments überschreitet. Das heißt, sie bewahrt einen Verweis auf eine Entität länger auf als die von der Online-Revisionsbereinigung erlaubte Aufbewahrungsdauer (standardmäßig 24 Stunden). Dieser Fall ist vorübergehend und führt nicht zu einer Beschädigung der Daten. Verwenden Sie für die Wiederherstellung das Tool „oak-run“, um den vorübergehenden Status der Ausnahme zu bestätigen (bei der Überprüfung mit „oak-run“ sollten keine Fehler gemeldet werden). Dazu muss die Instanz offline geschaltet und danach neu gestartet werden.
  2. Ein externes Ereignis verursachte die Beschädigung der Daten auf der Festplatte. Dabei kann es sich um einen Datenträgerfehler, ungenügenden Speicherplatz oder eine versehentliche Änderung der erforderlichen Datendateien handeln. In diesem Fall muss die Instanz offline geschaltet und mithilfe der Oak-Run-Prüfung repariert werden. Weitere Informationen zum Ausführen von Prüfungen mit „oak-run“ finden Sie in der Apache-Dokumentation.
  3. Alle anderen Vorkommnisse über die Adobe-Kundenunterstützung.

Fehlerbehebung basierend auf Fehlermeldungen

Die Datei "error.log"ist ausführlich, wenn während des Online-Revisionsbereinigungsprozesses Vorfälle auftreten. In der folgenden Matrix werden die häufigsten Fehlermeldungen und mögliche Lösungen erläutert:

Phase Protokollmeldungen Erklärung Nächste Schritte
Schätzung TarMK GC #2: Schätzung wurde übersprungen, weil die Komprimierung angehalten wurde. Die Schätzungsphase wird übersprungen, wenn die Komprimierung im System durch die Konfiguration deaktiviert ist. Aktivieren Sie die Online-Revisionsbereinigung.
Nicht zutreffend TarMK GC #2: estimation interrupted: ${REASON}. Skipping compaction. Die Schätzungsphase wurde frühzeitig beendet. Beispiele für Ereignisse, die die Schätzungsphase unterbrechen können: ungenügender Arbeitsspeicher oder Festplattenspeicher auf dem Host-System. Hängt von der Ursache ab.
Komprimierung TarMK GC #2: Komprimierung angehalten. Solange die Komprimierungsphase durch die Konfiguration angehalten wird, wird weder die Schätzungsphase noch die Komprimierungsphase ausgeführt. Aktivieren Sie die Online-Revisionsbereinigung.
Nicht zutreffend TarMK GC #2: Komprimierung abgebrochen: ${REASON}. Die Komprimierungsphase wurde frühzeitig beendet. Beispiele für Ereignisse, die die Komprimierungsphase unterbrechen können: ungenügender Arbeitsspeicher oder Festplattenspeicher auf dem Host-System. Darüber hinaus kann die Komprimierung auch abgebrochen werden, indem das System heruntergefahren oder explizit über Verwaltungsschnittstellen wie das Wartungsfenster im Vorgangs-Dashboard abgebrochen wird. Hängt von der Ursache ab.
Nicht zutreffend TarMK GC #2: Die Verdichtung scheiterte in 32.902 min (1974140 ms), nach 5 Zyklen. Diese Meldung bedeutet nicht, dass ein nicht behebbarer Fehler aufgetreten ist, sondern nur, dass die Komprimierung nach einigen Versuchen beendet wurde. Lesen Sie auch den folgenden Absatz. Lesen Sie die folgende Oak-Dokumentation und die letzte Frage im Abschnitt „Ausführen der Online-Revisionsbereinigung“.
Bereinigen TarMK GC #2: Bereinigung unterbrochen. Die Bereinigung wurde durch Herunterfahren des Repositorys abgebrochen. Es sind keinerlei Auswirkungen auf die Konsistenz zu erwarten. Außerdem wird wahrscheinlich nicht der gesamte Festplattenspeicher zurückgewonnen. Dieser wird beim nächsten Revisionsbereinigungszyklus zurückgewonnen. Finden Sie heraus, warum das Repository heruntergefahren wurde, und versuchen Sie in Zukunft, das Repository nicht während eines Wartungsfensters herunterzufahren.

Ausführen der Offline-Revisionsbereinigung

VORSICHT

Verwenden Sie eine Oak-run-Tool-Version, die eine Versionsnummer (sowohl Haupt- als auch Nebenversion) aufweist, die mit der Oak-Kernversion Ihrer AEM übereinstimmt. Wenn Ihre AEM-Instanz beispielsweise über die Oak-Kernversion 1.22.x verfügt, sollten Sie die neueste Version des Oak-run-Tools 1.22.x verwenden.

Adobe stellt ein Tool namens Oak-run für die Ausführung von Revisionsbereinigungen 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. Der Prozess wird als Offline-Revisionsbereinigung bezeichnet, da das Repository heruntergefahren werden muss, um das Tool ordnungsgemäß auszuführen. 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.

HINWEIS

Sie können auch alte Checkpoints löschen, bevor die Wartung durchgeführt wird (Schritte 2 und 3 im unten beschriebenen Verfahren). Dies wird nur für Instanzen mit mehr als 100 Checkpoints empfohlen.

  1. Stellen Sie stets sicher, dass Sie über eine aktuelle Sicherung der AEM-Instanz verfügen.

    Fahren Sie AEM herunter.

  2. (Optional) Verwenden Sie das Tool, um alte Checkpoints zu finden:

    java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore
    
  3. (Optional) Löschen Sie dann die nicht referenzierten Checkpoints:

    java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore rm-unreferenced
    
  4. Führen Sie die Komprimierung aus und warten Sie, bis sie abgeschlossen ist:

    java -jar -Dsun.arch.data.model=32 oak-run.jar compact install-folder/crx-quickstart/repository/segmentstore
    

Erhöhen der Leistung der Offline-Revisionsbereinigung

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 speicherzugeordnete Zugriff verwendet und auf 32-Bit-Systemen wird 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 150000, was bedeutet, dass die ersten 150000 komprimierten Knoten während des Vorgangs protokolliert werden. Verwenden Sie dies mit dem nächsten Parameter, der unten beschrieben wird.

  • -Dtar.PersistCompactionMap. Setzen Sie diesen Parameter auf "true", um Speicherplatz anstelle von Heap-Speicher für die Persistenz von Komprimierungskarten 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. Erzwingen Sie die Komprimierung und ignorieren Sie eine nicht übereinstimmende Segmentspeicherversion.

VORSICHT

Verwenden der --force -Parameter aktualisiert den Segmentspeicher auf die neueste Version, die mit älteren Oak-Versionen inkompatibel ist. Beachten Sie außerdem, dass kein Downgrade möglich ist. Im Allgemeinen sollten Sie diese Parameter mit Vorsicht und nur dann verwenden, wenn Sie wissen, wie Sie sie verwenden können.

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

Zusätzlich zu den oben beschriebenen Methoden können Sie den Revisionsbereinigungsmechanismus auch wie folgt mithilfe der JMX-Konsole auslösen:

  1. Öffnen Sie die JMX-Konsole, indem Sie zu http://localhost:4502/system/console/jmx wechseln.
  2. Klicken Sie auf MBean RevisionGarbageCollection.
  3. Klicken Sie im nächsten Fenster auf startRevisionGC() und dann auf Invoke, um den Vorgang der Revisionsbereinigung zu starten.

Häufig gestellte Fragen zur Offline-Revisionsbereinigung

Welche Faktoren bestimmen die Dauer der Offline-Revisionsbereinigung?

Die Größe des Repositorys und die Anzahl der zu bereinigenden Revisionen bestimmen die Dauer der Bereinigung.

Was ist der Unterschied zwischen einer Revision und einer Seitenversion?
  • Oak-Revision: Oak organisiert den gesamten Inhalt in einer großen Baumstruktur, die aus Knoten und Eigenschaften besteht. Jeder Schnappschuss oder jede Revision dieser Inhaltsstruktur ist unveränderlich, und Änderungen an der Baumstruktur werden als eine Abfolge neuer Revisionen ausgedrückt. Normalerweise wird bei jeder Inhaltsänderung eine neue Revision ausgelöst. Siehe auch Link folgen.
  • Seitenversion: Durch die Versionierung wird eine „Momentaufnahme“ einer Seite zu einem bestimmten Zeitpunkt festgehalten. In der Regel wird eine neue Version erstellt, wenn eine Seite aktiviert ist. Weitere Informationen finden Sie unter Arbeiten mit Seitenversionen.
Wie kann ich die Offline-Revisionsbereinigung beschleunigen, wenn diese Aufgabe nicht innerhalb von acht Stunden abgeschlossen wird? Wenn die Revisionsaufgabe nicht innerhalb von acht Stunden abgeschlossen wird und die Thread-Dumps zeigen, dass InMemoryCompactionMap.findEntry das Hauptproblem ist, verwenden Sie mit den Versionen 1.4 oder höher des Tools „oak-run“ den folgenden Parameter: -Dtar.PersistCompactionMap=true. Die -Dtar.PersistCompactionMap -Parameter wurde in Oak Version 1.6 entfernt.

Auf dieser Seite