Revisionsbereinigung

Einführung

Bei jeder Repository-Aktualisierung wird eine neue Inhaltsrevision erstellt. Dadurch wächst bei jeder Aktualisierung die Größe des Repositorys. Um ein unkontrolliertes Repository-Wachstum zu vermeiden, müssen alte Revisionen bereinigt werden, um Festplattenressourcen freizugeben. Diese Wartungsfunktionalität wird als Revisionsbereinigung bezeichnet. und ist ab AEM 6.0 als Offlineprogramm verfügbar.

Mit AEM 6.3 wurde eine Onlineversion dieser Funktionalität 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 wird als Methode für die Revisionsbereinigung empfohlen.

Hinweis: Eine Einführung und die Verwendung der Online-Revisionsbereinigung finden Sie im Video .

Die Revisionsbereinigung ist in drei Phasen unterteilt: Schätzung, Komprimierung und Bereinigung. Bei der Schätzung wird basierend auf der Menge an erfassten veralteten Daten entschieden, ob die nächste Phase (Komprimierung) ausgeführt wird. In der Komprimierungsphase werden Segmente und TAR-Dateien neu geschrieben; nicht verwendete Inhalte werden daraus entfernt. In der Bereinigungsphase werden die alten Segmente und alle darin enthaltenen veralteten Daten gelöscht. Im Offline-Modus kann in der Regel mehr Speicherplatz zurückgewonnen werden, da im Online-Modus der Arbeitsdatensatz von AEM berücksichtigt werden muss, für den zusätzliche Segmente beibehalten (d. h. nicht bereinigt) werden.

Weitere Informationen zur Revisionsbereinigung finden Sie unter folgenden Links:

Darüber hinaus können Sie auch die offizielle Oak-Dokumentation lesen.

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

Die Online-Revisionsbereinigung ist die empfohlene Methode zur Durchführung einer 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

Die Online-Revisionsbereinigung ist standardmäßig so konfiguriert, dass sie einmal pro Tag automatisch auf der Autoren- und Veröffentlichungsinstanz von AEM ausgeführt wird. Sie müssen nur ein Wartungsfenster für einen Zeitraum festlegen, in dem die Benutzeraktivität am wenigsten beeinträchtigt wird. Sie können die Online-Revisionsbereinigung wie folgt konfigurieren:

  1. Wechseln Sie im AEM Hauptfenster zu Tools - Vorgänge - Dashboard - Wartung oder verweisen Sie Ihren Browser auf: https://serveraddress:serverport/libs/granite/operations/content/maintenance.html

    chlimage_1-90

  2. Bewegen Sie den Mauszeiger über Tägliches Wartungsfenster und klicken Sie auf das Symbol Einstellungen.

    chlimage_1-91

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

    chlimage_1-92

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

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

  2. Klicken Sie auf Tägliches Wartungsfenster.

  3. Bewegen Sie den Mauszeiger über das Symbol 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. Dies bedeutet, dass bei jeder Ausführung der Revisionsbereinigung eine neue Generation erstellt und auf der Festplatte gespeichert wird. Es gibt jedoch einen Unterschied zwischen den beiden Arten der Revisionsbereinigung: Die Offline-Revisionsbereinigung behält eine Generation bei, während die Online-Revisionsbereinigung zwei Generationen aufbewahrt. Wenn Sie also die Online-Revisionsbereinigung nach Offline-Revisionsbereinigung ausführen, geschieht Folgendes:

  1. Nach der ersten Online-Revisionsbereinigung verdoppelt sich die Größe des Repositorys. Dies geschieht, weil jetzt zwei Generationen auf der Festplatte aufbewahrt werden.
  2. Während der nachfolgenden Ausführungen wächst das Repository vorübergehend, während die neue Generation erstellt wird, und stabilisiert sich dann wieder auf die Größe, die es nach der ersten Ausführung hatte, da der Online-Revisionsbereinigungsprozess die vorherige Generation zurückgewinnt.

Beachten Sie auch, dass abhängig vom Typ und der Anzahl der Commits jede Generierung eine andere Größe als die vorherige haben kann, weshalb die endgültige Größe von einem Durchlauf zum nächsten abweichen kann.

Deswegen empfiehlt es sich, 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

