Cette page est conçue pour fournir les détails consolidés et appropriés pour des opérations de maintenance sur le référentiel AEM 6.x.

Objectif

Cet article fournit des détails sur les activités de maintenance pour AEM 6.x. La maintenance du référentiel AEM Oak est essentielle pour conserver un système performant.  L'absence de maintenance entraîne une instabilité, des problèmes de performances et des interruptions dans l'espace disque.

Maintenance du stockage des nœuds Oak Tar

Maintenance du stockage de Oak Mongo

Maintenance du fichier binaire (banque de données BLOB)

Maintenance de vidage du flux de travail

Maintenance du vidage de la version

Maintenance de purge du journal d'audit

Activités de maintenance pour les instances de AEM 6.x.

Maintenance de la banque de noeuds SegmentNodeStore Oak Tar.

 La banque de noeuds SegmentNodeStore est le mécanisme de stockage Oak par défaut, fourni avec AEM. Cette couche de persistance écrit des données dans les fichiers tar sous crx-quickstart/repository/segmentstore. Le stockage est un format d'ajout uniquement. Par conséquent, lorsque le contenu est créé, mis à jour ou supprimé, les fichiers du dossier segmentstore sont plus volumineux. Avec le temps, cela peut affecter les performances et la stabilité d’AEM. Pour récupérer de l’espace disque et améliorer les performances, vous devez exécuter la maintenance de compactage tar, appelée également « Revision cleanup ».  Le nettoyage des modifications peut être exécuté hors ligne (avec AEM éteint) et en ligne (avec AEM en cours d’exécution). Toutefois, le nettoyage en ligne est sécurisé seulement lors d'une utilisation de AEM 6.3 et des dernières versions. Consultez la documentation relative à votre version AEM :

Comparaison hors ligne ou en ligne de la compression

Le tableau suivant fournit une référence rapide aux différences entre le nettoyage des modifications en ligne et hors ligne :

Compression hors ligne Compression en ligne
AEM 6.0 - 6.3. 6.3 et versions plus récentes.
Temps d'arrêt requis. Aucun temps d'arrêt requis.
Nettoie toutes les anciennes révisions. Nettoie les modifications avant
la dernière exécution du compactage en ligne.
Doit être exécuté jusqu'à la fin. Fonctionne dans la fenêtre de maintenance.
Exécution plus rapide. Performances limitées par les activités du système
Exécution deux fois par semaine recommandée. Fonctionne chaque jour (par défaut, de 2h à 5h du matin).

Pour les versions AEM 6.0 à 6.2, le nettoyage en ligne des modifications doit être désactivé. Consultez cet article pour les étapes de désactivation. En outre, il existe des scénarios connus dans lesquels le nettoyage hors ligne peut échouer. Consultez cet article pour éviter ces problèmes et améliorer les performances de compression hors ligne.

Planification recommandée.

Sur AEM6.0 à AEM6.2, il est recommandé d'exécuter la compression hors ligne deux fois par semaine.  Sur AEM6.3, la compression hors ligne n'est pas obligatoire.  Au lieu de cela, il est recommandé d'analyser la compression en ligne, qui est planifiée (par défaut) pour être exécutée chaque jour de 2h à 5h du matin.

Exemple de sortie de journal.

Voici des exemples de messages de journal indiquant l’exécution réussie du nettoyage des modifications.

 

Nettoyage hors ligne des modifications sur 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).​

 

Nettoyage en ligne des modifications sur 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: …….​

Maintenance du stockage Oak Mongo.

Certains clients ont choisi d'utiliser MongoDB (Banque de noeuds de document) comme plateforme de stockage pour Oak, au lieu d'utiliser la banque de noeuds de segments tar par défaut.  Cette plate-forme de stockage offre une haute disponibilité par le biais du regroupement d'instances AEM.  Comme pour le stockage Tar, la sélection de toutes les écritures, y compris les suppressions, entraîne plus de données à écrire.  Pour nettoyer les anciennes modifications inutiles de données, exécutez, lors de la récupération de la mémoire tampon, les modifications de banques de noeuds de document (également appelée « nettoyage des modifications »).  Cette maintenance est configurée sur toutes les versions AEM et s’exécute automatiquement tous les jours à 2h du matin.  La tâche de maintenance pour configurer cette fonction est la même que celle du nettoyage en ligne de modification tar

La tâche de maintenance fonctionne uniquement dans le noeud de regroupement AEM leader par rapport à la réplication principale du groupe MongoDB.  Il fonctionne comme suit :

  1. Vérifiez s'il existe un point de contrôle datant de plus de 24 heures
  2. Interrogez MongoDB pour les documents supprimés dont la date est antérieure à celle de la révision maximale.
  3. Supprimez les documents par lots.
  4. Interrogez MongoDB pour les documents de révision « scindés » plus anciens que la révision maximale.
  5. Supprimez les documents par lots.

Planification recommandée.

Cette maintenance doit être effectuée au moins quotidiennement.  Par défaut, elle démarre à 2h du matin et s'exécute jusqu'à la fin.  En revanche, plus l’exécution est fréquente, plus elle est rapide.  En outre, plus elle s’exécute fréquemment, plus les performances d’écriture Oak sont élevées.  Notez que lors de son exécution, elle affectera les performances MongoDB.  Elle ne doit fonctionner que si un minimum d'utilisateurs sont présents sur le système.

