Nettoyage de révision

Présentation

Chaque mise à jour du référentiel crée une nouvelle révision de contenu. Par conséquent, à chaque mise à jour, la taille du référentiel augmente. Pour éviter une croissance incontrôlée au référentiel, il faut nettoyer les anciennes révisions pour libérer de l’espace sur le disque. Cette fonctionnalité de maintenance est appelée le nettoyage des révisions. Elle est disponible sous forme de programme hors ligne depuis AEM 6.0.

Une version en ligne de cette fonctionnalité, baptisée Nettoyage des révisions en ligne, a été introduite dans AEM 6.3. Comparé au nettoyage des révisions hors ligne où l’instance AEM doit être arrêtée, le nettoyage des révisions en ligne peut être exécuté en maintenant l’instance AEM en ligne. Le nettoyage des révisions en ligne est activé par défaut, car il s’agit de la méthode recommandée pour effectuer un nettoyage des révisions.

Remarque : Consultez la Vidéo pour une présentation et comment utiliser le nettoyage de révision en ligne.

Le processus de nettoyage des révisions en ligne s’effectue en trois phases : l’estimation, la compression et le nettoyage. L’estimation permet de déterminer s’il est nécessaire d’exécuter la phase suivante (compressions) selon la quantité de mémoire pouvant être libérée. Pendant la phase de compression, les segments et les fichiers tar sont réécrits en omettant tout contenu inutilisé. La phase de nettoyage permet de supprimer par la suite les anciens segments, y compris toute la mémoire qu’ils peuvent contenir. Généralement, le mode hors ligne permet de récupérer plus d’espace, car le mode en ligne doit prendre en compte le système opérationel d’AEM, ce qui empêche certains segments d’être collectés.

Pour plus de détails sur le processus de nettoyage des révisions, consulter les liens suivants :

De plus, vous pouvez également lire la documentation officielle sur les chênes.

Quand utiliser le nettoyage de la révision en ligne plutôt que le nettoyage de la révision hors ligne ?

Il est recommandé de procéder au nettoyage des révisions en ligne. L’utilisation du nettoyage des révisions hors ligne doit être limitée à des cas exceptionnels, par exemple, avant d’effectuer une migration vers un nouveau format de stockage ou si le service clientèle d’Adobe vous demande de le faire.

Comment exécuter le nettoyage des révisions en ligne ?

Le nettoyage des révisions en ligne est programmé par défaut pour s’exécuter automatiquement une fois par jour sur les instances de publication et d’auteur d’AEM. Vous devez simplement définir la fenêtre de maintenance pendant une période où le niveau d’activité de l’utilisateur est aussi bas que possible. La nettoyage des révisions en ligne peut être configuré comme suit :

  1. Dans la fenêtre principale de l'AEM, accédez à Outils - Opérations - Tableau de bord - Maintenance ou pointez votre navigateur vers : https://serveraddress:serverport/libs/granite/operations/content/maintenance.html

    chlimage_1-90

  2. Passez la souris sur Daily Maintenance Window et cliquez sur l'icône Settings.

    chlimage_1-91

  3. Saisissez les valeurs souhaitées (périodicité, heure de début, heure de fin) et cliquez sur Enregistrer.

    chlimage_1-92

Autrement, si vous desirez effectuer le nettoyage manuellement vous pouvez :

  1. Accédez à Outils - Opérations - Tableau de bord - Maintenance ou accédez directement à https://serveraddress:serverport/libs/granite/operations/content/maintenance.html.

  2. Cliquez sur la fenêtre Maintenance quotidienne.

  3. Passez la souris sur l’icône Nettoyage de révision.

  4. Cliquez sur Exécuter.

    chlimage_1-93

Exécution du nettoyage des révisions en ligne après le nettoyage des révisions hors ligne

Le processus de nettoyage des révisions récupère les anciennes révisions par génération. Cela signifie qu’une nouvelle génération est créée et conservée sur le disque chaque fois que vous exécutez le nettoyage des révisions. Il existe toutefois une différence entre les deux types de nettoyage des révisions : le nettoyage des révisions hors ligne conserve une génération tandis que le nettoyage des révisions en ligne conserve deux générations. Ainsi, lorsque vous exécutez le nettoyage de la révision en ligne après la révision hors ligne, le nettoyage suivant se produit :

  1. Une fois la première révision en ligne nettoyée, le référentiel sera de taille doublon. Cela est dû au fait que deux générations sont à présent conservées sur le disque.
  2. Au cours des exécutions suivantes, le référentiel croît temporairement pendant la création de la nouvelle génération, puis se stabilise à nouveau à sa taille après la première exécution, à mesure que le processus de nettoyage de la révision en ligne récupère la génération précédente.

Gardez également à l’esprit qu’en fonction du type et du nombre de validations, la taille de chaque génération peut varier par rapport à la précédente. La taille finale peut donc varier d’une exécution à l’autre.

C’est pourquoi il est recommandé d’opter pour une taille de disque au moins deux à trois fois supérieure à celle estimée initialement pour le référentiel.

Modes de compression complète et de compression des révisions les plus récentes

AEM 6.5 introduit deux nouveaux modèles pour la phase de ​compactiondu processus de nettoyage de la révision en ligne :

  • Le mode compaction complète réécrit tous les segments et fichiers tar dans l’ensemble du référentiel. La phase de nettoyage suivante peut donc supprimer un maximum d’informations parasites du référentiel. Étant donné qu’une compression complète affecte l’ensemble du référentiel, cette opération nécessite une quantité considérable de ressources systèmes et demande beaucoup de temps. La compression complète correspond à la phase de compression dans AEM 6.3.
  • Le mode de compaction tail réécrit uniquement les segments et fichiers tar les plus récents dans le référentiel. Il s’agit des segments et fichiers tar qui ont été ajoutés depuis la dernière exécution d’une compression, de quelque type que ce soit. La phase de nettoyage suivante peut donc ne supprimer que les informations parasites contenues dans la partie récente du référentiel. Étant donné que ce mode de compression ne concerne qu’une partie du référentiel, il consomme beaucoup moins de ressources système qu’une compression complète et s’avère bien plus rapide.

