DocumentationAEM 6.4Guide d’administration

Récupération de l’espace mémoire de l’entrepôt de données data-store-garbage-collection

Last update: Thu May 04 2023 00:00:00 GMT+0000 (Coordinated Universal Time)

Créé pour :

  • Admin
CAUTION
AEM 6.4 a atteint la fin de la prise en charge étendue et cette documentation n’est plus mise à jour. Pour plus d’informations, voir notre période de support technique. Rechercher les versions prises en charge here.

Lorsqu’une ressource WCM conventionnelle est supprimée, la référence à l’enregistrement d’entrepôt de données sous-jacent peut être supprimée de la hiérarchie de nœud, mais l’enregistrement d’entrepôt de données lui-même est conservé. Cet enregistrement d’entrepôt de données non référencé est alors considéré comme faisant partie des « données à nettoyer » qu’il n’est pas utile de conserver. Dans les cas où il existe un certain nombre de ressources de mémoire, il est préférable de les supprimer afin de préserver de l’espace et d’optimiser les performances de sauvegarde et de maintenance du système de fichiers.

Le plus souvent, une application WCM tend à collecter des informations, mais à ne pas les supprimer aussi souvent. Bien que de nouvelles images soient ajoutées qui remplacent même les anciennes versions, le système de contrôle de version conserve encore l’ancienne version et prend sa restauration en charge si nécessaire. Ainsi, la majorité du contenu que nous pensons ajouter au système est définitivement stocké. Quelle est donc la source type de "déchets" dans le référentiel que nous pourrions vouloir nettoyer ?

AEM utilise le référentiel comme stockage pour un certain nombre d'activités internes et de maintenance :

  • Packages créés et téléchargés
  • Fichiers temporaires créés pour la réplication de publication
  • Payloads des workflows
  • Ressources créées temporairement lors du rendu de la gestion des ressources numériques

Lorsque l’un de ces objets temporaires est assez volumineux pour devoir être stocké dans l’entrepôt de données et lorsque cet objet n’est plus utilisé, l’enregistrement d’entrepôt de données lui-même demeure en tant que « données à nettoyer ». Dans une application de création/publication WCM standard, le processus d’activation de publication constitue généralement la plus grande source de données à nettoyer de ce type. Lorsque des données sont répliquées en publication, elles sont d’abord regroupées dans des collections ayant un format de données efficace nommé « Durbo » et stockées dans le référentiel, sous /var/replication/data. Les lots de données dépassent souvent en taille le seuil de taille critique du magasin de données et finissent donc par être stockés comme des enregistrements de magasins de données. Lorsque la réplication est terminée, le nœud dans /var/replication/data est supprimé, mais l’enregistrement du magasin de données demeure en tant que « données à nettoyer ».

Les packages constituent une autre source de données à nettoyer récupérables. Les données de package, comme tout le reste, sont stockées dans le référentiel et, donc, pour les packages dont la taille dépasse 4 Ko, dans l’entrepôt de données. Au cours d’un projet de développement ou au fil du temps, lors de la maintenance d’un système, les modules peuvent être créés et reconstruits de nombreuses fois, chaque version entraînant un nouvel enregistrement de l’entrepôt de données, rendant orphelin l’enregistrement de la version précédente.

Comment fonctionne le nettoyage de la mémoire d’entrepôt de données ? how-does-data-store-garbage-collection-work

Si le référentiel a été configuré avec un entrepôt de données externe, le nettoyage de la mémoire d’entrepôt de données est exécuté automatiquement dans le cadre de la période de maintenance hebdomadaire. L’administrateur système peut également exécuter le nettoyage de la mémoire du magasin de données manuellement selon les besoins. En général, il est recommandé d’effectuer le nettoyage de la mémoire d’entrepôt de données périodiquement, mais de prendre en compte les facteurs suivants lors de la planification du nettoyage de la mémoire d’entrepôt de données :

  • Le nettoyage de la mémoire d’entrepôt de données prend du temps et peut avoir un impact sur les performances. Il doit donc être planifié en conséquence.
  • La suppression des enregistrements de mémoire d’entrepôt de données n’affecte pas les performances normales. Il ne s’agit donc pas d’une optimisation des performances.
  • Si l’utilisation du stockage et les facteurs connexes tels que les temps de sauvegarde ne sont pas un problème, le nettoyage de la mémoire d’entrepôt de données peut être différé en toute sécurité.

