Diese Seite soll zusammengefasste und relevante Informationen für verschiedene Wartungsoperationen am AEM 6.x Repository zur Verfügung stellen.

Zielsetzung

Dieser Artikel bietet Informationen über verschiedene Wartungstätigkeiten für AEM 6.x. AEM Oak Repository-Wartung ist zur Beibehaltung eines leistungsfähigen Systems wichtig.  Wartungsmängel verursachen Instabilität, Leistungsprobleme und Speicherplatzausfälle.

Wartung des Oak Tar SegmentNodeStore

Wartung des Oak Mongo-Datenspeichers

Binärdatei-Wartung (BLOB Store oder DataStore)

Wartung der Workflow-Bereinigung

Wartung der Versionsbereinigung

Lucene Binärdateien-Bereinigung

Wartung der Auditprotokoll-Bereinigung

Wartungstätigkeiten für AEM 6.x-Instanzen

Wartung des Oak Tar SegmentNodeStore

 Der SegmentNodeStore ist der standardmäßige Oak-Speichermechanismus, der im Lieferumfang von AEM enthalten ist. Diese Persistenzschicht schreibt Daten in tar-Dateien unter crx-quickstart/repository/segmentstore. Der Speicher ist nur im „append only“-Format verfügbar, so dass beim Erstellen, Aktualisieren oder Löschen von Inhalten die Dateien im Segmentstore-Ordner nur größer werden. Im Laufe der Zeit kann sich dies auf die Leistung und Stabilität von AEM auswirken. Um Speicherplatz freizugeben und die Leistung zu verbessern, müssen Sie die Wartung der tar-Verdichtung (auch bekannt als „Revisionsbereinigung“) ausführen.  Die Revisionsbereinigung kann sowohl offline (mit geschlossenem AEM) als auch online (mit laufendem AEM) ausgeführt werden. Die Online-Bereinigung ist jedoch erst ab AEM 6.3-Version sicher nutzbar. Weitere Informationen finden Sie in der zugehörigen Dokumentation für Ihre AEM-Version:

Vergleich von Offline- vs. Online-Verdichtung

Die folgende Tabelle enthält eine kurze Übersicht über die Unterschiede zwischen Online- und Offline-Revisionsbereinigung:

Offline-Verdichtung Online-Verdichtung
AEM 6.0 - 6.3 6.3 und spätere Versionen
Ausfallzeit erforderlich Keine Ausfallzeiten
Bereinigt alle alten Revisionen Bereinigt Revisionen, die vor
der letzten Online-Verdichtung ausgeführt wurden
Muss bis zum Vollzug ausgeführt werden Wird während der Wartung ausgeführt
Wird schneller ausgeführt Leistung wird durch Systemaktivitäten eingeschränkt
Es empfiehlt sich, sie alle zwei Wochen auszuführen Wird täglich ausgeführt (standardmäßig von 2 bis 5 Uhr)

Die Online-Revisionsbereinigung muss für AEM-Versionen 6.0 bis 6.2 ausgeschaltet sein. Eine Anleitung zum Ausschalten finden Sie in diesem Beitrag. Darüber hinaus gibt es bekannte Szenarien, in denen die Offline-Bereinigung fehlschlagen kann. Sehen Sie sich diesen Beitrag an, um derartige Probleme zu vermeiden und die Leistung der Offline-Verdichtung zu verbessern.

Empfohlener Zeitplan

Für AEM6.0 bis AEM6.2 wird empfohlen, die Offline-Verdichtung alle zwei Wochen durchzuführen.  Die Offline-Verdichtung ist auf AEM6.3 nicht erforderlich.  Stattdessen wird empfohlen, die Online-Verdichtung zu überwachen, die (standardmäßig) täglich von 2 bis 5 Uhr ausgeführt wird.

Beispiel eines Protokolldatei-Outputs

Hier sind Beispiele von Protokollmeldungen mit erfolgreichen Ausführungen der Revisionsbereinigung.

 

Offline-Revisionsbereinigung für AEM6.2 / Oak:

Apache Jackrabbit Oak 1.4.13​
Compacting crx-quickstart/repository/segmentstore​
    before ​
        Fri Oct 14 12:19:30 EDT 2016, data00000a.tar​
        Wed May 17 10:37:46 EDT 2017, data00001b.tar​
        Fri Oct 14 12:20:22 EDT 2016, data00002a.tar​