Ces modes de compression constituent un compromis entre efficacité et consommation des ressources : bien que moins efficace, la compression des révisions les plus récentes a également un impact moindre sur le fonctionnement normal du système. La compression complète, en revanche, s’avère plus efficace, mais a davantage de répercussions sur le fonctionnement normal du système.

AEM 6.5 s’enrichit également d’un mécanisme de déduplication du contenu plus efficace au cours de la compression, ce qui a pour effet de réduire l’empreinte du référentiel sur le disque.

Les deux graphiques ci-dessous présentent les résultats des tests réalisés en laboratoire interne. Ils illustrent la réduction des délais d’exécution moyens et de l’empreinte moyenne sur le disque dans AEM 6.5 par rapport à AEM 6.3 :

onrc-duration-6_4vs63 segmentstore-6_4vs63

Procédure de configuration des modes de compression complète et de compression des révisions les plus récentes

La configuration par défaut prévoit l’exécution d’une compression des révisions les plus récentes en semaine et d’une compression complète le dimanche. La configuration par défaut peut être modifiée en utilisant la nouvelle valeur de configuration full.gc.days de la RevisionCleanupTask tâche de maintenance.

Lorsque vous configurez la valeur full.gc.days, gardez à l’esprit que la compaction complète s’exécutera pendant le ou les jours définis dans la valeur et que la compaction de queue s’exécutera pendant les jours qui ne sont pas définis dans la valeur. Par exemple, si vous configurez la compression complète pour qu’elle s’exécute le dimanche, la compression des révisions les plus récentes sera exécutée du lundi au samedi. Si vous planifiez l’exécution d’une compression complète pour tous les jours de la semaine, aucune compression des révisions les plus récentes ne sera effectuée.

Veuillez également tenir compte des points suivants :

  • La compactionde la queue est moins efficace et a moins d'impact sur les opérations normales du système. Elle est donc destinée à être exécutée pendant les jours ouvrables.
  • La compactioncomplète est plus efficace mais a également un impact plus important sur les opérations normales du système. Il est donc conseillé de l’exécuter en dehors des jours ouvrables.
  • L’exécution des deux modes de compression doit être planifiée en dehors des heures de pointe.

Résolution des incidents

Lorsque vous utilisez les nouveaux modes de compression, gardez à l’esprit les points suivants :

  • Vous pouvez surveiller les activités d’entrée/sortie (E/S), par exemple : opérations d’E/S, processeur en attente des E/S, taille de la file d’attente de validation… Cela permet de déterminer si le système devient tributaire des entrées-sorties et doit faire l’objet d’une augmentation de capacité.
  • Le RevisionCleanupTaskHealthCheck indique l'état d'intégrité global du nettoyage de révision en ligne. Elle fonctionne de la même manière que dans AEM 6.3 et ne fait pas la distinction entre les deux modes de compression.
  • Les messages de journal contiennent des informations importantes concernant les modes de compression. Par exemple, au lancement du nettoyage des révisions en ligne, les messages de journal correspondants indiquent le mode de compression. De plus, dans certains cas limites d’exécution, le système revient au mode de compression complète alors que l’exécution d’une compression des révisions les plus récentes était programmée ; les messages de journal font alors état de cette modification. Les exemples de messages de journal ci-dessous indiquent le mode de compression et le changement de mode opéré :
TarMK GC: running tail compaction
TarMK GC: no base state available, running full compaction instead

Limites connues

Dans certains cas, basculer entre les deux modes de compression a pour effet de retarder le processus de nettoyage. Plus exactement, la taille du référentiel augmente après une compression complète (elle est multipliée par deux). L’espace supplémentaire sera récupéré lors de l’opération de compression des révisions les plus récentes suivante, le référentiel retrouvant alors une taille inférieure à celle qu’il avait avant la compression complète. Il est également conseillé d’éviter les exécutions de tâches de maintenance en parallèle.

Il est recommandé d’opter pour une taille de disque au moins deux à trois fois supérieure à celle estimée initialement pour le référentiel.

Foire aux questions sur le nettoyage des révisions en ligne

Remarques concernant la mise à niveau AEM 6.5

Questions Réponses
De quoi dois-je tenir compte lorsque j’effectue une mise à niveau vers AEM 6.5 ?

Le format de persistance de TarMK change avec AEM 6.5. Ces modifications ne nécessitent aucune étape de migration proactive. Les référentiels existants font l’objet d’une migration progressive, un processus totalement transparent pour l’utilisateur. Le processus de migration est lancé la première fois qu’AEM 6.5 (ou les outils associés) accède(nt) au référentiel.

Une fois la migration vers le format de persistance AEM 6.5 initiée, le référentiel ne peut plus être rétabli au format de persistance AEM 6.3 précédent.

Migration vers Oak Segment Tar

Questions Réponses
Pourquoi dois-je faire migrer le référentiel ?

Dans AEM 6.3, des changements au format de l'enregistrement étaient nécessaires, en particulier pour améliorer le rendement et l'efficacité du nettoyage de la révision en ligne. Ces modifications ne sont pas rétrocompatibles, et les référentiels créés avec l’ancien Oak Segment (AEM 6.2 et versions antérieures) doivent être migrés.