AEM 6.5 führt zwei neue Modi für die ​​Komprimierungsphase des Online-Revisionsbereinigungsprozesses ein:

  • Der Modus vollständige Komprimierung schreibt alle Segmente und TAR-Dateien im gesamten Repository neu. Die nachfolgende Bereinigungsphase kann so eine maximale Bereinigung des Repositorys durchführen. Da die vollständige Komprimierung das gesamte Repository betrifft, benötigt sie in erheblichem Umfang Systemressourcen und Zeit. Die vollständige Komprimierung entspricht der Komprimierungsphase in AEM 6.3.
  • Der Modus Tail Compaction schreibt nur die neuesten Segmente und TAR-Dateien im Repository neu. Die aktuellsten 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 aktuellen Teil des Repositorys bereinigen. 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: während die Tail-Komprimierung weniger effektiv ist, wirkt sie sich auch weniger auf den normalen Systembetrieb aus. Im Gegensatz dazu ist die vollständige Komprimierung effektiver, wirkt sich aber stärker auf den normalen Systembetrieb aus.

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

Anleitung zum Konfigurieren der vollständigen und der Tail-Komprimierung

In der Standardkonfiguration wird die Tail-Komprimierung an Wochentagen und die vollständige Komprimierung an Sonntagen ausgeführt. Die Standardkonfiguration kann mithilfe des neuen Konfigurationswerts full.gc.days von RevisionCleanupTask Wartungsaufgabe geändert werden.

Wenn Sie den Wert full.gc.days konfigurieren, beachten Sie, dass die vollständige Komprimierung während der in dem Wert definierten Tage ausgeführt wird und die Tail-Komprimierung während der Tage ausgeführt wird, die im Wert nicht definiert sind. Wenn Sie beispielsweise die Ausführung einer vollständigen Komprimierung am Sonntag konfigurieren, wird die Tail-Komprimierung von Montag bis Samstag ausgeführt. Wenn Sie hingegen die Ausführung einer vollständigen Komprimierung an allen Tagen der Woche konfigurieren, wird die Tail-Komprimierung gar nicht ausgeführt.

Berücksichtigen Sie auch Folgendes:

  • Die Tail- Verdichtung ist weniger effektiv und hat weniger Auswirkungen auf den normalen Systembetrieb. Sie sollte daher an den Werktagen ausgeführt werden.
  • Vollständige Verdichtung ist effektiver, hat aber auch größere Auswirkungen auf den normalen Systembetrieb. Sie sollte daher außerhalb der Arbeitstage verwendet werden.
  • Beide Komprimierungen sollten so konfiguriert sein, dass sie außerhalb der Spitzenzeiten ausgeführt werden.

Fehlerbehebung

Wenn Sie die neuen Komprimierungsmodi verwenden, beachten Sie Folgendes:

  • Sie können die Ein-/Ausgabeaktivität überwachen, z. B.: E/A-Vorgänge, Wartezeiten der CPU auf E/A-Vorgänge, Größe der Commit-Warteschlange. Dies hilft Ihnen bei der Entscheidung, ob das System die E/A-Grenze erreicht hat und Upsizing erforderlich ist.
  • RevisionCleanupTaskHealthCheck gibt den allgemeinen Gesundheitsstatus der Online-Revisionsbereinigung an. Er funktioniert wie in AEM 6.3 und unterscheidet nicht zwischen der vollständigen und der Tail-Komprimierung.
  • Die Protokollmeldungen enthalten relevante Information über die Komprimierungsmodi. Wenn beispielsweise die Online-Revisionsbereinigung gestartet wird, geben die Protokollmeldungen den verwendeten Komprimierungsmodus an. Außerdem kann es in einigen Grenzfällen passieren, dass das System zur vollständigen Komprimierung wechselt, obwohl eine Tail-Komprimierung geplant ist. Diese Änderung ist in den Protokollmeldungen ersichtlich. Die folgenden Protokollbeispiele zeigen den Komprimierungsmodus und den Wechsel von der vollständigen Komprimierung zur Tail-Komprimierung:
TarMK GC: running tail compaction
TarMK GC: no base state available, running full compaction instead

Bekannte Einschränkungen

