Analyse de l’image mémoire des threads AEM

Téléchargez et installez IBM Thread Analyzer (nous l’appellerons IBM TDA pour abréger).

Capturez les images mémoire des threads d’une instance AEM présentant des problèmes de performances.

Ouvrez les images mémoire de threads dans IBM TDA.

Pour afficher les détails d’un vidage de threads, sélectionnez le fichier dans la liste, puis cliquez sur le bouton Détails du thread .

Triez par Profondeur de pile avec les piles les plus longues au-dessus.

Examinez les threads avec une profondeur de pile de 10 lignes ou plus.  Ce sont généralement les fils d'intérêt.

Prenez des notes sur les threads qui présentent un intérêt.

Tri par thread State.

Faites défiler l’écran jusqu’aux threads Runnable. Les threads exécutables sont ceux qui consommaient activement du temps de processeur lorsque l’image mémoire du thread était exécutée.

Remarque : lorsque vous passez en revue les threads Runnable, vous pouvez ignorer les threads répertoriés dans la section Threads qui peuvent être ignorés au bas de cette page.

Recherchez les threads exécutables qui font partie de l’application, par exemple, les threads de tâche en arrière-plan ou les threads de requête (les threads de requête portent des noms tels que : 127.0.0.1 [ 1347028187737] GET /content/sites/global/en/sitemap.static-delivery.httpd.html HTTP/1.1).

Une fois que vous les avez trouvés, cliquez dessus un par un.

Pour chaque thread de requête, vous pouvez déterminer quand le navigateur de l’utilisateur a envoyé la requête au serveur en observant l’horodatage dans le nom du thread.

Par exemple, dans le nom de thread ci-dessus, l’horodatage (au format d’époque unix en millisecondes) est 1347028187737.

Nous pouvons convertir ce numéro d’époque en date/heure à l’aide de www.epochconverter.com.

Chaque thread dump affiche la date et l’heure de prise.

Vous pouvez prendre la différence de temps entre le temps de requête et le temps de vidage du thread pour voir pendant combien de temps une requête a été active.

Après avoir examiné les threads de requête, faites défiler les autres threads Runnable.

Une fois que vous avez trouvé un fil d’intérêt Runnable, consultez le panneau central, En attente de threads.

Les Threads répertoriées attendent que le thread sélectionné libère un moniteur.

Si vous ne voyez aucun thread en attente, votre thread sélectionné peut toujours être propriétaire d’un Verrouillage (voir classes d’implémentation de Verrouillage pour plus d’informations).

Par exemple, avec un ReparticipantReadWriteLock, vous ne pouvez pas déterminer quel thread est l’espace de verrouillage, car les verrous implémentent plusieurs moniteurs en interne.

Vous devrez peut-être consulter le code source pour le faire correspondre à un thread qui pourrait être le cadenas.

Si le thread avait un verrou ou un moniteur que beaucoup d’autres threads attendaient, passez par le reste des vidages de thread pour voir si vous pouvez trouver d’autres threads ayant le même problème.

Vérifiez si le même thread existe toujours dans les autres images mémoire (dans IBM TDA, vous pouvez sélectionner plusieurs images mémoire de threads et cliquer sur le bouton Comparer Threads pour afficher l’état d’un thread dans plusieurs images mémoire de threads.

Voir le Collector Service dans la capture d’écran ci-dessous :

Dans cette vue, vous pouvez voir le thread dans plusieurs images mémoire de threads pour voir s’il s’agit d’un thread en cours d’exécution.

En gros, si le thread est à l’état Runnable sur plusieurs vidages et a une longue pile, cela signifie généralement qu’il s’agit d’un thread à long terme.

Si vous n’avez pas trouvé grand-chose à voir avec les threads Runnable, revenez à la liste des threads, sélectionnez un vidage de threads, puis cliquez sur le bouton Détails du moniteur sur le panneau supérieur.

Si vous avez capturé la sortie top -H -b -n1 -p <javapid> en plus des images mémoire de threads, vous pouvez effectuer des références croisées avec l’utilisation du processeur au niveau du thread.

Ouvrez la sortie supérieure et obtenez l’ID de processus des threads qui utilisent le processeur.

Convertissez l’ID de processus en hexadécimal, puis recherchez cette valeur hexadécimale dans le fichier de vidage de thread correspondant.

L’identifiant doit correspondre à l’identifiant nid de l’un des threads.

Si le thread correspondant utilisant le plus de processeur est le Thread VM ou n'importe quel thread GC, il se peut qu'il y ait un problème de mémoire.

Répétez le même exercice pour plus d’images mémoire de threads et une sortie supérieure, et s’il existe un modèle de ces threads qui prend du temps au processeur, vous rencontrez un problème de mémoire.

Si vous avez confirmé le problème de mémoire, capturez un vidage de tas la prochaine fois que le problème se produira.

Pour plus d’informations sur la capture et l’analyse des vidages de tas, reportez-vous à cet article Analyser les problèmes de mémoire .