Analyse de l’image mémoire des threads AEM

Description

Environnement
Adobe Experience Manager

Problème
Analyser AEM vidages de threads Java à l’aide de IBM Thread Analyzer et bonnes pratiques.

Résolution

Solution

Suivez ces étapes et bonnes pratiques pour analyser AEM vidages de threads Java à l’aide de IBM Thread Analyzer outil:

1. Télécharger et installer IBM Thread Analyzer (nous l’appellerons IBM TDA pour abréger).

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

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

4. 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 bouton .

   

5. Tri par Profondeur d’empilement avec les piles les plus longues sur le dessus.

   

6. Examinez les threads avec une profondeur de pile de 10 lignes ou plus.  Il s’agit généralement des threads les plus intéressants.

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

7. Tri par thread État.

8. Faites défiler l’écran vers le bas jusqu’à Runable threads. 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 : Lors de la vérification de la variable Runable threads, vous pouvez ignorer les threads répertoriés dans la variable Threads qui peuvent être ignorés au bas de cette page.

9. 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 comme celui-ci : 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.

10. 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 la date et l’heure 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 nombre epoch en date/heure à l’aide de www.epochconverter.com.

    Chaque image mémoire de thread affiche la date et l’heure auxquelles elle a été capturée.

    Vous pouvez calculer la durée entre l’heure de la requête et l’heure de l’image mémoire du thread pour voir depuis combien de temps une requête est active.

11. Après avoir examiné les threads de requête, faites défiler l’autre Runable threads.

    Une fois que vous avez trouvé un fil d’intérêt Runnable, puis regardez le panneau central, Attente des threads.

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

    Si vous ne voyez pas de threads en attente, votre thread sélectionné peut quand même être propriétaire d’un Verrou (voir la mise en œuvre des classes de Verrou pour plus de détails).

    Par exemple, avec un ReparticipantReadWriteLock vous ne pouvez pas déterminer quel thread est le porte-verrou, 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 support du verrou.

12. 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 vidages (dans IBM TDA, vous pouvez sélectionner plusieurs vidages de thread et cliquer sur le bouton Comparaison de threads pour afficher l’état d’un thread dans plusieurs images mémoire de threads.

    

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

    

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

    En fait, si le thread est dans la variable Runable se trouve dans plusieurs vidages et possède une longue pile, ce qui signifie généralement qu’il s’agit d’un thread à long terme.

15. Si vous n'avez pas trouvé grand-chose à voir la Runable threads, puis revenez à la liste des threads, sélectionnez un thread dump, puis cliquez sur Détails de l’écran sur le panneau supérieur.

IBM TDA ouvrira une fenêtre qui affiche une arborescence du moniteur propriétaire des threads et de leurs threads en attente.

Remarque : Il peut afficher certains threads du pool de threads, comme le moniteur du pool de threads du moteur de servlet, les threads inactifs peuvent être ignorés.

Vous pouvez généralement dire qu’un thread est un pool de threads inactifs, car la plupart du temps, il n’a que 10 lignes de pile ou moins.

Utilisation de l’unité centrale au niveau du thread (plateforme Linux uniquement):

1. Si vous avez capturé top -H -b -n1 -p javapid Outre les 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 à la variable nid de l’un des threads.

2. Si le thread correspondant utilisant le plus de processeur est le Thread VM ou GC alors vous pouvez rencontrer 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 avez un problème de mémoire.

3. Si vous avez confirmé le problème de mémoire, capturez une image mémoire la prochaine fois que le problème se produira.

   Voir Analyse des problèmes de mémoire pour plus d’informations sur la capture et l’analyse des vidages de tas.

Threads qui peuvent être ignorés:

• Thread VM : il s’agit d’un thread du système VM.
• Threads commençant par le thread de tâche GC : il s’agit des threads de récupération de l’espace mémoire.
• Threads dont les noms sont similaires à - 1347028691218 in code at java.net.PlainSocketImpl.socketAccept(Native Method): Il s’agit de threads provenant du pool de threads du moteur de servlet en attente de nouvelles connexions.

Ressources Business.Adobe.com