............​
        Wed May 17 10:37:45 EDT 2017, data00011b.tar​
        Sun Jul 16 16:12:39 EDT 2017, journal.log​
        Fri Oct 14 12:19:24 EDT 2016, repo.lock​
    size 7.7 GB (7712731491 bytes)​
    -> compacting​
    -> cleaning up​
    -> removed old file data00074a.tar​
    -> removed old file data00073a.tar​
    -> removed old file data00072a.tar​
….…​
    -> removed old file data00018b.tar​
    -> writing new journal.log: a838c3e9-613f-4095-abba-939c437882e7:59384 root​
..
..
after ​
        Fri Oct 14 12:19:30 EDT 2016, data00000a.tar​
        Wed May 17 10:37:46 EDT 2017, data00001b.tar​
        .............​
        Wed May 17 10:37:46 EDT 2017, data00003b.tar​
        Wed May 17 10:37:45 EDT 2017, data00004b.tar​
       Mon Jul 17 11:11:28 EDT 2017, journal.log​
        Fri Oct 14 12:19:24 EDT 2016, repo.lock​
    size 6.4 GB (6385295920 bytes)​
    removed files [data00057a.tar, data00065a.tar, data00020b.tar, data00018b.tar, data00050b.tar, data00073a.tar, data00058a.tar, data00069a.tar, data00060a.tar, data00063a.tar, data00074a.tar, data00066a.tar, data00055a.tar, data00062a.tar, data00036b.tar, data00070a.tar, data00068a.tar, data00072a.tar, data00067a.tar, data00049b.tar, data00061a.tar, data00056a.tar, data00064a.tar, data00059a.tar]​
    added files [data00050c.tar, data00065b.tar, data00073b.tar, data00056b.tar, data00072b.tar, data00066b.tar, data00069b.tar, data00063b.tar, data00018c.tar, data00058b.tar, data00060b.tar, data00074b.tar, data00020c.tar, data00059b.tar, data00070b.tar, data00062b.tar, data00061b.tar, data00036c.tar, data00075a.tar, data00057b.tar, data00049c.tar]​
Compaction succeeded in 21.76 s (21s).​

 

Online-Revisionsbereinigung auf AEM6.3:

TarMK GC #2: started​
TarMK GC #2: …..​
TarMK GC #2: estimation started
​TarMK GC #2: estimation completed in 6.373 ms (6 ms). Segmentstore size has increased since the last garbage collection from 417.9 MB (417905664 bytes) to 844.2 MB (844169728 bytes), an increase of 426.3 MB (426264064 bytes) or 102%. This is greater than sizeDeltaEstimation=100.0 MB (100000000 bytes), so running garbage collection​
TarMK GC #2: compaction started, …​
TarMK GC #2: estimated number of nodes to compact is 442708, based on 442307 nodes compacted to 417905664 bytes on disk in previous compaction and current size of 418285056 bytes on disk.​
TarMK GC #2: compaction cycle 0 completed in 52.96 s (52956 ms). Compacted ff940e56-3a69-4721-ab80-74210b7beae9.00000034 to 8ddf7c10-1af6-41f8-aa99-6b750e09e00b.00000533​
​TarMK GC #2: ……​
TarMK GC #2: compaction succeeded in 53.07 s (53072 ms), after 1 cycles​
TarMK GC #2: cleanup started.​
TarMK GC #2: current repository size is 530.8 MB (530752512 bytes)​
….​
cleanup marking files for deletion: …….​
cleanup completed in 1.584 s (1584 ms). Post cleanup size is 223.9 MB (223906816 bytes) and space reclaimed 306.8 MB (306845696 bytes).​
Removed files: ……​
TarMK closed: …….​

Wartung des Oak Mongo-Datenspeichers

Einige Kunden haben sich entschieden MongoDB (DocumentNodeStore) als die Speicherplattform für Oak zu verwenden, anstatt des standardmäßigen Tar SegmentNodeStore.  Diese Speicherplattform bietet hohe Verfügbarkeit durch Clustering von AEM-Instanzen.  Ähnlich wie beim Tar-Datenspeicher führen alle Schreibvorgänge, einschließlich der Löschvorgänge, dazu, dass mehr Daten geschrieben werden.  Um alte, nicht benötigte Revisionen von Daten zu bereinigen, führen Sie die DocumentNodeStore Revision Gargabe Collection aus (auch bekannt als „Revisionsbereinigung“).  Diese Wartung ist auf allen AEM-Versionen so konfiguriert, dass sie automatisch täglich um 2 Uhr ausgeführt wird.  Die Wartungsaufgabe, die dies konfiguriert, ist identisch mit Tar Online-Revisionsbereinigung.