Le nettoyeur de la mémoire d’entrepôt de données prend d’abord note de l’horodatage actuel lorsque le processus commence. La collecte est ensuite effectuée à l’aide d’un algorithme de modèle de marquage/balayage à plusieurs passages.

Lors de la première phase, le nettoyeur de la mémoire d’entrepôt de données traverse entièrement le contenu du référentiel. Pour chaque objet de contenu qui contient une référence à un enregistrement d’entrepôt de données, il localise le fichier dans le système de fichiers, exécutant une mise à jour de métadonnées (en modifiant l’attribut « dernière modification » ou MTIME). À ce stade, les fichiers accessibles par cette phase deviennent plus récents que l’horodatage de ligne de base initial.

Lors de la seconde phase, le nettoyeur de la mémoire d’entrepôt de données traverse la structure de répertoires physique d’un entrepôt de données à peu près comme une opération de recherche. Il examine l’attribut "last modified" ou MTIME du fichier et détermine ce qui suit :

  • Si l’attribut MTIME est plus récent que l’horodatage de base initial, le fichier a été trouvé lors de la première phase ou il s’agit d’un fichier entièrement nouveau qui a été ajouté au référentiel pendant l’exécution du processus de nettoyage. Dans l'un ou l'autre de ces cas, l'enregistrement est considéré comme principal et le fichier ne doit pas être supprimé.
  • Si le MTIME est antérieur à l’horodatage initial de la ligne de base, le fichier n’est pas un fichier activement référencé et il est considéré comme une mémoire pouvant être supprimée.

Cette approche fonctionne bien pour un nœud unique avec un entrepôt de données privé. Toutefois, l’entrepôt de données peut être partagé, et si c’est le cas, les références en direct potentiellement actives aux enregistrements d’entrepôt de données d’autres référentiels ne sont pas vérifiées, et les fichiers référencés actifs peuvent être supprimés par erreur. Il est impératif que l’administrateur système comprenne la nature partagée de l’entrepôt de données avant de planifier un nettoyage de la mémoire et n’utilise que le simple processus de nettoyage de la mémoire d’entrepôt de données intégré lorsqu’il est connu que l’entrepôt de données n’est pas partagé.

NOTE
Lorsque le nettoyage de la mémoire est effectué dans une configuration d’entrepôt de données partagé ou en cluster (avec Mongo ou Segment Tar), le journal peut contenir des avertissements sur l’impossibilité de supprimer certains ID de blob. Ces avertissements se produisent, car les ID de blob supprimés durant un nettoyage précédent sont à nouveau référencés de manière incorrecte par d’autres nœuds partagés ou clusters qui n’ont pas d’informations sur les suppressions des ID. Lorsque le nettoyage est effectué, un avertissement est donc enregistré dans le journal après une tentative de suppression d’un ID qui avait déjà été supprimé lors du précédent nettoyage. Ce comportement n’a aucune incidence sur les performances ou les fonctionnalités.

Exécution du nettoyage de la mémoire d’entrepôt de données running-data-store-garbage-collection

Il existe trois façons d’exécuter le nettoyage de la mémoire d’entrepôt de données, selon la configuration de l’entrepôt de données sur laquelle AEM s’exécute :

  1. Via le nettoyage de révision : un mécanisme de récupération de l’espace mémoire généralement utilisé pour le nettoyage des entrepôts de nœuds.

  2. Via Nettoyage de la mémoire d’entrepôt de données - un mécanisme de nettoyage de la mémoire spécifique aux entrepôts de données externes, disponible dans le tableau de bord des opérations.

  3. Via le Console JMX.

Si TarMK est utilisé comme entrepôt de nœuds et entrepôt de données, le nettoyage de révision peut être utilisé pour le nettoyage de la mémoire de l’entrepôt de nœuds et l’entrepôt de données. Cependant, si un entrepôt de données externe est configuré comme entrepôt de données de système de fichiers, le nettoyage de la mémoire d’entrepôt de données doit être explicitement déclenché séparément du nettoyage de révision. Le nettoyage de la mémoire d’entrepôt de données peut être déclenché par le biais du tableau de bord des opérations ou de la console JMX.