In einigen Fällen verzögert der Wechsel zwischen dem Tail- und dem vollständigen Komprimierungsmodus den Bereinigungsprozess. Genauer gesagt steigt die Größe des Repositorys nach einer vollständigen Komprimierung an (sie verdoppelt sich). Der zusätzliche Speicherplatz wird bei der nachfolgenden Tail-Komprimierung zurückgewonnen, bei der das Repository unter den Wert vor der vollständigen Komprimierung fällt. Auch die parallele Ausführung von Wartungsaufgaben sollte 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 keine proaktive Migration erforderlich. Vorhandene Repositorys durchlaufen eine parallele 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 initiiert wurde, kann das Repository nicht mehr in 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 waren Änderungen am Speicherformat erforderlich, insbesondere zur Verbesserung der Leistung und Wirksamkeit der Online-Revisionsbereinigung. Diese Änderungen sind nicht rückwärtskompatibel, daher müssen mit dem alten Oak-Segment (AEM 6.2 und früher) erstellte Repositorys migriert werden.

Weitere Vorteile der Änderung des Speicherformats:
Wird das vorherige TAR-Format weiterhin unterstützt? AEM 6.3 unterstützt nur das neue Oak-Segment-Tar.
Ist die Migration des Inhalts immer obligatorisch? Ja. Sie müssen Inhalt immer migrieren, es sei denn, Sie starten mit einer neuen Instanz.
Kann ich auf 6.3 aktualisieren und die Migration später durchführen (um z. B. ein anderes Wartungsfenster zu nutzen)? Nein, wie oben beschrieben, ist die Migration obligatorisch.
Kann die Ausfallzeit für die Migration vermieden werden? Nein. Es handelt sich um eine einmalige Aufgabe, die 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 einer IllegalStateException mit der Meldung "Ungültiges Segmentformat"fehl. Daten werden jedoch nicht beschädigt.
Müssen die Suchindizes neu indiziert werden? Nein. Durch die Migration von Oak-Segment zu Oak-Segment-Tar werden Änderungen im Containerformat eingeführt. 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 im 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 Offline-Revisionsbereinigung ausgefü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 Offline-Revisionsbereinigung ähneln, vorausgesetzt, die Offline-Revisionsbereinigung wurde vor der Migration ausgeführt.

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? Siehe 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. Jedes Mal, wenn die Revisionsbereinigung ausgeführt wird, wird eine neue Generation erstellt. Nur Inhalt, der mindestens zwei Generationen alt ist, wird zurückgewonnen; daher wird beim erstmaligen Ausführen kein Speicherplatz zurückgewonnen.
Warum gewinnt die erste Online-Revisionsbereinigung keinen Speicherplatz zurück, wenn sie nach der Offline-Revisionsbereinigung ausgeführt wird?

Bei der Offline-Revisionsbereinigung wird alles zurückgewonnen, nur die letzte Generation bleibt erhalten. Bei der Online-Revisionsbereinigung bleiben die beiden letzten Generationen erhalten. Im Fall eines neuen Repositorys wird beim erstmaligen Ausführen der Online-Revisionsbereinigung im Anschluss an die Offline-Bereinigung kein Speicherplatz zurückgewonnen, da keine Generation alt genug für die Rückgewinnung ist.

Lesen Sie hierzu auch den Abschnitt „Ausführen der Online-Revisionsbereinigung nach der Offline-Revisionsbereinigung“ in diesem Kapitel.
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 konfiguriert werden, um eine optimale Bereinigungswirksamkeit zu gewährleisten. 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 daher eine ältere Version von AEM verwenden, müssen Sie zum neuen Oak-Segment-Tar migrieren.
Welche Faktoren bestimmen die Dauer der Online-Revisionsbereinigung? Es handelt sich um folgende Faktoren:
  • Repository-Größe
  • Systemlast (Anforderungen pro Minute, insbesondere Schreibvorgänge)
  • Aktivitätsmuster (Lese- versus Schreibvorgänge)
  • Hardwarespezifikationen (CPU-Leistung, Hauptspeicher, IOPS)
Können Autoren weiterarbeiten, während die Online-Revisionsbereinigung läuft? Ja, die Online-Revisionsbereinigung beherrscht gleichzeitige Schreibvorgänge. Die Online-Revisionsbereinigung ist jedoch schneller und effizienter, wenn keine gleichzeitigen Schreibvorgänge erfolgen. Es wird empfohlen, die Wartungsaufgabe für die Online-Revisionsbereinigung für einen relativ ruhigen Zeitraum mit geringem Traffic zu planen.
Welche Mindestanforderungen gelten für Festplatten- und Heapspeicher, wenn die Online-Revisionsbereinigung ausgeführt wird?

Der Festplattenspeicher wird während der Online-Revisionsbereinigung kontinuierlich überwacht. Falls der verfügbare Speicherplatz unter einen kritischen Wert sinkt, wird der Vorgang abgebrochen. Der kritische Wert beträgt 25 % der aktuellen Festplattengröße auf dem Repository und kann nicht konfiguriert 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.

