Analyse de l’image mémoire des threads AEM

Suivez les étapes et bonnes pratiques présentées dans cet article pour analyser correctement AEM vidages de threads Java à l’aide de la variable IBM Thread Analyzer outil.

Description description

Environnement

Adobe Experience Manager

Problème

Comment analyser AEM vidages de threads Java à l’aide du IBM Thread Analyzer outil ?

Résolution resolution

  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 de pile avec les piles les plus longues sur le dessus.

  6. 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.

  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 révision de la variable Runable threads, vous pouvez ignorer les threads répertoriés dans la variable  Threads qui peut être ignorée  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 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.

  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 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 nombre 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.

  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ées attendent que le thread sélectionné libère un moniteur.

    Si vous ne voyez pas de threads en attente, le thread sélectionné peut toujours être propriétaire d’un Verrouiller (voir implémentation des classes de Verrouiller 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 cadenas.

  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 en cours d’exécution.

    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 ouvre une fenêtre qui affiche une arborescence du moniteur propriétaire des threads et de leurs threads d’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 thread de pool de threads inactif 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 rencontrez un problème de mémoire.

  3. Si vous avez confirmé le problème de mémoire, capturez un vidage de tas 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 peut être ignorée:

  • 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.
recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f