Dans quels cas le thread dump est utile ?
Le thread dump est un instantané de l'activité des threads de la JVM. Leur analyse est intéressante dans les cas où l'activité de la JVM ne semble pas normale :
Nous nous limitons ici à la machine virtuel IBM sous AIX. Dans ce cas là il est extrêmement simple de déclencher la création d'un thread dump : il suffit de faire un kill -3 sur le processus Java.
Un fichier dont le nom est javacore.[date].[numero_processus].[compteur].txt est produit. Sur la sortie standard du processus vous devriez voir la ligne suivante s'afficher :
JVMDUMP010I Java Dump written to .....
En général le dump est produit dans le répertoire de travail du processus Java. Sous Oracle Weblogic il s'agit du répertoire du domaine : /..../domain/javacore...ou sous Tomcat il s'agit du répertoire bin
Attention : la production d'un tread dump est une opération couteuse qui fige l'activité de la machine virtuelle pendant un certain temps. Elle ralentie donc l'activité de cette dernière.
Comment lire le thread dump ?
Un thread dump est un fichier texte, vous pouvez l'ouvrir avec n'importe quel éditeur de texte. Mais à la longue, si vous devez en analyser plusieurs et que vous travaillez sur un serveur d'application qui fait tourner plusieurs centaines de threads en parallèle cela devient vite fastidieux.
Heureusement un monsieur chez IBM, Jinwoo Hwang, a réalisé un excellent logiciel pour l'analyse des thread dumps : IBM Thread and Monitor Dump Analyzer for Java. Cerise sur le gâteau on peut le télécharger librement sur le site d'IBM (à condition de s'inscrire) : http://www.alphaworks.ibm.com/tech/jca/download
Exemple sur un "Bottleneck"
Le code suivant va simuler un traitement long avec verrou d'un moniteur afin de simuler un goulot d'étranglement :
@WebServlet("/wait")
public class WaitServlet extends HttpServlet {
private static Object lock = new Object();
protected void doGet(
HttpServletRequest request,
HttpServletResponse response
) throws ServletException, IOException {
response.getWriter().println("We need the lock");
synchronized (lock) {
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
response.getWriter().println("OK");
}
}
Cette servlet va être embarquée dans un Tomcat 7 et nous allons utiliser une JVM IBM 1.6.0 SR9FP1
N.B. Sur les versions antérieur à la SR9 un blocage de la JVM peut se produire lors de la demande du thread dump. On se retrouve alors avec un thread dump incomplet et une JVM complètement bloquée. Plus de détail sur http://www-01.ibm.com/support/docview.wss?uid=swg1IZ84925
Analyse du thread dump de l'exemple
Une fois l'utilitaire démarré charger le thread dump :
J'ai démarré 10 clients en simultané avec JMeter.
Ce thread dump montre qu'un thread (celui qui s'appelle "http-bio-8080"-exec-7) possède le verrou sur notre objet partagé décrit dans la section Monitor : Owns Monitor Lock on java/lang/Object@0xB0A65A60
On peut aussi voir précisément qu'elle partie du code possède le verrou, pas de surprise ici il s'agit bien de la méthode doGet de la servlet.
A gauche, sous le thread qui possède le verrou, on peut voir la liste des 9 autres threads (et donc client HTTP) en attente. Si vous cliquez sur l'un de ces threads vous verrez où ces derniers sont en attentes et sur quel objet :
En vous souhaitant une bonne analyse de vos threads sous IBM AIX.
Le thread dump est un instantané de l'activité des threads de la JVM. Leur analyse est intéressante dans les cas où l'activité de la JVM ne semble pas normale :
- Activité suspendue (deadlock/interblocage) ou partiellement suspendue (starvation/famine)
- Activité existante mais le "débit" est en deçà de ce qui est attendu (Goulot d'étranglement / Bottleneck)
- Activité existante mais le "débit" reste nul (Boucle infinie / Infinite Loop)
Nous nous limitons ici à la machine virtuel IBM sous AIX. Dans ce cas là il est extrêmement simple de déclencher la création d'un thread dump : il suffit de faire un kill -3 sur le processus Java.
Un fichier dont le nom est javacore.[date].[numero_processus].[compteur].txt est produit. Sur la sortie standard du processus vous devriez voir la ligne suivante s'afficher :
JVMDUMP010I Java Dump written to .....
En général le dump est produit dans le répertoire de travail du processus Java. Sous Oracle Weblogic il s'agit du répertoire du domaine : /..../domain/javacore...ou sous Tomcat il s'agit du répertoire bin
Attention : la production d'un tread dump est une opération couteuse qui fige l'activité de la machine virtuelle pendant un certain temps. Elle ralentie donc l'activité de cette dernière.
Comment lire le thread dump ?
Un thread dump est un fichier texte, vous pouvez l'ouvrir avec n'importe quel éditeur de texte. Mais à la longue, si vous devez en analyser plusieurs et que vous travaillez sur un serveur d'application qui fait tourner plusieurs centaines de threads en parallèle cela devient vite fastidieux.
Heureusement un monsieur chez IBM, Jinwoo Hwang, a réalisé un excellent logiciel pour l'analyse des thread dumps : IBM Thread and Monitor Dump Analyzer for Java. Cerise sur le gâteau on peut le télécharger librement sur le site d'IBM (à condition de s'inscrire) : http://www.alphaworks.ibm.com/tech/jca/download
Exemple sur un "Bottleneck"
Le code suivant va simuler un traitement long avec verrou d'un moniteur afin de simuler un goulot d'étranglement :
@WebServlet("/wait")
public class WaitServlet extends HttpServlet {
private static Object lock = new Object();
protected void doGet(
HttpServletRequest request,
HttpServletResponse response
) throws ServletException, IOException {
response.getWriter().println("We need the lock");
synchronized (lock) {
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
response.getWriter().println("OK");
}
}
Cette servlet va être embarquée dans un Tomcat 7 et nous allons utiliser une JVM IBM 1.6.0 SR9FP1
N.B. Sur les versions antérieur à la SR9 un blocage de la JVM peut se produire lors de la demande du thread dump. On se retrouve alors avec un thread dump incomplet et une JVM complètement bloquée. Plus de détail sur http://www-01.ibm.com/support/docview.wss?uid=swg1IZ84925
Analyse du thread dump de l'exemple
Une fois l'utilitaire démarré charger le thread dump :
- File -> Open Thread Dumps : sélectionner le fichier qui commence par javacore.
- Cliquez sur le thread dump qui apparait alors dans la liste
- Analysis -> Monitor Detail
Exemple d'analyse d'analyse des moniteurs d'un thread dump IBM |
Ce thread dump montre qu'un thread (celui qui s'appelle "http-bio-8080"-exec-7) possède le verrou sur notre objet partagé décrit dans la section Monitor : Owns Monitor Lock on java/lang/Object@0xB0A65A60
On peut aussi voir précisément qu'elle partie du code possède le verrou, pas de surprise ici il s'agit bien de la méthode doGet de la servlet.
A gauche, sous le thread qui possède le verrou, on peut voir la liste des 9 autres threads (et donc client HTTP) en attente. Si vous cliquez sur l'un de ces threads vous verrez où ces derniers sont en attentes et sur quel objet :
Détail d'un thread en attente |
En vous souhaitant une bonne analyse de vos threads sous IBM AIX.
Comments
Post a Comment