Autres avantages liés au changement de format du stockage :

Le format Tar précédent est-il toujours pris en charge ? Seul le nouveau format Oak Segment Tar est pris en charge dans AEM 6.3.
La migration du contenu est-elle toujours obligatoire ? Oui. À moins de commencer avec une nouvelle instance, vous aurez toujours à effectuer une migration du contenu.
Puis-je effectuer la mise à niveau vers la version 6.3 et effectuer la migration ultérieurement (par exemple, en utilisant une autre fenêtre de maintenance) ? Non, comme nous l’avons expliqué ci-dessus, la migration du contenu est obligatoire.
Les temps d’interruption peuvent-ils être évités durant la migration ? Non. C’est une opération unique qui ne peut pas être entreprise sur une instance en cours d’exécution.
Que se passe-t-il si j’exécute accidentellement le mauvais format de référentiel ? Si vous essayez d'exécuter le module de segment de chêne sur un référentiel de segment de chêne-tar (ou vice versa), le démarrage échoue avec une IllegalStateException avec le message "Format de segment non valide". Il n’y aura aucune corruption de données.
Une réindexation des index de recherche est-elle nécessaire ? Non. La migration du segment de chêne vers le segment de chêne-goudron introduit des modifications dans le format de conteneur. Les données contenues ne sont pas affectées et ne sont pas modifiées.
Comment calculer au mieux l’espace disque attendu pendant et après la migration ? La migration équivaut à recréer l’entrepôt de segments dans un nouveau format. Cela peut être utilisé pour calculer l’espace disque supplémentaire nécessaire durant la migration. Après la migration, l’ancien entrepôt de segments peut être supprimé pour récupérer de l’espace.
Comment estimer au mieux la durée de la migration ? Les performances de migration peuvent être considérablement améliorées si le nettoyage de la révision hors ligne est exécuté avant la migration. Nous conseillons à tous les clients de l’exécuter en tant que conditions préalables à la mise à niveau. En général, la durée de la migration doit être similaire à la durée de la tâche de nettoyage de la révision hors ligne, en supposant que la tâche de nettoyage de la révision hors ligne a été exécutée avant la migration.

Exécution du nettoyage des révisions en ligne

Questions Réponses
À quelle fréquence le nettoyage des révisions en ligne doit-il être exécuté ? Une fois par jour. C’est la configuration par défaut dans le tableau des opérations.
Comment puis-je configurer l’heure de début de la tâche de maintenance du nettoyage des révisions en ligne ? Voir la section Comment exécuter le nettoyage de révision en ligne.
Existe-t-il une fréquence maximale ne devant pas être dépassée pour le nettoyage des révisions en ligne ? Il est recommandé d’exécuter le nettoyage des révisions en ligne une fois par jour, tel que configuré par défaut.
Quels sont les indicateurs clés permettant de déterminer à quelle fréquence le nettoyage des révisions en ligne doit être effectué ? Il n’est pas nécessaire de déterminer la fréquence, étant donné que le nettoyage des révisions en ligne est configuré en tant que tâche de maintenance et s’exécute automatiquement de façon quotidienne.
Pourquoi le nettoyage des révisions en ligne ne récupère-t-il pas de l’espace lorsqu’il est exécuté pour la première fois ? Le nettoyage des révisions en ligne récupère les anciennes révisions par génération. Une nouvelle génération est générée à chaque fois que le nettoyage des révisions est exécuté. Seul le contenu vieux d’au moins deux générations sera récupéré, ce qui signifie que lors d’une première exécution, rien n’est récupéré.
Pourquoi le premier nettoyage des révisions en ligne ne permet-il pas de récupérer de l’espace lorsqu’il est exécuté après le nettoyage des révisions hors ligne ?

Alors que le nettoyage des révisions en ligne récupère les deux dernières générations, le processus hors ligne ne récupère que la dernière génération. Dans le cas d’un tout nouveau référentiel, le nettoyage en ligne ne récupère aucun espace lorsqu’il est exécuté pour la première fois après le nettoyage hors ligne, car il n’y a aucune génération suffisamment ancienne pour être récupérée.

Lisez également la section « Exécution du nettoyage des révisions en ligne après le nettoyage des révisions hors ligne » de ce chapitre.

L’auteur et la publication ont-ils des fenêtres de nettoyage des révisions en ligne différentes ? Cela dépend des heures de travail et des modèles de trafic de la présence en ligne du client. Les fenêtres de maintenance doivent être configurées en dehors des heures de production principales pour assurer la meilleure efficacité de nettoyage. S’il existe plusieurs instances de publication AEM (ferme TarMK), les fenêtres de maintenance pour le nettoyage des révisions en ligne doivent être fragmentées.
Existe-t-il des conditions préalables pour exécuter le nettoyage des révisions en ligne ?

Le nettoyage de la révision en ligne est disponible uniquement avec AEM versions 6.3 et ultérieures. Aussi, si vous utilisez une ancienne version d’AEM, vous devrez effectuer une migration vers le nouvel Oak Segment Tar.

Quels sont les facteurs qui déterminent la durée du nettoyage des révisions en ligne ? Les facteurs sont les suivants :
  • Taille du référentiel
  • Charge sur le système (demandes par minute, surtout les opérations d’écriture)
  • Modèle d’activité (lectures et écritures)
  • Spécifications matérielles (performances du processeur, mémoire, IOPS)