Le tableau ci-dessous indique le type de nettoyage de la mémoire d’entrepôt de données qui doit être utilisé pour tous les déploiements d’entrepôt de données pris en charge dans AEM 6 :

Magasin de nœuds
Magasin de données
Mécanisme de récupération de l’espace mémoire
TarMK
TarMK
Nettoyage des révisions (les binaires sont alignés avec le magasin de segments)
TarMK
Système de fichiers externe

Tâche de nettoyage de la mémoire du magasin de données via le tableau de bord des opérations

Console JMX

MongoDB
MongoDB

Tâche de nettoyage de la mémoire du magasin de données via le tableau de bord des opérations

Console JMX

MongoDB
Système de fichiers externe

Tâche de nettoyage de la mémoire du magasin de données via le tableau de bord des opérations

Console JMX

Exécution du nettoyage de la mémoire du magasin de données via le tableau de bord des opérations running-data-store-garbage-collection-via-the-operations-dashboard

La période de maintenance hebdomadaire intégrée, disponible via le tableau de bord des opérations, contient une tâche intégrée pour déclencher le nettoyage de la mémoire du magasin de données à 1 heure du matin le dimanche.

Si vous devez exécuter le nettoyage de la mémoire d’entrepôt de données en dehors de cette période, il peut être déclenché manuellement via le tableau de bord des opérations.

Avant d’exécuter le nettoyage de la mémoire d’entrepôt de données, vous devez vérifier qu’aucune sauvegarde n’est en cours d’exécution à ce moment-là.

  1. Ouvrez le tableau de bord des opérations en procédant comme suit : Navigation -> Outils -> Opérations -> Maintenance.

  2. Cliquez ou appuyez sur Période de maintenance hebdomadaire.

    chlimage_1-121

  3. Sélectionnez la tâche Nettoyage de la mémoire du magasin de données, puis cliquez ou appuyez sur l’icône Exécuter.

    chlimage_1-122

  4. Le nettoyage de la mémoire du magasin de données s’exécute et son statut s’affiche sur le tableau de bord.

    chlimage_1-123

NOTE
La tâche de nettoyage de la mémoire du magasin de données est uniquement visible si vous avez configuré un magasin de données basé sur les fichiers. Consultez Configuration de magasins de nœuds et de données dans AEM 6 pour obtenir des informations sur la configuration d’un magasin de données basé sur les fichiers.

Exécution du nettoyage de la mémoire d’entrepôt de données via la console JMX running-data-store-garbage-collection-via-the-jmx-console

Cette section aborde le nettoyage de la mémoire d’entrepôt de données via la console JMX. Si votre installation est configurée sans entrepôt de données externe, ceci ne s’applique pas. Voir plutôt les instructions sur l’exécution du nettoyage de révision sous Maintenance du référentiel.

NOTE
Si vous exécutez TarMK avec un magasin de données externe, vous devez exécuter le nettoyage de révision d’abord pour que le nettoyage soit efficace.