Die Wartungsaufgabe wird nur auf dem Leader AEM Cluster-Knoten ausgeführt, entgegen dem primären Replikat des MongoDB-Clusters.  Dies funktioniert wie folgt:

  1. Überprüfen Sie, ob ein Kontrollpunkt vorhanden ist, der älter als 24 Stunden ist
  2. Fragen Sie MongoDB nach gelöschten Dokumenten ab, die älter als das maximale Revisionsalter sind
  3. Löschen Sie Dokumente in Stapeln
  4. Fragen Sie MongoDB nach „verzweigten“ Revisionsdokumenten ab, die älter als das maximale Revisionsalter sind
  5. Löschen Sie Dokumente in Stapeln

Empfohlener Zeitplan

Diese Wartung muss mindestens einmal täglich ausgeführt werden.  Standardmäßig wird sie um 2 Uhr ausgeführt und läuft bis zum Abschluss.  Je häufiger sie jedoch ausgeführt wird, desto schneller die Ausführung.  Zudem wird die Oak-Schreibleistung umso besser, je häufiger dies ausgeführt wird.  Beachten Sie, dass sie bei Ausführung die Leistung von MongoDB beeinflusst.  Sie sollte nur ausgeführt werden, wenn sich nur eine minimale Anzahl von Benutzern im System befindet.

Beispiel eines Protokolldatei-Outputs

Die folgende Beispielprotokollausgabe zeigt die Start- und Endprotokollmeldungen für eine erfolgreiche Ausführung der Revisionsbereinigung:

16.08.2017 23:38:26.521 *INFO* [sling-oak-observation-173] org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector Starting revision garbage collection. Revisions older than [2017-08-15 23:38:26.516] will be removed
16.08.2017 23:38:26.727 *INFO* [sling-oak-observation-173] org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector Proceeding to delete [2620] documents
16.08.2017 23:38:27.265 *INFO* [sling-oak-observation-173] org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector Proceeding to delete [0] previous documents
16.08.2017 23:38:27.279 *INFO* [sling-oak-observation-173] org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector Revision garbage collection finished in 766.2 ms. VersionGCStats{ignoredGCDueToCheckPoint=false, deletedDocGCCount=2620, splitDocGCCount=3, intermediateSplitDocGCCount=0, timeToCollectDeletedDocs=170.4 ms, timeTakenToDeleteDeletedDocs=561.3 ms, timeTakenToCollectAndDeleteSplitDocs=10.52 ms}

Wartung einer Oak-Binärdatei (BLOB)

Bei AEM 6.3 ist die standardmäßige Oak Repository-Speicherkonfiguration des Tar SegmentStore mit einem FileDataStore zum Speichern von Binärdateien konfiguriert.  Standardmäßig speichert ein DataStore Binärdateien, die 4 KB oder größer sind.  Bei einer Standardinstallation befindet sich der Datastore unter crx-quickstart/Behälter/datastore im Dateisystem des Servers.  Zu diesen Dateien gehören jar-Dateien, Bilder, javascript, css, Pakete, lucene-Indexdateien und jede andere Binärdatei, die in AEM hochgeladen wurden.  Auf diese Dateien wird in den Revisionen der Eigenschaften von Binärknoten im NodeStore verwiesen.

Das DataStore soll Dateien eindeutig speichern, d. h., wenn dieselbe Datei in Oak an zwei verschiedenen Speicherorten hochgeladen wird, wird nur eine Datei gespeichert.  Aus diesem Grund werden Dateien erst dann aus dem Datastore gelöscht, wenn die DataStore-Speicherbereinigung ausgeführt wird.

Die Wartung von BLOB GC (auch bekannt als „DataStore-Speicherbereinigung“) bezieht sich auf Datei-, S3- und Mongo BLOB-Binärspeicher in Oak.  Weitere Informationen zu diesem Thema finden Sie in der offiziellen Dokumentation:

Empfohlener Zeitplan

Standardmäßig ist dies eine wöchentliche Wartungsaufgabe am Samstagmorgen, die um 2 Uhr beginnt und bis zum Abschluss ausgeführt wird.  Es wird empfohlen, diese Wartungsaufgabe wöchentlich auszuführen, um Festplattenspeicher zu sparen.  Wenn jedoch ausreichend Speicherplatz vorhanden ist, kann die Wartung ohne Bedenken weniger häufig ausgeführt werden.  Das Auslassen dieser Wartung führt nur zur Vergeudung von Festplattenspeicher.