Les auteurs peuvent-ils travailler pendant l’exécution du nettoyage des révisions en ligne ? Oui, le nettoyage des révisions en ligne gère les écritures simultanées. Toutefois, le nettoyage des révisions en ligne fonctionne plus rapidement et plus efficacement sans transactions d’écriture simultanées. Il est recommandé de planifier la tâche de maintenance de nettoyage en ligne durant une période relativement calme sans beaucoup de trafic.
Quelles sont les conditions minimales requises en matière d’espace disque et de mémoire de tas lors de l’exécution du nettoyage des révisions en ligne ?

L’espace disque est surveillé en permanence lors du nettoyage des révisions en ligne. Si l’espace disque passe en dessous d’une certaine valeur, le processus est annulé. La valeur critique par défaut est de 25 % de l’encombrement sur le disque du référentiel, et elle n’est pas configurable.

Il est recommandé d’opter pour une taille de disque au moins deux à trois fois supérieure à celle estimée initialement pour le référentiel.

L’espace de tas libre est surveillé en permanence lors du processus de nettoyage. Si l’espace de tas disponible passe en dessous d’une certaine valeur, le processus est annulé. La valeur critique est configurée via org.apache.jackrabbit.oak.segment.SegmentNodeStoreService#MEMORY_THRESHOLD. La valeur par défaut est 15%.

Les recommandations sur le dimensionnement du tas de compression minimal ne sont pas séparées des recommandations sur le dimensionnement de la mémoire AEM. En règle générale : si une instance AEM est suffisamment bien dimensionnée pour gérer les cas d’utilisation et la charge utile attendue, le processus de nettoyage obtiendra suffisamment de mémoire.

Quel est l’impact attendu sur les performances pendant l’exécution du nettoyage des révisions en ligne ? Le nettoyage des révisions en ligne est un processus en arrière-plan qui lit et écrit sur le référentiel en même temps que les opérations normales du système. En particulier, il est peut-être nécessaire d’acquérir un accès exclusif au référentiel pendant une courte période, ce qui empêche toute autre thread d’écrire dans le référentiel.
Quelle est la durée estimée d’exécution du nettoyage des révisions en ligne ? Cela ne devrait pas prendre plus de 2 heures d’après les derniers tests de performance que nous avons réalisés en interne.
Que faire si le nettoyage des révisions en ligne dure plus longtemps ?
  • Assurez-vous qu’il est exécuté tous les jours.
  • Assurez-vous qu’il est exécuté pendant les activités minimales du référentiel en configurant les fenêtres de maintenance dans le Tableau de bord des opérations en conséquence.
  • Faites évoluer les ressources du système (processeur, mémoire, E/S).
Que se passe-t-il si le nettoyage des révisions en ligne dépasse la fenêtre de maintenance configurée ? Assurez-vous que d’autres tâches de maintenance ne retardent pas son exécution. Cela peut être le cas s’il y a plus de tâches de maintenance que de nettoyage des révisions en ligne exécutées dans la même fenêtre de maintenance. Notez que les tâches de maintenance suivantes sont exécutées consécutivement, sans ordre configurable.
Pourquoi le nettoyage de la mémoire est-il ignoré ?

Le nettoyage des révisions requiert une phase d’estimation pour décider s’il y a suffisamment de contenu inutilisé à nettoyer. L’estimateur compare la taille actuelle à la taille du référentiel après la dernière compression. Si la taille dépasse le delta configuré, le nettoyage sera effectué. Le delta de taille est défini à 1 Go. Cela signifie que si la taille du référentiel n'a pas augmenté de 1 Go depuis la dernière exécution de nettoyage, la nouvelle itération de nettoyage de révision sera ignorée.

Vous trouverez, ci-dessous, des entrées de journaux pertinentes pour la phase d’estimation :

  • Révision Le GC sera exécuté : Le delta de taille est N% ou N/N (octets N/N), donc l'exécution de compaction
  • Le GC de révision sera non exécuté : Le delta de taille est N% ou N/N (octets N/N), de sorte que la compaction est ignorée pour l'instant
Est-il possible d’annuler en toute sécurité la compression automatique si l’impact sur les performances est trop élevé ? Oui. Depuis AEM 6.3, il peut également être arrêté par l’intermédiaire de la fenêtre des tâches de maintenance du tableau de bord des opérations ou via JMX.
Si l’instance AEM est arrêtée pendant une tâche de nettoyage programmée, le processus s’arrête-t-il de manière sécurisée ou l’arrêt est-il bloqué jusqu’à la réalisation complète de la compression ? Le nettoyage des révisions est interrompu et le référentiel va s’arrêter en toute sécurité.
Que se passe-t-il si le système tombe en panne pendant le nettoyage des révisions en ligne ? Il n’existe aucun risque de corruption des données dans ce cas. Le reste des résidus sera nettoyé lors de la prochaine exécution.
Qu’arrive-t-il lorsque vous n’effectuez pas le nettoyage des révisions en ligne ? Le niveau de performances se dégrade au fil du temps.
Quelles révisions sont collectées ? Par défaut, le nettoyage des révisions en ligne collecte uniquement les révisions datant d’au moins 24 heures.
Que se passe-t-il en cas d'interférence excessive des écritures simultanées dans le référentiel ?

S’il y a des écritures simultanées sur le système, le nettoyage des révisions en ligne peut nécessiter un accès exclusif à l’écriture pour pouvoir effectuer les changements à la fin d’un cycle de compression. Le système passe en mode forceCompact, comme expliqué plus en détail dans la documentation sur le chêne. Pendant la compression forcée, un dispositif exclusif de verrouillage de l’écriture est acquis pour effectuer les modifications sans aucune écriture simultanée perturbatrice. Pour limiter l’impact sur les délais de réponse, une valeur de délai d’expiration peut être définie. Cette valeur est définie sur 1 minute par défaut, ce qui signifie que si la compression en force ne se termine pas dans un délai d’une minute, le processus de compression sera interrompu au profit d’autres commits simultanés.