Exemple de sortie de journal.

L’exemple de sortie de journal ci-dessous illustre les messages de début et de fin de journalisation pour une exécution réussie du nettoyage de la mémoire tampon.

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}

Maintenance de fichier binaire Oak (BLOB).

Depuis AEM 6.3, la configuration par défaut du stockage de référentiel Oak est une banque de segments tar avec une banque de fichiers de données configurée pour stocker des fichiers binaires.  Par défaut, une banque de donnée stocke des fichiers binaires qui sont de 4 Ko ou plus.  Dans une installation par défaut, la banque de données se trouve sous crx-quickstart/repository/datastore dans le système de fichiers du serveur.  Ces fichiers comprennent les fichiers jar, images, JavaScript, css, les packages, les fichiers d’index lucene et tout autre fichier binaire téléchargé sur AEM.  Ces fichiers sont référencés dans les révisions des propriétés de nœuds binaires dans la banque de noeuds.

La banque de données est conçue pour stocker des fichiers un à un, ce qui signifie que si le même fichier est téléchargé sur deux emplacements différents dans Oak, un seul fichier sera stocké.  En conséquence, les fichiers ne sont jamais supprimés de la banque de données tant que le nettoyage de la mémoire tampon de la banque de données est en cours.

La maintenance de GC BLOB (alias « nettoyage de la mémoire tampon de la banque de données ») s'applique aux banques binaires de fichiers, S3 et Mongo BLOB dans Oak.  Reportez-vous à la documentation officielle pour plus d’informations sur cette rubrique :

Planification recommandée.

Par défaut, il s'agit d'une tâche de maintenance hebdomadaire qui fonctionne le samedi à partir de 2h du matin et s'exécute jusqu'à la fin.  Il est recommandé d’exécuter cette tâche de maintenance chaque semaine pour éviter les problèmes d'espace disque.  Cependant, si les volumes de stockage ont beaucoup d’espace, elle peut être exécutée moins fréquemment en toute sécurité.  L'absence de cette maintenance risque uniquement de gaspiller de l'espace disque.

Exemple de sortie de journal.

L’exemple de la sortie de journal ci-dessous illustre les messages de début et de fin du journal pour une exécution réussie du nettoyage de la mémoire tampon de la banque de données :

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]









Workflow Purge Maintenance

Chaque fois qu'un flux de travail est démarré dans AEM, un historique de flux de travail est créé sous /etc/workflow/instances dans le référentiel Oak.  Au fil du temps, les nœuds de l'historique du flux de travail peuvent s'accumuler et affecter les performances du système.  Pour éviter cette situation, vous devez exécuter Workflow Purge Maintenance.

Voir cette documentation pour plus de détails sur la configuration et l'exécution de cette tâche de maintenance.

Planification recommandée.

Cette tâche de maintenance doit être exécutée toutes les semaines.

Exemple de sortie de journal.

Les messages de journal ci-dessous montrent une exécution réussie de Workflow Purge Maintenance :

*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​

Maintenance de purge de version

Dans une installation AEM par défaut, les versions sont créées lorsque vous publiez ou annulez la publication de pages ou d'éléments, transférez ou remplacez des éléments.  Les versions sont stockées sous la forme de nœuds sous /jcr:system/jcr:versionStorage dans le référentiel Oak.  Ces nœuds conservent les références aux fichiers binaires dans la banque de données.  Avec le temps, les versions s'empilent, ce qui affecte les performances du système et l’utilisation du disque.  Les index de recherche, le stockage Tar ou Mongo et le DataStore s'encombrent de données supplémentaires provenant d’anciens historiques. Pour récupérer de l’espace disque et rétablir les performances du système, vous devez exécuter une purge par le biais de la fonction Version Purge.

  • Consultez la documentation pour savoir comment configurer et exécuter la fonction Version Purge.
  • Consultez cet article pour savoir comment éviter les problèmes rencontrés avec Version Purge.

Planification recommandée.

Cette tâche de maintenance doit être exécutée mensuellement.

Exemple de sortie de journal.

La fonction Version purge n'enverra des messages dans les journaux que si elle purge correctement les versions.  Si elle ne parvient pas à purger certaines versions, elle renverra une erreur et continuera de purger les autres versions.

Le message journal ci-dessous est un exemple de purge réussie d’une version :

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

L’erreur ci-dessous est un exemple d'échec de purge de version :

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

Maintenance de purge du journal d'audit

Dans une installation AEM par défaut, les pages ou les actifs sont créés/transférés, modifiés, supprimés ou publiés (ou dépubliés) lorsque les journaux d'audit sont créés.  Les journaux d'audit sont stockés sous la forme de nœuds sous /var/audit dans le référentiel Oak.  Avec le temps, ces nœuds s'empilent et affectent les performances du système.  Pour éviter ce cas de figure, vous devez exécuter des opérations de maintenance de journal d'audit.

Consultez cette documentation pour savoir comment configurer et exécuter la maintenance de purge du journal d'audit.

Planification recommandée.

Cette tâche de maintenance doit être exécutée mensuellement.

Exemple de sortie de journal.

Les messages journaux ci-dessous indiquent une exécution réussie de la fonction de maintenance du journal d'audit :

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

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne