Outil / méthode d'analyse de vidage de thread
Lorsque l'application Java est bloquée, vous ne connaissez même pas le cas d'utilisation qui y mène et que vous souhaitez enquêter, je comprends que les vidages de threads peuvent être utiles.
Mais comment pouvons-nous facilement dériver des données utiles des vidages de threads pour trouver où est le problème? L'application serveur avec laquelle j'ai travaillé 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 conteneur que je ne suis pas sûr de devoir regarder (c'est-à-dire les 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 nettement 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 pour trouver longs threads, etc. Voir la capture d'écran ci-dessous:
Mais il y a encore trop de données à analyser - près de 300 threads. Je ne connais aucun critère que je pourrais utiliser pour filtrer tous les threads JBoss, qui ne m'intéressent pas. Je ne sais pas si je devrais regarder uniquement les threads qui sont actuellement dans l'état "exécutable" ou si "en attente de condition" et "dans 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 threads ne sera pas trop 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. donc à la fin, vous aurez un seul fichier journal qui a environ 20 à 25 secondes d'action sur le serveur d'application.
Ce que vous voulez vérifier, c'est quand un thread bloqué ou une transaction longue se produit, tous les vidages de threads montreront qu'un certain id de thread est sur la même ligne dans votre Java. En termes plus simples, la transaction (par exemple dans un EJB ou une base de données) s'étend sur plusieurs vidages de threads et nécessite donc plus d'investigations.
Maintenant, lorsque vous les exécutez Samurai (je n'ai pas utilisé TDA moi-même), il les mettra en surbrillance en rouge afin que vous puissiez rapidement cliquer dessus et accéder aux lignes indiquant les problèmes.
Voir un exemple de ceci ici . Regardez l'image de sortie du samouraï 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)
mise à jour
J'ai récemment utilisé le 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'analyse de vidage de thread Java
Cet outil regroupe les threads qui ont la même trace de pile et vous permet d'afficher uniquement 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 ont donc tous la même trace de pile.
Je ne sais pas si je devrais regarder uniquement les threads qui sont actuellement dans l'état "exécutable" ou si "en attente de condition" et "dans Object.wait" sont également importants.
Les deux derniers sont en fait les choses à rechercher lors du diagnostic d'un blocage, comme vous semblez le faire. "Runnable" signifie que le thread fait quelque chose en ce moment (ou attend d'obtenir le CPU). "bloqué" et "en attente" est ce dont sont faits les blocages.
Bien sûr, un conteneur d'application aura de nombreux threads en attente légitime. Pour filtrer les cas intéressants, regardez la trace de la pile. Si ce sont des classes de framework (et en particulier celles appelées "Worker" ou "Queue") c'est probablement OK. S'il s'agit d'un code d'application, vous devriez le regarder de plus près.