La durée du pacte de force dépend des facteurs suivants :

  • matériel : spécifiquement IOPS. La durée décroît lorsqu’il y a plus d’IOPS.
  • taille de l’entrepôt de segments : la durée augmente en fonction de la taille de l’entrepôt de segments.

Comment le nettoyage des révisions en ligne est-il exécuté sur une instance de secours ?

Dans une configuration Cold Standby, seule l’instance principale doit être configurée pour exécuter le nettoyage des révisions en ligne. Sur l’instance de secours, le nettoyage des révisions en ligne n’a pas besoin d’être programmé de manière spécifique.

L'opération correspondante sur une instance Secondaire est le nettoyage automatique, ce qui correspond à la phase de nettoyage de la révision en ligne. Le nettoyage automatique est exécuté sur l’instance de secours après l’exécution du nettoyage des révisions en ligne sur l’instance principale.

Les phase de compression et d’estimation ne sont pas exécutées sur l’instance de secours.

Le nettoyage des révisions hors ligne peut-il libérer plus d’espace disque que le nettoyage des révisions en ligne ?

Le nettoyage des révisions hors ligne peut supprimer instantanément les anciennes révisions, alors que le nettoyage des révisions en ligne doit tenir compte des anciennes révisions qui sont toujours référencées par la pile de l’application. Le premier peut donc supprimer les résidus de manière plus agressive que le second, où l’effet est amortit au bout de quelques cycles de nettoyage de la mémoire.

Lisez également la section « Exécution du nettoyage des révisions en ligne après le nettoyage des révisions hors ligne » de ce chapitre.

Observations relatives aux opérations de fichiers mappés par la mémoire
  • Sur les environnements Windows, l’accès régulier aux fichiers est toujours appliqué, de sorte que l’accès mappé à la mémoire n’est pas utilisé. En règle générale, toute la RAM disponible doit être allouée au tas et la taille de segmentCache doit être augmentée. Vous augmentez le segmentCache en ajoutant l’option segmentCache.size à org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config (par exemple, segmentCache.size=20480). N’oubliez pas de laisser de la mémoire vive pour le système d’exploitation et d’autres processus.
  • Dans les environnements non Windows, augmentez la taille de la mémoire physique pour améliorer le mappage de mémoire du référentiel.

Surveillance du nettoyage des révisions en ligne

Que doit-on surveiller pendant le nettoyage de la révision en ligne ?
  • L'espace disque doit être surveillé lorsque le nettoyage de révision en ligne est activé. S’il n’y a pas sufisamment d’espace disque, soit le processus de nettoyage ne sera pas lancé, ou il sera arrêté de manière préventive.
  • Vérifiez les journaux pendant la durée d’exécution du nettoyage des révisions en ligne. Cela ne devrait pas durer plus de 2 heures.
  • Nombre de points de contrôle. S’il existe plus de 3 points de contôle durant l’exécution de la compression, il est recommandé de nettoyer les points de contôle.
Comment vérifier si le nettoyage de la révision en ligne a réussi ?

Vous pouvez vérifier si le nettoyage de la révision en ligne s'est terminé correctement en vérifiant les journaux.

Par exemple, "TarMK GC #{}: compaction completed in {} ({} ms), after {} cycles" signifie l’étape de compactage terminée avec succès, sauf si elle est précédée du message "TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles", ce qui signifie qu’il y a eu trop de charges simultanées.

En conséquence, un message "TarMK GC #{}: cleanup completed in {} ({} ms" indique que l’étape de nettoyage a été terminée avec succès.

Où trouver les statistiques des dernières exécutions de nettoyage de révision en ligne ?

Le statut, les progrès et les statistiques sont exposés via JMX (SegmentRevisionGarbageCollection MBean). Pour plus d'informations sur le SegmentRevisionGarbageCollection MBean, consultez le paragraphe suivant.

L'avancement peut être suivi via l'attribut EstimatedRevisionGCCompletion de la variable SegmentRevisionGarbageCollection MBean.

Vous pouvez obtenir une référence du MBean à l'aide de ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection”.

N’oubliez pas que les statistiques sont dospnibles uniquement avec le dernier démarrage de système. L’outil de surveillance externe peut être utilisé pour conserver les données au-delà de la disponibilité d’AEM. Voir la documentation AEM pour l'attachement des contrôles d'intégrité à Nagios comme exemple pour un outil de surveillance externe.

Quelles sont les entrées de journal pertinentes ?
  • Le nettoyage de la révision en ligne a démarré / arrêté
    • Le nettoyage de la révision en ligne se compose de trois phases : estimation, compaction et nettoyage. La phase d’estimation peut forcer l’omission des phases de compression et de nettoyager si le référentiel ne contient pas suffisament de résidus. Dans la dernière version de AEM, le message "TarMK GC #{}: estimation started" marque le début de l'estimation, "TarMK GC #{}: compaction started, strategy={}" marque le début de compaction et "TarMK GC #{}: cleanup started. Current repository size is {} ({} bytes" le début de nettoyage.
  • Espace disque gagné par le nettoyage de la révision
    • L'espace n'est récupéré que lorsque la phase de nettoyage est terminée. L'achèvement de la phase de nettoyage est marqué par le message du journal "TarMK GC #{}: cleanup completed in {} ({} ms". La dimension après nettoyage est {} ({} octets) et l’espace récupéré{} ({} octets). Le poids/la profondeur de la carte de compression est {}/{} ({} octets/{}).”.
  • Un problème s'est produit lors du nettoyage de la révision
    • Il y a de nombreuses conditions d'échec, toutes sont marquées par des messages de journal WARN ou ERROR commençant par "TarMK GC".