Beispiel eines Protokolldatei-Outputs

Die folgende Beispielprotokollausgabe zeigt die Start- und Endprotokollmeldungen für eine erfolgreiche Ausführung der Datenspeicherbereinigung:

Starting Blob garbage collection with markOnly [false]​
Collected (1024) blob references ​
….​
Deleted blobs [……….]​
….​
Blob garbage collection completed in 4.569 s (4568 ms). Number of blobs deleted [6341] with max modification time of [2017-07-16 22:03:55.295]









Wartung der Workflow-Bereinigung

Immer wenn ein Workflow in AEM gestartet wird, wird ein Workflow-Verlauf unter //etc/workflow/instances im Oak Repository erstellt.  Im Laufe der Zeit können sich Workflow-Verlaufsknoten anhäufen und die Systemleistung beeinträchtigen.  Um dies zu vermeiden, müssen Sie die Wartung der Workflow-Bereinigung ausführen.

Lesen Sie diese Dokumentation, um zu erfahren, wie Sie diese Wartungsaufgabe konfigurieren und ausführen.

Empfohlener Zeitplan

Diese Wartungsaufgabe muss wöchentlich ausgeführt werden.

Beispiel eines Protokolldatei-Outputs

Die nachfolgenden Protokollmeldungen zeigen eine erfolgreiche Ausführung der Workflow-Bereinigung:

*INFO* [Workflow Purge: 'DAM Workflows'] com.adobe.granite.workflow.core.mbean.WorkflowOperationsImpl Begin workflow purge with the following parameters:​
dry run: false​
days old: 0​
states: {COMPLETED, ABORTED}​
models: {/etc/workflow/models/dam/update_asset/jcr:content/model ,/etc/workflow/models/dam-xmp-writeback/jcr:content/model} purge save threshold: {20} purge query count: {1000}​
*INFO* [Workflow Purge: 'DAM Workflows'] com.adobe.granite.workflow.core.mbean.WorkflowOperationsImpl Cleaned up 1006 instances​
*INFO* [Workflow Purge: 'DAM Workflows'] com.adobe.granite.workflow.core.mbean.WorkflowOperationsImpl Finished running Workflow Purge. Purged: 1006 items.  Elapsed time (seconds): 0​
*INFO* [Workflow Purge: 'DAM Workflows'] com.adobe.granite.workflow.core.mbean.PurgeScheduler Finished running  Workflow Purge Configuration: DAM Workflows.  Purged: 1006 items.  Elapsed time (seconds): 0​

Wartung der Versionsbereinigung

Bei einer standardmäßigen AEM-Installation werden Versionen erstellt, wenn Sie Seiten oder Assets veröffentlichen oder widerrufen, oder Assets hochladen oder ersetzen.  Versionen werden als Knoten unter /jcr:system/jcr:versionStorage in der Oak-Repository gespeichert.  Diese Knoten behalten Verweise zu Binärdateien im Datastore.  Im Laufe der Zeit häufen sich die Versionen an, und dies wirkt sich auf die Systemleistung und Speichernutzung aus.  Die Suchindizes, Tar- oder Mongo-Speicher und DataStore werden durch zusätzliche Daten aus alten Versionsverläufen aufgebläht. Um den Speicherplatz zurückzugewinnen und die Systemleistung wiederherzustellen, müssen Sie die Versionsbereinigung ausführen.

  • Lesen Sie diese Dokumentation über die Konfiguration und Ausführung der Versionsbereinigung.
  • Weitere Informationen finden Sie in diesem Beitrag zum Vermeiden bekannter Probleme mit Versionsbereinigung.

Empfohlener Zeitplan

Diese Wartungsaufgabe muss monatlich ausgeführt werden.

Beispiel eines Protokolldatei-Outputs

Die Versionbereinigung gibt nur Meldungen an die Protokolle aus, wenn sie die Versionen erfolgreich bereinigt.  Wenn einige Versionen nicht bereinigt werden konnten, wird ein Fehler ausgegeben und andere Versionen werden weiterhin bereinigt.

Die folgende Meldung ist ein Beispiel für eine erfolgreiche Versionsbereinigung:

INFO [pool-11-thread-10-Maintenance Queue(com/adobe/granite/maintenance/job/VersionPurgeTask)] com.day.cq.wcm.core.impl.VersionManagerImpl Purged version 1.0 of /content/geometrixx/en/jcr:content