Pour exécuter la récupération de l’espace mémoire :

  1. Dans la console de gestion OSGi Apache Felix, mettez en surbrillance le Principal et sélectionnez JMX dans le menu suivant.

  2. Ensuite, recherchez puis cliquez sur le bouton Gestionnaire de référentiel MBean (ou accédez à https://<host>:<port>/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Drepository+manager%2Ctype%3DRepositoryManagement).

  3. Cliquez sur startDataStoreGC(boolean markOnly).

  4. Entrez true pour le paramètre markOnly si nécessaire :

    table 0-row-2 1-row-2
    Option Description
    boolean markOnly Définissez cette variable sur true pour marquer uniquement les références et ne pas effectuer de balayage dans l’opération de marquage et de balayage. Ce mode doit être utilisé lorsque le BlobStore sous-jacent est partagé entre plusieurs référentiels. Pour tous les autres cas, définissez ce paramètre sur false pour effectuer le nettoyage complet de la mémoire.

  5. Cliquez sur Invoquer. CRX effectue la récupération de l’espace mémoire et indique quand celle-ci est terminée.

NOTE
Le nettoyage de la mémoire du magasin de données ne collecte pas les fichiers qui ont été supprimés au cours des dernières 24 heures.
NOTE
La tâche de nettoyage de la mémoire du magasin de données ne commence que si vous avez configuré un magasin de données basé sur les fichiers. Si aucun magasin de données de fichier externe n’a été configuré, la tâche renvoie le message Cannot perform operation: no service of type BlobGCMBean found après l’appel. Consultez Configuration de magasins de nœuds et de données dans AEM 6 pour obtenir des informations sur la configuration d’un magasin de données basé sur les fichiers.

Automatisation du nettoyage de la mémoire d’entrepôt de données automating-data-store-garbage-collection

Si possible, le nettoyage de la mémoire d’entrepôt de données doit être exécuté lorsque la charge du système est faible, par exemple le matin.

La période de maintenance hebdomadaire intégrée, disponible via le tableau de bord des opérations, contient une tâche intégrée pour déclencher le nettoyage de la mémoire d’entrepôt de données à 1 heure du matin le dimanche. Vous devez également vérifier qu’aucune sauvegarde n’est en cours à ce moment. Le début de la fenêtre de maintenance peut être personnalisé au besoin à partir du tableau de bord.

NOTE
La raison pour laquelle vous pouvez ne pas l’exécuter simultanément est que les anciens fichiers (et inutilisés) du magasin de données sont également sauvegardés, de sorte que s’il est nécessaire de restaurer une ancienne révision, les fichiers binaires figurent encore dans la sauvegarde.

Si vous ne souhaitez pas exécuter le nettoyage de la mémoire du magasin de données avec la période de maintenance hebdomadaire dans le tableau de bord des opérations, vous pouvez également l’automatiser à l’aide des clients HTTP wget ou curl. Voici un exemple illustrant comment automatiser la sauvegarde à l’aide de la commande curl :

CAUTION
Dans les exemples de commande curl suivants, il se peut que divers paramètres doivent être configurés pour votre instance. Par exemple, le nom d’hôte (localhost), le port (4502), le mot de passe administrateur (xyz) et divers paramètres pour le nettoyage effectif de la mémoire du magasin de données.

Voici un exemple de commande curl invoquant le nettoyage de la mémoire du magasin de données via la ligne de commande :

curl -u admin:admin -X POST --data markOnly=true  http://localhost:4503/system/console/jmx/org.apache.jackrabbit.oak"%"3Aname"%"3Drepository+manager"%"2Ctype"%"3DRepositoryManagement/op/startDataStoreGC/boolean

La commande curl est immédiatement renvoyée.

Vérification de la cohérence de l’entrepôt de données checking-data-store-consistency

La vérification de la cohérence de l’entrepôt de données signale les fichiers binaires d’entrepôt de données manquants, mais encore référencés. Pour lancer une vérification de cohérence, procédez comme suit :

  1. Accédez à la console JMX. Pour plus d’informations sur l’utilisation de la console JMX, consultez cet article.

  2. Recherchez le Blob GC MBean et cliquez dessus.

  3. Cliquez sur le lien checkConsistency().

Une fois la vérification de cohérence terminée, un message affiche le nombre de fichiers binaires signalés comme manquants. Si le nombre est supérieur à 0, vérifiez le fichier journal error.log pour obtenir plus de détails sur les fichiers manquants.

Vous trouverez ci-dessous un exemple de la façon dont les fichiers binaires manquants sont répertoriés dans les journaux :

11:32:39.673 INFO [main] MarkSweepGarbageCollector.java:600 Consistency check found [1] missing blobs

11:32:39.673 WARN [main] MarkSweepGarbageCollector.java:602 Consistency check failure in the blob store : DataStore backed BlobStore [org.apache.jackrabbit.oak.plugins.blob.datastore.OakFileDataStore], check missing candidates in file /tmp/gcworkdir-1467352959243/gccand-1467352959243
recommendation-more-help
5ce3024a-cbea-458b-8b2f-f9b8dda516e8