Consultez également la section Résolution des problèmes en fonction des messages d’erreur ci-dessous.

Comment vérifier combien d'espace a été récupéré après le nettoyage de la révision en ligne ? Un message se trouve dans le journal à la fin du cycle de nettoyage : "TarMK GC #3: cleanup completed" qui comprend la taille du référentiel et la quantité de déchets récupérés.
Comment vérifier l'intégrité du référentiel une fois le nettoyage de la révision en ligne terminé ?

Une vérification de l'intégrité du référentiel n'est pas nécessaire après le nettoyage de la révision en ligne.

Cependant, vous pouvez effectuer les actions suivantes pour vérifier l’état du référentiel après le nettoyage :

  • Référentiel vérification de la traversée
  • Utilisez l'outil d'exécution de chêne une fois le processus de nettoyage terminé pour vérifier les incohérences. Pour plus d’informations sur la façon de procéder, consultez la documentation Apache. Vous n'avez pas besoin de fermer AEM pour exécuter l'outil.
Comment détecter si le nettoyage de la révision en ligne a échoué et quelles sont les étapes à restaurer ? Les conditions d'échec sont marquées par les messages du journal WARN ou ERROR commençant par "TarMK GC". Consultez également la section Résolution des problèmes en fonction des messages d’erreur ci-dessous.
Quelles sont les informations exposées dans le bilan d'intégrité du nettoyage de révision ? Comment et quand contribue-t-elle aux niveaux d’état codés par des couleurs ?

Le contrôle d'intégrité du nettoyage de la révision fait partie du Tableau de bord d'exploitation .

L'état est VERT si la dernière exécution de la tâche de maintenance de nettoyage de révision en ligne est terminée.

Il sera JAUNE si la tâche de maintenance de nettoyage de révision en ligne a été annulée une fois.

Il sera RED si la tâche de maintenance de nettoyage de révision en ligne a été annulée trois fois de suite. Dans ce cas, une interaction manuelle est nécessaire ou le nettoyage de la révision en ligne est susceptible d'échouer à nouveau. Pour plus d'informations, consultez la section Dépannage ci-dessous.

Veuillez aussi noter que l’état de la vérification de l’intégrité sera réinitialisé après le redémarrage du système. Par conséquent, une instance fraîchement redémarrée affiche un état vert sur la vérification d’intégrité du nettoyage des révisions. L’outil de surveillance externe peut être utilisé pour conserver les données au-delà de la disponibilité d’AEM. Voir la documentation AEM pour l'attachement des contrôles d'intégrité à Nagios comme exemple pour un outil de surveillance externe.

Comment surveiller le nettoyage automatique sur une instance Secondaire ?

Le statut, les progrès et les statistiques sont exposés via JMX en utilisant le SegmentRevisionGarbageCollection MBean. Voir aussi la documentation sur les chênes suivante.

Vous pouvez obtenir une référence du MBean en utilisant ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection”.

Notez que les statistiques sont disponibles uniquement à partir du dernier démarrage du système. L’outil de surveillance externe peut être utilisé pour conserver les données au-delà de la disponibilité d’AEM. Voir aussi la documentation AEM pour l'attachement des contrôles d'intégrité à Nagios comme exemple d'outil de surveillance externe.

Les fichiers de journal peuvent aussi être utilisés pour vérifier l’état, le progrès et les statistiques du nettoyage automatique.

Que doit-on surveiller pendant le nettoyage automatique sur une instance Secondaire ?

  • L'espace disque doit être surveillé lors de l'exécution du nettoyage automatique.
  • Le délai d’exécution (via les journaux) pour vous assurer que 2 heures ne sont pas dépassées.
  • Taille de la banque de segments après l’exécution du nettoyage automatique. La taille de l’entrepôt de segments sur l’instance de secours doit être à peu près le même que celle de l’instance principale.

Dépannage du nettoyage des révisions en ligne

Quel est le pire qui puisse arriver si vous n’exécutez pas le nettoyage des révisions en ligne ? L’instance AEM ne disposera plus d’espace disque, ce qui causera des pannes de production.
Un trafic élevé d’utilisateurs risque-t-il de causer des problémes d’exécution du nettoyage des révisions en ligne sur une instance de publication ? Le trafic élevé d’utilisateurs peut impacter la réussite de l’exécution de la phase de compression.
D’après la vérification d’intégrité et les entrées du journal, le processus de nettoyage des révisions en ligne a échoué trois fois de suite. Que doit-on faire pour assurer le succès du nettoyage des révisions en ligne ? Vous pouvez prendre plusieurs mesures pour trouver et résoudre le problème:
  • Tout d’abord, vérifiez les entrées du journal.
  • En fonction des informations contenues dans les journaux, prenez une mesure appropriée :
    • Si les journaux indiquent cinq cycles compacts manqués et un dépassement de délai sur le cycle forceCompact, programmez la fenêtre de maintenance à un moment calme lorsque la quantité d'écritures du référentiel est faible. Vous pouvez vérifier les écritures du référentiel dans l’outil de surveillance des mesures du référentiel situé à l’adresse https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.html.
    • Si le nettoyage est arrêté à la fin de la fenêtre de maintenance, assurez-vous que la configuration de la fenêtre de maintenance dans l’interface utilisateur des tâches de maintenance est suffisamment volumineuse.
    • Si la mémoire disponible est insuffisante, assurez-vous que l’instance contienne suffisament de mémoire.
    • En cas de délai de réponse, l’entrepôt de segments peut augmenter de façon excessive au point où il devient impossible d’effectuer un nettoyage des révisions en ligne, même avec une fenêtre de maintenance plus longue. Par exemple, si aucun nettoyage des révisions en ligne n’a réussi au cours de la dernière semaine, il est recommandé de planifier une maintenance hors ligne et d’effectuer le nettoyage des révisions hors ligne en vue de convertir la taille de l’entrepôt de segments à une dimension plus gérable.