Der verfügbare Heap-Speicher wird beim Bereinigungsvorgang ständig überwacht. Falls der verfügbare Heap-Speicher unter einen kritischen Wert sinkt, wird der Vorgang 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. Als allgemeine Regel gilt: Falls eine AEM-Instanz ausreichend für die Anwendungsbereiche und erwartete Nutzlast dimensioniert ist, ist ausreichend Speicherplatz für den Bereinigungsvorgang vorhanden.
Mit welcher Auswirkung auf die Performance muss beim Ausführen der Online-Revisionsbereinigung gerechnet werden? Die Online-Revisionsbereinigung ist ein Hintergrundprozess, der parallel zu den normalen Systemvorgängen Daten aus dem Repository liest und in das Repository schreibt. Insbesondere benötigt der Vorgang u. U. für einen kurzen Zeitraum exklusiven Zugang zum Repository, sodass andere Threads nicht in das Repository schreiben können.
Wie lange dauert die Ausführung der Online-Revisionsbereinigung erwartungsgemäß? Ausgehend von unseren letzten intern ausgeführten Performancetests sollte die Ausführung nicht mehr als 2 Stunden dauern.
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 während der minimalen Repository-Aktivitäten 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, falls mehrere Wartungsaufgaben zusätzlich zur Online-Revisionsbereinigung im selben Wartungsfenster ausgeführt werden. Beachten Sie, dass Wartungsaufgaben der Reihe nach ausgeführt werden und die Reihenfolge nicht konfiguriert werden kann.
Warum wird die Revisionsbereinigung übersprungen?

Die Revisionsbereinigung ermittelt in einer Schätzungsphase, ob eine Bereinigung notwendig ist. Bei der Schätzung wird die aktuelle Repository-Größe mit der Größe nach der letzten Komprimierung verglichen. Falls die Größe den konfigurierten Deltawert übersteigt, erfolgt eine Bereinigung. Der Delta-Formatbereich ist auf 1 GB eingestellt. 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: Das Größendelta ist N% oder N/N (N/N Bytes), sodass die laufende Komprimierung ausgeführt wird
  • Revision GC führt not aus: Das Delta der 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 Performance zu groß ist? Ja. AEM 6.3 kann sicher über das Wartungsaufgaben-Fenster im Vorgangs-Dashboard oder über JMX beendet werden.
Wenn die AEM-Instanz während einer geplanten Bereinigungsaufgabe beendet wird, wird der Prozess dann sicher beendet oder wird das Herunterfahren so lange 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? Es besteht in diesem Fall keine Gefahr für die Daten. Nicht bereinigte alte Daten werden bei der nächsten Bereinigung gelöscht.
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 gleichzeitige Schreibvorgänge an das Repository zu stark stören?

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 committen. Das System wechselt in den forceCompact-Modus, wie ausführlicher in der Oak-Dokumentation beschrieben. Bei der erzwungenen Komprimierung wird eine exklusive Schreibsperre angewendet, damit die Änderungen ohne störende gleichzeitige Schreibvorgänge gespeichert werden können. Um die Auswirkungen auf die Reaktionszeiten zu begrenzen, kann ein Zeitlimitwert festgelegt werden. Dieser Wert beträgt standardmäßig 1 Minute. Falls also die erzwungene Komprimierung nicht innerhalb 1 Minute abgeschlossen ist, wird die Komprimierung zugunsten gleichzeitiger Speichervorgänge abgebrochen.

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

  • Hardware: insbesondere IOPS. Die Dauer verkürzt sich mit steigenden IOPS.
  • Segmentspeichergröße: Die Dauer steigt proportional zur Größe des Segmentspeichers.

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

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

Der entsprechende Vorgang auf einer Standby-Instanz ist die automatische Bereinigung - dies entspricht der Bereinigungsphase der Online-Revisionsbereinigung. Die automatische Bereinigung wird auf der Standby-Instanz im Anschluss an die Online-Revisionsbereinigung auf der primären Instanz ausgeführt.

Auf der Standby-Instanz gibt es keine Schätzungs- und Komprimierungsphasen.
Kann die Offline-Revisionsbereinigung mehr Speicherplatz freigeben als die Online-Revisionsbereinigung?

