Thread Dump Analysis Tool/Metodo

Question

Quando l'applicazione Java è bloccata, non si conosce nemmeno il caso d'uso che sta conducendo a questo e si vuole indagare, capisco che i dump dei thread possono essere utili.

Ma come possiamo facilmente ricavare dati utili dai dump di thread per trovare dove si trova il problema? L'applicazione server con cui lavoro ha generato dump di thread molto lunghi, poiché si tratta di un'architettura EJB e i dump dei thread contengono molti thread contenitore che non sono sicuro di dover esaminare (ovvero i thread che non eseguono il codice dell'applicazione , ma il codice di JBoss).

Ieri ho provato lo strumento Thread Dump Analyzer. Lo strumento è decisamente migliore rispetto ai dump di thread non elaborati in un editor di testo, perché puoi filtrare i thread che non ti interessano, vedere l'elenco dei thread, fare clic su un thread per visualizzarne i dettagli, confrontare i dump di thread per trovare lungo thread in esecuzione, ecc veda la figura sottostante:

ma c'è ancora troppi dati da analizzare - quasi 300 discussioni. Non conosco alcun criterio che possa essere utilizzato per filtrare tutti i thread di JBoss, in cui non sono interessato. Non sono sicuro se dovrei guardare i thread che sono attualmente in stato "runnable" o se "waiting on condition" e "in Object.wait" sono anche importanti.

Qual è l'approccio che normalmente seguiresti e gli strumenti che utilizzeresti in generale?

Answer 1

Un set di dump di thread da solo non sarà troppo utile per ottenere la causa principale.

Il trucco consiste nel prendere 4 o 5 serie di dump di thread con un intervallo di 5 secondi tra ciascuna. così alla fine avremo un singolo file di registro che ha circa 20-25 secondi di azione sul server delle app.

Quello che si desidera verificare è quando si verifica un thread bloccato o una transazione in esecuzione prolungata, tutti i dump del thread mostreranno che un determinato ID thread si trova sulla stessa riga nella traccia java stack. In termini più semplici, la transazione (ad esempio in un EJB o database) si estende su più discariche di thread e quindi necessita di ulteriori indagini.

Ora quando si eseguono queste operazioni tramite Samurai (non ho utilizzato TDA personalmente), queste verranno evidenziate in Colore rosso in modo da poter fare rapidamente clic su di esso e raggiungere le linee che mostrano problemi.

Vedere un esempio di this here. Guarda l'immagine di output di Samurai in quel collegamento. Le celle verdi vanno bene.Le cellule rosse e grigie hanno bisogno di guardare.

un samurai esempio dalla mia web app che segue mostra una sequenza bloccato per Thread'19' attraverso un arco di 5 - 10 secondi

>  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) 

aggiornamento

Recentemente ho utilizzato il Java Thread Dump Analyzer menzionato in this answer ed è stato molto utile per Tomcat in contrapposizione a Sa murai

Answer 2

Io non sono sicuro se devo essere guardando le discussioni che sono attualmente in stato di "eseguibile" solo o se "in attesa a condizione" e "in Object.wait" sono anche importante.

Questi ultimi due sono in realtà le cose da cercare quando la diagnosi di una situazione di stallo, come ti sembra di fare. "Runnable" significa che il thread sta facendo qualcosa in questo momento (o in attesa di ottenere la CPU). "bloccato" e "in attesa" è ciò di cui sono fatti i deadlock.

Ovviamente, un contenitore di applicazioni avrà un sacco di thread in attesa legittima. Per filtrare i casi interessanti, guarda la traccia dello stack. Se si tratta di classi di framework (e specialmente di quelle chiamate "Worker" o "Queue") probabilmente è OK. Se è il codice dell'applicazione, dovresti esaminarlo più da vicino.

Answer 3

So che questa è una vecchia domanda, ma ho appena scritto uno strumento per contribuire a rendere più leggibili i dump di thread lunghi.

Java Thread Dump Analysis Tool

Questo strumento raggruppa fili insieme che hanno lo stesso stack e consente di soli fili mostra che sono in particolari stati (ad esempio eseguibili o bloccato).

Questo rende un po 'più veloce trovare i thread interessanti tra decine o centinaia di thread JBoss che trascorrono la maggior parte del loro tempo in attesa di lavoro nello stesso punto nel codice e quindi hanno tutti la stessa traccia di stack.