Que doit-on faire une fois l’alerte de vérification d’intégrité activée ? Voir le point précédent.
Que se passe-t-il lorsque le nettoyage des révisions en ligne est à court de temps pendant la fenêtre maintenance planifiée ? Le nettoyage des révisions en ligne sera annulé et le restant sera supprimé. Il recommencera la prochaine fois que la fenêtre de maintenance est planifiée.
En quoi les instances SegmentNotFoundException sont-elles consignées dans error.log et comment puis-je récupérer ?

Un SegmentNotFoundException est consigné par le TarMK lorsqu'il tente d'accéder à une unité d'enregistrement (un segment) qu'il ne trouve pas. Il existe trois scénarios pouvant causer ce problème :

  1. Une application qui contourne les systèmes d’accès recommandés (comme Sling et l’API JCR) et utilise un niveau API/SPI plus bas pour accéder au référentiel, puis dépasse la période de validité d’un segment. En d’autres termes, il conserve une référence à une entité plus longue que la durée de rétention octroyée par le nettoyage des révisions en ligne (24 heures par défaut). Ce cas est transitoire et ne conduit pas à la corruption des données. Pour récupérer, l'outil d'exécution de chêne doit être utilisé pour confirmer la nature transitoire de l'exception (la vérification d'exécution de chêne ne doit pas signaler d'erreurs). Pour ce faire, l’instance doit être mise hors ligne et redémarrée ensuite.
  2. Un événement externe a causé la corruption des données sur le disque. Il peut s’agir d’une panne du disque, d’un espace disque saturé ou d’une modification accidentelle des fichiers de données requis. Dans ce cas, une instance doit être déconnectée et réparée avec la vérification exécutée par Oak. Pour plus d'informations sur la façon d'effectuer la vérification de l'exécution du chêne, consultez la documentation Apache suivante.
  3. Toutes les autres occurrences doivent être traitées par le service à la clientèle Adobe.

Dépannage basé sur les messages d’erreur

Le fichier error.log sera détaillé en cas d'incident au cours du processus de nettoyage des révisions en ligne. La matrice suivante vise à expliquer les messages les plus courants et à fournir des solutions possibles :

Phase Messages du journal Explication Étapes suivantes
Estimation TarMK GC #2 : estimation ignorée car la compaction est suspendue La phase d'estimation est ignorée lorsque la compaction est désactivée sur le système par configuration. Activation du nettoyage des révisions en ligne.
TarMK GC #2 : estimation interrompue : ${REASON}. Skipping compaction. La phase d'estimation s'est terminée prématurément. Quelques exemples d’événements qui peuvent interrompre la phase d’estimation : pas suffisamment de mémoire ou d’espace disque sur le système hôte. Dépend de la raison donnée.
Compaction TarMK GC #2 : compaction suspendue Tant que la phase de compaction est interrompue par la configuration, ni la phase d'estimation ni la phase de compaction ne seront exécutées. Activez le nettoyage des révisions en ligne.
TarMK GC #2 : compaction annulée : ${REASON}. La phase de compaction s'est terminée prématurément. Quelques exemples d’événements qui peuvent interrompre la phase de compression : pas suffisamment de mémoire ou d’espace disque sur le système hôte. De plus, la compression peut être annulée en désactivant le système ou en l’annulant de façon explicite par le biais des interfaces d’administration telles que la fenêtre de maintenance dans le tableau des opérations. Dépend de la raison donnée.
TarMK GC #2 : échec de compaction en 32,902 min (1974140 ms), après 5 cycles Ce message ne signifie pas qu’il y a eu une erreur irrécupérable, mais seulement que la compaction a été arrêtée après un certain nombre de tentatives. Lisez également le paragraphe suivant. Lisez la documentation sur les chênes suivante et la dernière question de la section Exécution du nettoyage de révision en ligne.
Nettoyage TarMK GC #2 : nettoyage interrompu Le nettoyage a été annulé en arrêtant le référentiel. Aucun impact sur la cohérence n’est attendu. En outre, l’espace disque ne sera probablement pas pleinement récupéré. Il sera récupéré lors du prochain cycle de nettoyage des révisions. Découvrir pourquoi le référentiel a été arrêté et essayer d’éviter de le désactiver pendant les fenêtres de maintenance.

Exécution du nettoyage des révisions hors ligne

ATTENTION

Les différentes versions de l’outil exécuté par Oak doivent être utilisées en fonction de la version d’Oak que vous utilisez avec votre installation AEM. Vérifiez les exigences de version énumérés ci-dessous avant d’utiliser l’outil :

  • Pour les versions Oak 1.0.0 à 1.0.11 ou 1.1.0 à 1.1.6, utilisez la version Oak 1.0.11

  • Pour des versions d’Oak plus récentes que celle ci-dessus, utilisez la version d’Oak-run qui correspond au système Oak de votre installation AEM.

Adobe fournit un outil appelé Oak-run pour effectuer le nettoyage de la révision. Il peut être téléchargé à l’emplacement suivant :

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

L’outil est un jar exécutable qui peut être exécuté manuellement pour compresser le référentiel. Le processus est appelé nettoyage des révisions hors ligne, car le référentiel doit être desactivé pour pouvoir exécuter correctement l’outil. Veillez à planifier le nettoyage en fonction de la période de maintenance.