Die Offline-Revisionsbereinigung kann alte Revisionen sofort entfernen, während die Online-Revisionsbereinigung alte Versionen berücksichtigen muss, die weiterhin vom Anwendungsstapel referenziert werden. Bei der Offline-Revisionsbereinigung werden alte Daten also aggressiver bereinigt; bei der Online-Revisionsbereinigung zeigt sich der Effekt nach einigen Bereinigungszyklen.

Lesen Sie hierzu auch den Abschnitt „Ausführen der Online-Revisionsbereinigung nach der Offline-Revisionsbereinigung“ in diesem Kapitel.
Gibt es Aspekte, die bei Dateioperationen mit Speicherzuordnung beachtet werden müssen?
  • In Windows-Umgebungen wird immer der reguläre Dateizugriff erzwungen, sodass der speicherzugeordnete Zugriff nicht verwendet wird. Als allgemeine Empfehlung sollte der gesamte verfügbare RAM dem Heap zugeordnet und die segmentCache-Größe erhöht werden. Sie erhöhen den segmentCache, indem Sie die Option segmentCache.size zur Datei org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config hinzufügen (z. B. segmentCache.size=20480). Denken Sie daran, auch RAM für das Betriebssystem und andere Prozesse einzuplanen.
  • In Nicht-Windows-Umgebungen erhö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 vorzeitig beendet, falls nicht genügend Speicherplatz vorhanden ist.
  • Überprüfen Sie die Protokolldateien auf die Ausführungsdauer der Online-Revisionsbereinigung. Sie sollte nicht länger als 2 Stunden in Anspruch nehmen.
  • Anzahl der Checkpoints. Falls bei der Komprimierung mehr als drei Prüfpunkte auftreten, wird empfohlen, die Prüfpunkte zu bereinigen.
Wie kann ich überprüfen, 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, der Meldung "TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles"vorangestellt ist, was bedeutet, dass zu viele gleichzeitige Lasten aufgetreten sind.

Dementsprechend gibt es eine 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) verfügbar gemacht. Weitere Informationen zum MBean SegmentRevisionGarbageCollection finden Sie im folgenden Absatz.

Der Fortschritt kann über das Attribut EstimatedRevisionGCCompletion der SegmentRevisionGarbageCollection MBean.

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

Beachten Sie, dass Statistiken nur ab dem letzten Systemstart verfügbar sind. Sie können externe Überwachungstools verwenden, um Daten über die AEM-Laufzeit hinaus aufzubewahren. Siehe die AEM Dokumentation zum Anhängen von Konsistenzprüfungen an Nagios als Beispiel für ein externes Überwachungstool.
Welche Protokolleinträge sind relevant?
  • Die Online-Revisionsbereinigung wurde gestartet/beendet.
    • Die Online-Revisionsbereinigung umfasst 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"den Beginn der Bereinigung.
  • Durch die Revisionsbereinigung gesammelter 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"gekennzeichnet. Post cleanup size is {} ({} bytes) and space reclaimed {} ({} bytes). Compaction map weight/depth is {}/{} ({} 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.

Weitere Informationen finden Sie unten im Abschnitt Fehlerbehebung basierend auf Fehlermeldungen .
Wie kann ich überprüfen, wie viel Speicherplatz nach Abschluss der Online-Revisionsbereinigung zurückgewonnen wurde? Am Ende des Bereinigungszyklus wird im Protokoll eine Meldung angezeigt: "TarMK GC #3: cleanup completed", der die Größe des Repositorys und den Umfang des zurückgewonnenen Speicherbereinigtes umfasst.
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:

  • Ein Repository traversal check
  • Verwenden Sie das oak-run-Tool nach Abschluss des Bereinigungsprozesses, um nach Inkonsistenzen zu suchen. Weitere Informationen dazu finden Sie in der Apache-Dokumentation. Sie müssen das Tool nicht herunterfahren, AEM Sie es ausführen.
Wie kann ich feststellen, ob die Online-Revisionsbereinigung fehlgeschlagen ist und welche Wiederherstellungsschritte sind erforderlich? Fehlerbedingungen werden durch WARN- oder ERROR-Protokollmeldungen gekennzeichnet, die mit "TarMK GC"beginnen. Weitere Informationen finden Sie unten im Abschnitt Fehlerbehebung basierend auf Fehlermeldungen .
Welche Informationen werden in der Konsistenzprüfung der Revisionsbereinigung angezeigt? Wie und wann tragen sie zu den farbcodierten Statusstufen bei?

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