Der folgende Fehler ist ein Beispiel für eine fehlgeschlagene Versionsbereinigung:

ERROR [pool-11-thread-10-Maintenance Queue(com/adobe/granite/maintenance/job/VersionPurgeTask)] com.day.cq.wcm.core.impl.VersionManagerImpl Unable to purge version 1.1 for /content/geometrixx/en/jcr:content : OakIntegrity0001: Unable to delete referenced node
javax.jcr.ReferentialIntegrityException: OakIntegrity0001: Unable to delete referenced node
at org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:235)
at org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212)
at org.apache.jackrabbit.oak.jcr.version.ReadWriteVersionManager.removeVersion(ReadWriteVersionManager.java

Lucene-Binärdateien-Bereinigung

Mit der Aufgabe Lucene-Binärdateien-Bereinigung können Sie Lucene-Binärdateien bereinigen und die Größe des laufenden Datenspeichers reduzieren. Dies liegt daran, dass der Binärchurn des Lucene täglich neu beansprucht wird, anstatt die frühere Abhängigkeit von einem erfolgreichen Garbage-Collection-Lauf des Datenspeichers.

Obwohl die Wartungsaufgabe entwickelt wurde, um den Lucene bezogenen Revisionsmüll zu reduzieren, gibt es allgemeine Effizienzsteigerungen bei der Ausführung der Aufgabe:

  • Die wöchentliche Ausführung der Data Store Garbage Collection Aufgabe wird schneller abgeschlossen
  • Es kann auch die allgemeine AEM-Leistung leicht verbessern 

Sie können auf die Aufgabe Lucene-Binärdateien-Bereinigung zugreifen über: AEM > Tools > Operations > Wartung > Tägliche Wartung > Tägliche Wartung - Fenster > Lucene-Binärdateien-Bereinigung.

Wartung der Auditprotokoll-Bereinigung

Bei einer standardmäßigen AEM-Installation werden bei jedem Erstellen / Hochladen, Modifizieren, Löschen oder Veröffentlichen / Widerrufen von Seiten oder Assets Auditlogs erstellt.  Auditprotokolle werden als Knoten unter /var/audit in der Oak-Repository gespeichert.  Im Laufe der Zeit häufen sich diese Knoten an und beeinflussen die Systemleistung.  Um dies zu vermeiden, müssen Sie die Auditprotokollierungs-Wartung ausführen.

Lesen Sie diese Dokumentation, um zu erfahren, wie Sie die Wartung der Auditprotokoll-Bereinigung konfigurieren und ausführen.

Empfohlener Zeitplan

Diese Wartungsaufgabe muss monatlich ausgeführt werden.

Beispiel eines Protokolldatei-Outputs

Die nachfolgenden Protokollmeldungen zeigen eine erfolgreiche Ausführung von „AuditLog Maintenance“:

16.08.2017 23:19:48.765 *INFO* [pool-81-thread-1] com.day.cq.audit.impl.AuditLogPurgeScheduler {name = test, type = [PageVersion Created, PageRestored, PageValid, PageMoved, PageDeleted, PageModified, PageCreated, PageInvalid, PageRolled Out], contentPath = /content, minimumAge = 5} activated
16.08.2017 23:19:48.799 *INFO* [sling-threadpool-d679d698-60cf-4039-9702-55136a780492-(apache-sling-job-thread-pool)-1-Maintenance Queue(com/adobe/granite/maintenance/job/AuditLogMaintenanceTask)] com.day.cq.audit.impl.AuditLogPurgeScheduler test - AuditLog purge starting execution
16.08.2017 23:19:48.800 *INFO* [sling-threadpool-d679d698-60cf-4039-9702-55136a780492-(apache-sling-job-thread-pool)-1-Maintenance Queue(com/adobe/granite/maintenance/job/AuditLogMaintenanceTask)] com.day.cq.audit.impl.AuditLogPurgeScheduler test - Node /var/audit/com.day.cq.wcm.core.page/content does not exist in the repository, skipping current rule execution.
16.08.2017 23:19:48.800 *INFO* [sling-threadpool-d679d698-60cf-4039-9702-55136a780492-(apache-sling-job-thread-pool)-1-Maintenance Queue(com/adobe/granite/maintenance/job/AuditLogMaintenanceTask)] com.day.cq.audit.impl.AuditLogPurgeScheduler test - AuditLog purge execution is over

Dieses Werk unterliegt den Bedingungen der Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.  Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.

Rechtliche Hinweise   |   Online-Datenschutzrichtlinie