Analyse des processus lents et bloqués

FAQ

Quelles sont les situations courantes provoquant une consommation élevée du processeur ?

Certaines activités de maintenance peuvent être à l'origine d'une sollicitation intensive du processeur : reproduction de tar, nettoyage de mémoire tampon, sauvegarde en ligne, activation en ligne, activation du déploiement d'une mise à jour de l'application provoquant le vidage des caches, etc.

Quelle serait la raison d’une consommation nulle du processeur  ?

Un blocage de niveau java peut provoquer une telle situation. Dans ce cas, collectez quelques images mémoire de threads, soumettez un ticket au service de support et redémarrez l’AEM.

Existe-t-il des conseils d'optimisation des performances ?

Oui. Pour y accéder, visitez la page https://helpx.adobe.com/fr/experience-manager/kb/performance-tuning-tips.html

Voir aussi la session gem : http://dev.day.com/content/ddc/en/gems/dispatcher-caching---new-features-and-optimizations.html

Solutions

Vidéo gem - Présentation technique

La session vidéo gem est disponible à l'adresse http://dev.day.com/content/ddc/en/gems/cq-aem-5-6-troubleshooting.html

Adobe Experience Manager 5.6 ou version plus récente et CRX 2.3 ou version plus récente

Utilisez http://localhost:4502/system/console/profiler pendant au moins quelques minutes pendant le ralentissement ou l'utilisation intensive du processeur. Le résultat du fichier journal permet de déterminer les tâches JVM qui consomment le plus de cycles du processeur, ainsi que leurs contenus et les classes associées.

Version CRX 2.2  et antérieures

Utilisez l’outil de profilage simple de processeur, inclus dans CRX 2.0.x. Pour commencer, ouvrez

http://localhost:7402/crx/diagnostic/prof.jsp

CRX 1.x

Pour vous aider à analyser le problème, créez quelques vidages complets de tâches. Ces vidages de tâches peuvent ensuite être analysés. Création de vidages complets de tâches.

Obtention de l’ID du processus

Pour obtenir l’ID de votre processus Java, utilisez

jps- l

Si cela ne fonctionne pas (chemin d’accès non défini, JDK non installé ou ancienne version de Java), utilisez

ps -el | grep java

Vidages de Fil complet

Pour analyser un problème de performance ou un processus bloqué, créez environ dix full thread dumps avec un retard d'environ une seconde. Si le problème peut être dû au regroupement, créez au moins dix filetages complets sur chaque nœud de clusters Dans la mesure du possible, créez les filetages à la même heure (même si ce n’est pas l'heure réelle).

Un vidage complet des filetages commence par des informations telles que  :

2015-07-22 10:26:30
Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.65-b04):

"Thread-76273" daemon prio=3 tid=0x111061 nid=0x111061 running [0x111061]
... stack and locked object MUST be present

Si votre thread dump ne ressemble pas à celui-ci, il ne sera pas possible d'effectuer les recherches appropriées.

Vous pouvez utiliser l'« outil » fourni sur le partage de module comme indiqué sur la page. Il fournit un outil de vidage de threads qui permet de réaliser de multiples vidages de threads, au format présenté plus haut.

Si jstack est installé, vous pouvez aussi l’utiliser. La commande suivante renvoie les vidages de thread dans le système :

jstack <pid>

Cette commande ajoute un vidage de threads complet dans un fichier :

jstack <pid> >> threadDumpNode1.txt

Sur certains systèmes, l’utilisation de : sudo -u aem jstack -J-d64 -l <pid>peut s'avérer nécessaire.

Si cela ne fonctionne pas, utilisez kill -QUIT. La commande suivante renvoie le vidage de threads dans le fichier journal :

kill -QUIT <pid>

S'il n'y a aucun thread dumps dans la sortie standard de la dernière commande, ajoutez-le aux paramètres Java :

-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=jvm.log

Remarque : Si les étapes ci-dessus pour l'obtention des thread dumps ne fonctionnent pas dans votre environnement, reportez-vous à l’article suivant.

Vérification de l’utilisation du processeur

Pour analyser le problème, il est important de savoir si CRX /CQ s’exécute dans une boucle infinie ou si elle est en veille. Pour le découvrir, saisissez

top

Cette commande affiche la liste des processus, triés par utilisation du processeur. Si le processus supérieur est un processus Java et si le PID correspond à CRX/CQ, le processus est alors exécuté à la vitesse maximale.

Si vous ne savez pas comment interpréter les résultats, exécutez l’instruction suivante, puis incluez le fichier top.txt dans votre rapport de problèmes :

top -l5 -s5 > top.txt

Vérifiez le nombre de sessions.

Souvent, le problème est que le nombre de sessions ouvertes est trop élevé. Il ralentit le traitement. Pour savoir si c'est le cas, exécutez la commande

jps -l (pour obtenir l'identifiant de processus Java).

jmap -histo <pid> | grep CRXSession (pour obtenir le nombre de sessions ouvertes)

s'il s'agit, en fait, de ce problème (le nombre est supérieur à quelques centaines de sessions), alors il doit être analysé. Il est possible qu’un pool de sessions soit utilisé (en fonction de la version de CRX / CQ il peut s’agir d’un correctif urgent pour le problème donné) ou de sessions de références de cache interne (éventuellement au niveau de l'application). Pour analyser l'endroit où ces sessions sont ouvertes, reportez-vous à la page « Analyse des sessions ouvertes ».

Ne tuez pas le processus

Le processus CRX ne doit jamais être tué, même lorsque l’arrêt dure trop longtemps. Si vous devez tuer un processus qui ne répond pas, créez d’abord un vidage complet des threads et enregistrez l’erreur.

Si vous éliminez le processus CRX, la prochaine fois que vous le lancez, il se peut que le gestionnaire tar PM crée des fichiers de backup_.tar.

Outils d'assistance

Utilisez l'outil de collecte et d'analyse de vidage de threads pour prendre des vidages de thread d'une instance d'exécution CQ et résoudre les problèmes liés :
- aux performances ;

- aux conflits de verrouillage ;

- aux blocages ;

- aux autres problèmes de thread.