Outil / méthode d’parsing de vidage de filetage

Lorsque l’application Java est suspendue, vous ne connaissez même pas le cas d’utilisation qui mène à cela et que vous souhaitez étudier, je comprends que les sauvegardes de threads peuvent être utiles.

Mais comment pouvons-nous facilement extraire des données utiles des décharges de threads pour trouver le problème? L’application serveur avec laquelle j’ai travaillé produit de très longs vidages de threads, car il s’agit d’une architecture EJB et que les vidages de threads contiennent de nombreux threads de conteneur que je ne devrais pas examiner (threads qui n’exécutent pas mon code d’application) , mais le code de JBoss).

Hier, j’ai essayé l’outil Thread Dump Analyzer . L’outil est sans aucun doute meilleur que de regarder les vidages de threads bruts dans un éditeur de texte, car vous pouvez filtrer les threads qui ne vous intéressent pas, voir la liste des threads, cliquer sur un thread pour voir ses détails, comparer les vidages de threads longs threads en cours d’exécution, etc. Voir la capture d’écran ci-dessous:

Analyseur de décharge de fil

Mais il y a encore trop de données à parsingr – près de 300 threads. Je ne connais aucun critère que je pourrais utiliser pour filtrer tous les threads JBoss, dans lesquels je ne suis pas intéressé. Je ne suis pas sûr si je devrais regarder les threads qui sont actuellement dans l’état “runnable” seulement ou si “wait on condition” et “in Object.wait” sont également importants.

Quelle est l’approche que vous suivriez normalement et les outils que vous utiliseriez généralement?

Un seul ensemble de vidages de thread ne sera pas très utile pour trouver la cause première.

L’astuce consiste à prendre 4 ou 5 jeux de dumps de threads à un intervalle de 5 secondes entre chaque. à la fin, vous disposerez d’un fichier journal unique qui aura une durée d’action d’environ 20 à 25 secondes sur le serveur d’applications.

Ce que vous voulez vérifier, c’est quand un thread bloqué ou une longue transaction se produit, tous les vidages de threads montreront qu’un certain identifiant de thread se trouve sur la même ligne dans votre trace de stack Java. En termes plus simples, la transaction (par exemple dans un EJB ou une firebase database) couvre plusieurs vidages de threads et nécessite donc plus d’investigations.

Maintenant, lorsque vous les exécutez via Samurai (je n’ai pas utilisé TDA moi-même), il les mettra en évidence en rouge pour que vous puissiez cliquer dessus rapidement et accéder aux lignes montrant les problèmes.

Voir un exemple de ceci ici . Regardez l’image de sortie Samurai dans ce lien. Les cellules vertes vont bien. Les cellules rouges et grises doivent être examinées.

Un exemple de samouraï de ma propre application Web ci-dessous montre une séquence bloquée pour Thread 19 sur une période de 5 à 10 secondes

> Thread dump 2/3 "[ACTIVE] ExecuteThread: '19' for queue: > 'weblogic.kernel.Default > (self-tuning)'" daemon prio=7 > tid=07b06000 nid=108 lwp_id=222813 > waiting for monitor entry > [2aa40000..2aa40b30] > java.lang.Thread.State: BLOCKED (on > object monitor) at > com.bea.p13n.util.lease.JDBCLeaseManager.renewLease(JDBCLeaseManager.java:393) > - waiting to lock <735e9f88> (a com.bea.p13n.util.lease.JDBCLeaseManager) > at > com.bea.p13n.util.lease.Lease$LeaseTimer.timerExpired(Lease.java:229)

…

 > Thread dump 3/3 "[ACTIVE] > ExecuteThread: '19' for queue: > 'weblogic.kernel.Default > (self-tuning)'" daemon prio=7 > tid=07b06000 nid=108 lwp_id=222813 > waiting for monitor entry > [2aa40000..2aa40b30] > java.lang.Thread.State: BLOCKED (on > object monitor) at > com.bea.p13n.util.lease.JDBCLeaseManager.renewLease(JDBCLeaseManager.java:393) > - waiting to lock <735e9f88> (a com.bea.p13n.util.lease.JDBCLeaseManager) > at > com.bea.p13n.util.lease.Lease$LeaseTimer.timerExpired(Lease.java:229)

mettre à jour

J’ai récemment utilisé l’ parsingur de threads Java Thread Dump Analyzer mentionné dans cette réponse et il a été très utile pour Tomcat, par opposition à Samurai.

Je sais que c’est une vieille question, mais je viens d’écrire un outil pour aider à rendre les vidages de fils longs plus lisibles.

Outil d’parsing Java Thread Dump

Cet outil regroupe les threads qui ont la même trace de stack et vous permet d’afficher uniquement les threads qui sont dans des états particuliers (par exemple, RUNNABLE ou BLOCKED).

Cela rend un peu plus rapide la recherche des threads intéressants parmi les dizaines ou les centaines de threads JBoss qui passent le plus clair de leur temps à attendre le travail au même endroit dans le code et ont donc tous la même trace de stack.

Je ne suis pas sûr si je devrais regarder les threads qui sont actuellement dans l’état “runnable” seulement ou si “wait on condition” et “in Object.wait” sont également importants.

Les deux derniers sont en fait les choses à rechercher lors du diagnostic d’une impasse, comme vous semblez le faire. “Runnable” signifie que le thread fait quelque chose en ce moment (ou attend pour obtenir le CPU). “bloqué” et “en attente” est ce que sont les impasses.

Bien entendu, un conteneur d’applications aura beaucoup de threads en attente. Pour filtrer les cas intéressants, regardez la trace de la stack. Si ce sont des classes de framework (et en particulier celles appelées “Worker” ou “Queue”), c’est probablement correct. Si c’est le code de l’application, vous devriez le regarder de plus près.