Der Status lautet GREEN , wenn die letzte Ausführung der Online-Revisionsbereinigung erfolgreich abgeschlossen wurde.

Es ist YELLOW, wenn die Wartungsaufgabe der 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, da die Online-Revisionsbereinigung wahrscheinlich erneut fehlschlägt. Weitere Informationen finden Sie unten im Abschnitt Fehlerbehebung.

Beachten Sie, dass der Status der Konsistenzprüfung nach jedem Systemneustart zurückgesetzt wird. Für eine neu gestartete Instanz wird der Status der Konsistenzprüfung der Revisionsbereinigung grün angezeigt. Sie können externe Überwachungstools verwenden, um Daten über die AEM-Laufzeit hinaus aufzubewahren. Siehe die AEM Dokumentation zum Anhängen von Konsistenzprüfungen an Nagios als Beispiel für ein externes Überwachungstool.

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

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

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

Beachten Sie, dass die Statistiken nur seit dem letzten Systemstart verfügbar sind. Sie können externe Überwachungstools verwenden, um Daten über die AEM-Laufzeit hinaus aufzubewahren. Siehe auch die AEM Dokumentation zum Anhängen von Konsistenzprüfungen an Nagios als Beispiel für ein externes Überwachungstool.

Anhand der Protokolldateien können Sie auch den Status, den Fortschritt und die Statistiken der automatischen Bereinigung ü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.
  • Segmentspeichergröße nach Ausführung 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? Die AEM-Instanz hat keinen Speicherplatz mehr, 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 verschiedene Maßnahmen ergreifen, um das Problem zu identifizieren und zu beheben:
  • Analysieren Sie zunächst die Protokolleinträge.
  • Führen Sie je nach den in den Protokollen angezeigten Informationen folgende Schritte aus:
    • Wenn in den Protokollen fünf verpasste kompakte Zyklen und eine Zeitüberschreitung beim forceCompact-Zyklus angezeigt werden, planen Sie das Wartungsfenster auf eine ruhige Zeit, wenn die Menge an Repository-Schreibvorgängen gering ist. Sie können die Schreibweise des Repositorys im Tool zur Überwachung der Repository-Metriken unter https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.html überprüfen.
    • Falls die Bereinigung am Ende des Wartungsfenster angehalten wurde, überprüfen Sie auf der Benutzeroberfläche für Wartungsaufgaben, ob das Wartungsfenster ausreichend lange konfiguriert ist.
    • Falls der verfügbare Heap-Speicher nicht ausreicht, stellen Sie sicher, dass die Instanz genügend Speicher hat.
    • Im Fall einer langsamen Reaktion wächst der Segmentspeicher möglicherweise zu schnell, sodass die Online-Revisionsbereinigung auch in einem längeren Wartungsfenster nicht abgeschlossen werden kann. Falls beispielsweise die Online-Revisionsbereinigung in der letzten Woche nicht erfolgreich abgeschlossen wurde, wird empfohlen, eine Offline-Wartung zu planen und eine Offline-Revisionsbereinigung auszuführen, um die Größe des Segmentspeichers zu beschränken.
Wie muss ich vorgehen, wenn die Warnfunktion bei der 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 Reste werden entfernt. Die Online-Revisionsbereinigung wird im nächsten geplanten Wartungsfenster neu gestartet.
Was verursacht die Protokollierung von SegmentNotFoundException-Instanzen in error.log und wie kann ich sie wiederherstellen?

Ein SegmentNotFoundException wird vom TarMK protokolliert, wenn er versucht, auf eine Speichereinheit (ein Segment) zuzugreifen, die nicht gefunden werden kann. Es gibt drei Situationen, die diesen Fehler verursachen können:

  1. Eine Anwendung, die die empfohlenen Zugriffsmechanismen (wie Sling und die JCR-API) umgeht und über eine API/SPI auf niedrigerer Ebene auf das Repository zugreift und dann die Aufbewahrungsdauer für ein Segment überschreitet. Anders ausgedrückt, es wird eine Referenz auf eine Einheit für einen längeren Zeitraum als die von der Online-Revisionsbereinigung erlaubte Aufbewahrungsdauer (standardmäßig 24 Stunden) beibehalten. Dieser Fall tritt nur vorübergehend auf und führt nicht zu einer Beschädigung von Daten. Um eine Wiederherstellung zu ermöglichen, sollte das Tool oak-run verwendet werden, um die vorübergehende Natur der Ausnahme zu bestätigen (bei der Oak-Run-Prüfung sollten keine Fehler gemeldet werden). Dazu muss die Instanz offline geschaltet und danach neu gestartet werden.
  2. Ein externes Ereignis hat die Beschädigung der Daten auf der Festplatte verursacht. Hierbei kann es sich um einen Datenträgerfehler, ungenügenden Festplattenspeicher oder eine unbeabsichtigte Änderung der erforderlichen Datendateien handeln. In diesem Fall müssen Sie die Instanz in den Offline-Modus versetzen und den Fehler mithilfe der oak-run-Prüfung beheben. Weitere Informationen zum Ausführen der Oak-Run-Prüfung finden Sie in der folgenden Apache-Dokumentation.
  3. Alle anderen Vorkommnisse sollten über die Adobe-Kundenunterstützung adressiert werden.

