Comment surveiller le TarMK | AEM 6.3 | OAK 1.6

* Les informations suivantes s'appliquent pour Oak version 1.6+ et version AEM 6.3+.

Problème :
la mémoire disponible étant limitée (tas et hors tas), les caches sont surchargés lorsque le référentiel d'une instance atteint un certain niveau.
En conséquence, la plupart des accès de référentiel lisent les données directement à partir du disque, ce qui ralentit grandement le processus et entraîne des désagréments pour l'utilisateur final.

Symptômes :
globalement, l'instance ralentit : les délais de réponse augmentent et le nettoyage de la révision en ligne prend beaucoup plus de temps à s'exécuter, dépassant parfois la période de maintenance allouée.
Au niveau du système, on observe une activité IO élevée et constante.

Étapes

Résolution des problèmes

Il existe plusieurs points de terminaison qui sont contrôlés pour déterminer quand le système devient lié à IO. 
Les paragraphes suivants portent sur les points de terminaison disponibles et les indicateurs clés.

Contrôle des points de terminaison

Il existe plusieurs points de terminaison pour surveiller les mesures relatives à IO dans AEM, JVM et le système d'exploitation. 

Ensemble, ils fournissent des perspectives différentes sur le débit global du système aux niveaux différents : des sessions JCR pour valider le TarMK au disque IO du TarMK.

Associés aux informations collectées avec les outils au niveau de JVM et du système d’exploitation, ils fournissent une multitude d’informations sur l’intégrité du système et facilitent la recherche de points d'étranglement.

• Chaque session expose une instance SessionMBean, qui contient des compteurs comme le nombre et le taux de lecture et d'écriture actuellement dans la session.
• La variable RepositoryStatsMBean expose les points de terminaisons pour surveiller le nombre de sessions ouvertes, la vitesse de connexion de la session, la lecture globale et le chargement de lectures au cours de toutes les sessions et de la lecture globale, les minutages d'écriture dans toutes les sessions ainsi que les chargements et minutages totaux pour les requêtes et l'observation.
• Le SegmentNodeStoreStatsMBean expose les points de terminaison pour surveiller les commits : nombre et taux, nombre de validations en attente et temps de mise en file d'attente.
• Le FileStoreStatsMBean expose les points d'extrémité reflétant la quantité de données écrites sur le disque, le nombre de fichiers tar sur le disque et l'encombrement total sur le disque.

Outre ces points de terminaison, il existe de nombreux outils spécifiques à JVM et à un système d’exploitation pour vous aider à mieux comprendre l’activité du système :

• Java Mission Control (jmc) est un outil puissant pour collecter tous les aspects des performances d’une JVM en cours d’exécution. Sa capacité à enregistrer des entrées-sorties par processus Java peut parfois être inestimable.
• Les outils de ligne de commande jstat, jstack et jmap sont utiles pour accéder respectivement au ramasse-miettes de la JVM, aux threads de la JVM et au segment de mémoire de la JVM.
• Les outils de niveau du système d'exploitation vmstat et iostat sont utilisés pour examiner l'utilisation des E / S et du processeur au niveau du système d'exploitation.

Disque de surveillance IO

Quoi : le nombre d'opérations sur disque (lectures / écritures) par unité de temps (seconde)

Comment : outillage au niveau du système d'exploitation (par exemple : vmstat, iostat sous UNIX)

Normal : faible niveau de lecture du disque (proche de zéro) ; constant, faible nombre d'écritures (voir image). Pics pendant le nettoyage de révision.

Avertissement : un niveau élevé et croissant de lecture des disques est un signe de sous-dimensionnement de la mémoire (voir image).

AVERTISSEMENT DE RESPONSABILITÉ : un volume élevé d'E/S de disque est dû à d'autres opérations exécutées sur AEM (par exemple : ingestion d'actifs) ou par un autre processus (par exemple : analyse antivirus), donc assurez-vous d'exclure toute autre cause avant le diagnostic Segment Tar comme coupable. En général, la tendance sur plusieurs jours est plus pertinente que les pics locaux.

Surveillance de l'unité centrale

• Quoi : temps passé par le processeur pour diverses opérations, en particulier l'attente d'IO.
• Comment : Outillage au niveau du système d'exploitation (par exemple : vmstat sous UNIX). Tous les outils ne le signalent pas (par exemple : haut).
• Normal : le processeur est principalement utilisé par l'application au niveau utilisateur et l'attente d'ES est faible.
• Attention : le CPU passe la plupart des cycles à attendre IO, avec une tendance croissante, au détriment de l'application utilisateur.
• CLAUSE DE NON-RESPONSABILITÉ : un pourcentage élevé de CPU en attente d’IO est dû à d’autres opérations exécutées sur AEM (par exemple: ingestion d’actifs) ou par un autre processus (par exemple: analyse de virus), assurez-vous donc d’exclure toute autre cause avant de diagnostiquer le segment Tar comme coupable. En règle générale, la tendance sur plusieurs jours est plus pertinente que les pics locaux.

Surveillance de la file d'attente de validation

• Quoi : la file d'attente de validation est un mécanisme de mise en mémoire tampon utilisé par Segment Tar lorsque le volume entrant des commits est supérieur à la vitesse de traitement.
• Comment : la taille de la file d'attente de validation en temps réel est exposée via le JMX MBean: org.apache.jackrabbit.oak: COMMIT_QUEUE_SIZE (Metrics) (/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3DCOMMIT_QUEUE_SIZE%2Ctype%3DMetrics). Il est accessible via http sur la console système ou en utilisant un client JMX.
• Normal : une file d'attente vide (taille = 0) indique que le système est en bon état et peut traiter tous les commits à la vitesse à laquelle ils entrent. Les pics locaux traités rapidement sont également normaux.
• Attention : file d'attente constante, non nulle, avec une tendance croissante, le tar segment ne peut pas traiter les commits à la vitesse entrante. La file d'attente risque d'être saturée et les nouveaux commits sont rejetés.
• CLAUSE DE NON-RESPONSABILITÉ : une file d'attente élevée temporaire (pic) est due à une opération intensive déclenchée (par exemple: réplication ou déploiement) ou à un trafic élevé. Veillez donc à exclure toute autre cause avant de diagnostiquer Segment Tar comme le coupable. Généralement, la tendance est plus pertinente que les pics locaux.