DocumentationExperience Cloud KCS

Examiner la croissance du journal et les échecs de synchronisation dans AEM TarMK Cold Standby

Dernière mise à jour : 28 octobre 2026

Cet article explique comment gérer la croissance rapide du fichier tarmk-coldstandby.log et les échecs de synchronisation dans les environnements Adobe Experience Manager (AEM) TarMK Cold Standby, généralement causés par une journalisation DEBUG excessive et un traitement récursif profond.

Description description

Environnement

Adobe Experience Manager 6.5 ou AEM 6.5 LTS configuré avec TarMK Cold Standby ; confirmez la version applicable avant d’utiliser ces étapes.

Problème/Symptômes

  • Le tarmk-coldstandby.log de l’instance de secours augmente rapidement.
  • L’espace disque sur l’instance de secours devient faible ou est épuisé.
  • La synchronisation Cold Standby échoue ou arrête la mise à jour.
  • Les journaux contiennent des entrées StackOverflowError répétées pendant la synchronisation.

Cause

Dans le modèle d’échec documenté, la journalisation DEBUG enregistre un volume élevé d’activité de synchronisation des segments. Le même incident incluait des entrées StackOverflowError récurrentes pendant le traitement récursif de référence de segment. Vérifiez le niveau de l’enregistreur et les preuves d’erreur avant d’appliquer un correctif ; ces symptômes ne permettent pas à eux seuls d’établir que chaque échec de synchronisation a la même cause.

Résolution resolution

Suivez les étapes ci-dessous pour résoudre le problème :

  1. Augmentez la taille de la pile de threads JVM sur l’instance de secours en ajustant l’option JVM -Xss sur une valeur plus élevée, telle que 2m. Cela permet d’éviter les StackOverflowError lors d’un traitement récursif profond.
  2. Passez en revue la configuration de journalisation pour les composants Cold Standby et définissez le niveau de journal pour les classes org.apache.jackrabbit.oak.segment.standby.client et associées à INFO pendant les opérations normales.
  3. Activez la journalisation des DEBUG uniquement lorsque un dépannage détaillé est nécessaire, car une journalisation excessive des DEBUG est la principale cause de la croissance des fichiers journaux.
  4. Pour modifier les niveaux de journal, utilisez Console système > Prise en charge du journal Sling et mettez à jour la configuration pour les enregistreurs concernés.
  5. Si les problèmes de synchronisation persistent, recréez l’instance de secours à partir d’une instance principale saine afin d’éliminer toutes les incohérences accumulées.
  6. Surveillez l’utilisation du disque et enregistrez la croissance des fichiers sur les nœuds de secours pour identifier précocement les modèles de croissance anormaux.
  7. Surveillez la synchronisation Cold Standby en examinant les mesures disponibles dans la console web OSGi d’AEM, y compris l’état de la synchronisation de secours et l’heure de la dernière synchronisation réussie.
  8. Vérifiez que la croissance du fichier journal est contrôlée, que la synchronisation Cold Standby s’effectue correctement et qu’aucune autre occurrence de StackOverflowError n’est signalée.
recommendation-more-help
experience-cloud-kcs-help-kbarticles