Fehlerbehebung basierend auf Fehlermeldungen

Die Datei error.log ist ausführlich, wenn es während der Online-Revisionsbereinigung zu Vorfällen kommt. In der folgenden Matrix werden die häufigsten Fehlermeldungen und mögliche Lösungen erläutert:

Schritt Protokollmeldungen Erklärung Nächste Schritte
Schätzung TarMK GC #2: Schätzung übersprungen, weil die Komprimierung angehalten wurde Die Schätzungsphase wird übersprungen, wenn die Komprimierung im System durch Konfiguration deaktiviert ist. Aktivieren der Online-Revisionsbereinigung.
TarMK GC #2: Schätzung unterbrochen: ${GRUND}. Skipping compaction. Die Schätzungsphase wurde vorzeitig beendet. Beispiele für Ereignisse, die die Schätzungsphase unterbrechen können: ungenügender Arbeitsspeicher oder Festplattenspeicher auf dem Hostsystem Hängt vom angegebenen Grund ab.
Komprimierung TarMK GC #2: Komprimierung angehalten Solange die Komprimierungsphase durch die Konfiguration angehalten wird, werden weder die Schätzungsphase noch die Komprimierungsphase ausgeführt. Aktivieren Sie die Online-Revisionsbereinigung.
TarMK GC #2: Komprimierung abgebrochen: ${GRUND}. Die Komprimierungsphase wurde vorzeitig beendet. Beispiele für Ereignisse, die die Komprimierungsphase unterbrechen können: ungenügender Arbeitsspeicher oder Festplattenspeicher auf dem Hostsystem. Eine Komprimierung kann auch abgebrochen werden, wenn das System heruntergefahren wird, oder explizit über eine administrative Schnittstelle wie das Wartungsfenster im Vorgangs-Dashboard. Hängt vom angegebenen Grund ab.
TarMK GC #2: Komprimierung fehlgeschlagen 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 einer bestimmten Anzahl von Versuchen beendet wurde. Lesen Sie auch den folgenden Absatz. Lesen Sie die folgende Oak-Dokumentation und die letzte Frage des Abschnitts 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 ganze Festplattenspeicher zurückgewonnen. Dieser wird beim nächsten Revisionsbereinigungszyklus zurückgewonnen. Finden Sie heraus, warum das Repository heruntergefahren wurde; versuchen Sie in Zukunft, das Repository nicht während eines Wartungsfensters herunterzufahren.

Ausführen der Offline-Revisionsbereinigung

VORSICHT

Je nach der mit der AEM-Installation verwendeten Oak-Version müssen unterschiedliche Versionen des Tools „oak-run“ verwendet werden. Prüfen Sie die nachfolgend aufgeführten Versionsanforderungen, bevor Sie das Tool nutzen:

  • Verwenden Sie für Oak-Versionen 1.0.0 bis 1.0.11 oder 1.1.0 bis 1.1.6 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 bietet ein Tool namens Oak-run für die Durchführung der Revisionsbereinigung. Es kann unter folgender URL heruntergeladen werden:

https://repo1.maven.org/maven2/org/apache/jackrabbit/oak-run/

Bei dem Tool handelt es sich um 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 für das konfigurierte Wartungsfenster.

Tipps zur Leistungssteigerung des Bereinigungsprozesses finden Sie unter Steigern der Leistung der Offline-Revisionsbereinigung.

HINWEIS

