Outil / méthode d'analyse du vidage de fil

Question

Lorsque l'application Java est suspendue, que vous ne connaissez même pas le cas d'utilisation qui conduit à ce problème et que vous voulez enquêter, je comprends que les vidages de threads peuvent être utiles.

Mais comment pouvons-nous facilement dériver des données utiles à partir des vidages de threads pour trouver où se situe le problème ? L'application serveur sur laquelle je travaille produit des vidages de threads très longs, car il s'agit d'une architecture EJB et les vidages de threads contiennent de nombreux threads de conteneurs que je ne suis pas sûr de devoir examiner (c'est-à-dire des threads qui n'exécutent pas le code de mon application, mais celui de JBoss).

Hier, j'ai essayé le Analyseur de vidage de fil outil. L'outil est définitivement meilleur que de regarder les vidages de fils bruts dans un éditeur de texte, parce que vous pouvez filtrer les fils qui ne vous intéressent pas, voir la liste des fils, cliquer sur un fil pour voir ses détails, comparer les vidages de fils pour trouver les longs fils, etc.

Mais il y a encore trop de données à analyser - près de 300 fils. Je ne connais pas de critères que je pourrais utiliser pour filtrer tous les fils de discussion JBoss, qui ne m'intéressent pas. Je ne sais pas si je dois regarder uniquement les threads qui sont actuellement dans l'état "runnable" ou si "waiting on condition" et "in Object.wait" sont également importants.

Quelle est l'approche que vous suivriez normalement et les outils que vous utiliseriez en général ?

Answer 1

Je sais qu'il s'agit d'une vieille question, mais je viens d'écrire un outil pour aider à rendre les longs fils de discussion plus lisibles.

Outil d'analyse du dump des threads Java

Cet outil regroupe les threads qui ont la même trace de pile et vous permet de ne montrer que les threads qui sont dans des états particuliers (par exemple RUNNABLE ou BLOCKED).

Cela permet de trouver un peu plus rapidement les threads intéressants parmi les dizaines ou centaines de threads JBoss qui passent la plupart de leur temps à attendre du travail au même endroit dans le code et qui ont donc tous la même trace de pile.

Answer 2

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

L'astuce consiste à prendre 4 ou 5 ensembles de vidages de threads à un intervalle de 5 secondes entre chacun d'eux. Ainsi, à la fin, vous aurez un seul fichier journal qui contient environ 20 à 25 secondes d'action sur le serveur d'application.

Ce que vous voulez vérifier, c'est que lorsqu'un thread bloqué ou une transaction de longue durée se produit, tous les thread dumps montrent qu'un certain identifiant de thread se trouve à la même ligne dans votre stack trace java. En termes plus simples, la transaction (disons dans un EJB ou une base de données) s'étend sur plusieurs threads dumps et nécessite donc une enquête plus approfondie.

Maintenant, quand vous les passez dans Samurai (Je n'ai pas utilisé TDA moi-même), il les surlignera en rouge afin que vous puissiez rapidement cliquer dessus et accéder aux lignes qui posent problème.

Voir un exemple de ici . Regardez l'image de sortie du Samouraï dans ce lien. Les cellules vertes sont bien. Les cellules rouges et grises doivent être examinées.

Un exemple de Samurai tiré de ma propre application web ci-dessous montre une séquence bloquée pour le fil "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)

mise à jour

J'ai récemment utilisé le Analyseur de vidage de threads Java mentionné dans cette réponse et il a été très utile pour Tomcat par rapport à Samurai

Answer 3

Je ne suis pas sûr que je doive chercher à les threads qui sont actuellement dans actuellement dans l'état "runnable" seulement ou si "waiting on condition" et "in Object.wait" sont des états également importants.

Les deux derniers sont en fait le site les choses à rechercher pour diagnostiquer un blocage, comme vous semblez le faire. "Runnable" signifie que le thread est en train de faire quelque chose en ce moment (ou attend d'obtenir le CPU). "bloqué" et "en attente", voilà de quoi sont faits les blocages.

Bien sûr, un conteneur d'application aura beaucoup de threads en attente légitime. Pour filtrer les cas intéressants, regardez la trace de la pile. S'il s'agit de classes du framework (et en particulier de celles appelées "Worker" ou "Queue"), tout va probablement bien. S'il s'agit de code d'application, vous devez l'examiner de plus près.