Pour obtenir des conseils sur la façon d’améliorer les performances du processus de nettoyage, voir Augmentation des performances du nettoyage de la révision hors ligne.

REMARQUE

Vous pouvez également effacer les anciens points de contrôle avant que la maintenance ait lieu (étapes 2 et 3 de la procédure ci-dessous). Cette méthode s’adresse uniquement aux instances comportant plus de 100 points de contrôle.

  1. Vérifiez systématiquement que vous disposez d’une sauvegarde récente de l’instance AEM.

    Arrêtez AEM.

  2. (Facultatif) Utilisez l’outil pour trouver des anciens points de contrôle :

    java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore
    
  3. (Facultatif) Ensuite, supprimez les points de contrôle non-référencés :

    java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore rm-unreferenced
    
  4. Exécutez la compression et attendez qu’elle soit terminée :

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

Amélioration de la performance du nettoyage des révisions hors ligne

L’outil oak-run présente plusieurs fonctionnalités ayant pour but d’améliorer les performances du processus de nettoyage des révisions et de réduire la fenêtre de maintenance autant que possible.

La liste comprend plusieurs paramètres de ligne de commande, comme décrit ci-dessous :

  • -mmap. Vous pouvez définir cette variable sur true ou false. S’il est défini sur true, l’accès mappé par la mémoire est utilisé. S’il est défini sur false, l’accès aux fichiers est utilisé. S’il n’est pas spécifié, l’accès mappé par la mémoire est utilisé sur les systèmes 64 bits et l’accès aux fichiers est utilisé sur les systèmes 32 bits. Sous Windows, l’accès standard aux fichiers est toujours appliqué et cette option est ignorée. Ce paramètre a remplacé le paramètre -Dtar.memoryMapped.

  • -Dupdate.limit. Définit le seuil de vidage d’une transaction temporaire sur le disque. La valeur par défaut est 10000.

  • -Dcompress-interval. Nombre de saisies du plan de compression à conserver jusqu’à la compression du plan actuel. La valeur par défaut est de 1000000. Vous devez augmenter cette valeur à un nombre plus élevé pour un débit plus rapide, si vous disposez de suffisamment de mémoire. Ce paramètre a été supprimé dans Oak version 1.6 et est sans effet.

  • -Dcompaction-progress-log. Le nombre de nœuds compressés qui seront inscrits dans le journal. La valeur par défaut est 150000, ce qui signifie que les 150000 premiers noeuds compactés seront enregistrés pendant l’opération. Utilisez ce paramètre conjointement avec le paramètre suivant répertoriées ci-dessous.

  • -Dtar.PersistCompactionMap. Définissez ce paramètre sur true pour utiliser l’espace disque au lieu de la mémoire de tas pour la persistance de la carte de compaction. Nécessite l'outil d'exécution en chêne versions 1.4 et ultérieures. Pour plus de détails, reportez-vous à la question 3 dans la section FAQ sur le nettoyage des révisions hors ligne. Ce paramètre a été supprimé dans Oak version 1.6 et est sans effet.

  • –force. Force la compression et ignore une version d’entrepôt de segments sans correspondance.

ATTENTION

L’utilisation du paramètre --force permet de mettre à niveau le magasin de segments vers la dernière version, ce qui est incompatible avec les anciennes versions d’Oak. Veuillez également tenir compte du fait qu’il est impossible de revenir à la version antérieure. En règle générale, l’utilisation de ces paramètres doit être réservée aux utilisateurs qui disposent des connaissances appropriées.

Un exemple de paramètre utilisé :

java -Dupdate.limit=10000 -Dcompaction-progress-log=150000 -Dlogback.configurationFile=logback.xml -Xmx8g -jar oak-run-*.jar checkpoints <repository>

Autres méthodes pour déclencher le nettoyage des révisions

Outre celles présentées ci-dessus, vous pouvez également déclencher le mécanisme de nettoyage des révisions à l’aide de la console JMX, comme suit :

  1. Ouvrez la console JMX en accédant à http://localhost:4502/system/console/jmx.
  2. Cliquez sur RevisionGarbageCollection MBean.
  3. Dans la fenêtre suivante, cliquez sur startRevisionGC(), puis sur Invoke pour début de la tâche Revision Garbage Collection.

FAQ sur le nettoyage des révisions hors ligne

Quels sont les facteurs qui déterminent la durée du nettoyage des révisions hors ligne ?

La taille du référentiel et la quantité de révisions devant être nettoyées déterminent la durée du nettoyage.

Quelle différence y a-t-il entre une révision et une version de page ?
  • Révision en chêne : Oak organise tout le contenu dans une grande arborescence composée de noeuds et de propriétés. Chaque aperçu ou révision de cet ensemble de contenus inaltérables, ainsi que les modifications de l’arborescence sont indiqués sous forme de séquence de nouvelles révisions. En règle générale, chaque modification de contenu déclenche une nouvelle révision. Voir aussi Suivre le lien.
  • Version de la page : le contrôle de version crée un "instantané" d’une page à un moment donné. En règle générale, une nouvelle version est créée lorsqu’une page est activée. Pour plus d’informations, voir Utilisation des versions de page.
Comment accélérer la tâche de nettoyage des révisions hors ligne si elle n’est pas terminée au bout de 8 heures ? Si la tâche de révision n'est pas terminée dans les 8 heures et que le thread dumps révèle que la zone réactive principale est InMemoryCompactionMap.findEntry, utilisez le paramètre suivant avec l'outil d'exécution de chêne versions 1.4 ou ultérieures : -Dtar.PersistCompactionMap=true. Notez que le paramètre -Dtar.PersistCompactionMap a été supprimé dans Oak version 1.6.

Sur cette page

Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now