Vor der Wartung können Sie außerdem alte Prüfpunkte löschen (Schritte 2 und 3 unten). Dies wird nur für Instanzen empfohlen, die mehr als 100 Prüfpunkte aufweisen.

  1. Stellen Sie immer sicher, dass Sie über eine Sicherungskopie der AEM-Instanz verfügen.

    Fahren Sie AEM herunter.

  2. (Optional) Verwenden Sie das Tool, um alte Prüfpunkte zu finden:

    java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore

  3. (Optional) Löschen Sie die nicht referenzierten Prüfpunkte:

    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 diese abgeschlossen ist:

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

Steigern der Leistung der Offline-Revisionsbereinigung

Das Oak-run-Tool beinhaltet diverse Funktionen, die die Leistung der Revisionsbereinigung steigern und das Wartungsfenster so weit wie möglich verkleinern.

Die Liste enthält einige Befehlszeilenparameter, wie im Folgenden beschrieben:

  • -mmap. Sie können dies als "true"oder "false"festlegen. Wenn „true“ festgelegt ist, wird der Zugriff mit Speicherzuordnung verwendet. Wenn „false“ festgelegt ist, wird der Dateizugriff verwendet. Wenn kein Wert festgelegt 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, weshalb diese Option ignoriert wird. Dieser Parameter hat den Parameter -Dtar.memoryMapped ersetzt.

  • -Dupdate.limit. Definiert den Schwellenwert für das Löschen temporärer Transaktionen auf der Festplatte. Der Standardwert ist 10000.

  • -Dcompress-interval. Anzahl der Komprimierungszuordnungseinträge, die bis zur Komprimierung der aktuellen Zuordnung beibehalten werden. Standard: 1000000. Sie sollten für diesen Wert eine noch höhere Zahl festlegen, um einen schnelleren Durchsatz zu erzielen, falls nicht genügend Heap-Speicher vorhanden ist. Dieser Parameter wurde in 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 diese Option zusammen mit dem im Folgenden erläuterten Parameter.

  • -Dtar.PersistCompactionMap. Setzen Sie diesen Parameter auf "true", um Speicherplatz anstelle des Heap-Speichers für die Persistenz von Komprimierungskarten zu verwenden. Erfordert das Oak-Run-Tool Version 1.4 und höher. Weitere Informationen finden Sie unter Frage 3 im Abschnitt Häufig gestellte Fragen zur Offline-Revisionsbereinigung. Dieser Parameter wurde in Oak Version 1.6 entfernt und hat keine Auswirkung.

  • –force. Erzwingen Sie die Komprimierung und ignorieren Sie eine nicht übereinstimmende Segmentspeicherversion.

VORSICHT

Mit dem Parameter --force wird der Segmentspeicher auf die neueste Version aktualisiert, was mit älteren Oak-Versionen inkompatibel ist. Beachten Sie außerdem, dass kein Downgrade möglich ist. Generell sollten Sie diese Parameter vorsichtig verwenden und nur, wenn Sie wirklich wissen, wie sie verwendet werden.

Ein Beispiel der 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 Revisions-Bereinigung

Zusätzlich zu den oben genannten Methoden können Sie die Revisionsbereinigung auch wie folgt über die JMX-Konsole auslösen:

  1. Öffnen Sie die JMX-Konsole, indem Sie zu http://localhost:4502/system/console/jmx navigieren.
  2. Klicken Sie auf das MBean RevisionGarbageCollection.
  3. Klicken Sie im nächsten Fenster auf startRevisionGC() und dann auf Invoke , um den Auftrag zur 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 Revisionen, die bereinigt werden müssen, 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. Jede Momentaufnahme bzw. jede Revision dieser Inhaltsstruktur ist unveränderlich; Änderungen der Struktur werden als eine Reihe neuer Revisionen ausgedrückt. In der Regel wird durch jede Inhaltsänderung eine neue Revision ausgelöst. Siehe auch Follow link.
  • Seitenversion: Durch die Versionierung wird ein "Schnappschuss"einer Seite zu einem bestimmten Zeitpunkt erstellt. 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 8 Stunden abgeschlossen wird? Wenn die Revisionsaufgabe nicht innerhalb von 8 Stunden abgeschlossen wird und die Thread-Dumps zeigen, dass der Haupt-Hotspot InMemoryCompactionMap.findEntry ist, verwenden Sie den folgenden Parameter mit dem Oak-Run-Tool Versionen 1.4 oder höher: -Dtar.PersistCompactionMap=true. Beachten Sie, dass der Parameter -Dtar.PersistCompactionMap in Oak Version 1.6 entfernt wurde.

Auf dieser Seite