Narzędzie analizy zrzutu wątków/metoda

Question

Gdy zawiesza się aplikacja Java, nie znasz nawet przypadku użycia, który prowadzi do tego i chcesz zbadać sprawę. Rozumiem, że zrzuty wątków mogą być przydatne.

Ale jak możemy łatwo wyprowadzić użyteczne dane ze zrzutu wątku, aby znaleźć miejsce, w którym występuje problem? Aplikacja serwera, z którą pracowałem, tworzy bardzo długie zrzuty wątków, ponieważ jest to architektura EJB, a zrzuty wątków zawierają wiele wątków kontenerowych, na których nie powinienem polegać (tj. Wątków, które nie obsługują mojego kodu aplikacji). , ale kod JBossa).

Wczoraj wypróbowałem narzędzie Thread Dump Analyzer. Narzędzie jest zdecydowanie lepsze niż spojrzenie na nieprzetworzone zrzuty nici w edytorze tekstu, ponieważ możesz odfiltrować wątki, które Cię nie interesują, zobacz listę wątków, kliknij wątek, aby zobaczyć jego szczegóły, porównaj zrzuty wątków, aby znaleźć długo działa wątki itd patrz obrazek poniżej:

ale jest jeszcze zbyt wiele danych do analizy - prawie 300 wątków. Nie znam żadnych kryteriów, za pomocą których mógłbym odfiltrować wszystkie wątki JBoss, w których nie jestem zainteresowany. Nie jestem pewien, czy powinienem przyglądać się wątkom, które są obecnie w stanie "uruchomionym", czy też "oczekujące warunku" i "w Object.wait" są również ważne.

Jakie podejście zazwyczaj stosujesz i jakich narzędzi używasz?

Answer 1

Jeden zestaw zrzutów nici sam w sobie nie będzie zbyt pomocny, aby dostać się do pierwotnej przyczyny.

Sztuką jest wykonanie 4 lub 5 zestawów zrzutów nici w odstępach 5 sekundowych między nimi. więc na końcu będziesz mieć jeden plik dziennika, który ma około 20-25 sekund akcji na serwerze aplikacji.

To, co chcesz sprawdzić, to kiedy utkniesz w wątku lub długa uruchomiona transakcja, wszystkie zrzuty wątku pokaże pewien identyfikator wątku na tym samym wierszu w twoim stosie java. Mówiąc prościej, transakcja (powiedzmy w EJB lub bazie danych) obejmuje wiele zrzutów wątków i dlatego wymaga więcej badań.

Teraz po uruchomieniu ich przez Samurai (sam nie używałem TDA), podświetli je w kolorze czerwonym, aby można było szybko kliknąć i przejść do linii pokazujących problemy.

Zobacz przykład z this here. Spójrz na obraz wyjściowy Samurai w tym łączu. Zielone komórki są w porządku.Czerwone i szare komórki wymagają patrzenia.

samurajem przykład z własnej aplikacji internetowej poniżej przedstawia zatrzymany sekwencję Thread'19' w całej rozpiętości 5 - 10 sekund

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

aktualizacji

Ostatnio użyłem Java Thread Dump Analyzer wspomnianego in this answer i było bardzo przydatne dla Tomcat w przeciwieństwie do Sa murai

Answer 2

Nie jestem pewien, czy powinien być patrząc na wątków, które są obecnie w „runnable” lub jeżeli tylko stan „czekania na stan” i „w Object.wait” są również ważna.

Te dwie ostatnie są rzeczywiście się rzeczy zwrócić uwagę przy diagnozowaniu impasu, ponieważ wydaje się, że robi. "Runnable" oznacza, że ​​wątek robi coś teraz (lub czeka na procesor). "Zablokowane" i "czekanie" jest tym, z czego są robione blokady.

Oczywiście, kontener aplikacji będzie miał wiele wątków oczekujących legalnie. Aby odfiltrować interesujące przypadki, spójrz na ślad stosu. Jeśli są to klasy szkieletowe (a szczególnie te o nazwie "Worker" lub "Queue"), to prawdopodobnie jest OK. Jeśli jest to kod aplikacji, powinieneś przyjrzeć się temu bliżej.

Answer 3

Wiem, że to stare pytanie, ale właśnie napisałem narzędzie, które pomoże uczynić długie wątki bardziej czytelne.

Java Thread Dump Analysis Tool

To narzędzie grupuje razem nici, które mają ten sam ślad stosu i pozwala jedynie do występów nici, które znajdują się w poszczególnych stanach (np Runnable lub zablokowany).

To sprawia, że ​​jest nieco szybciej znaleźć interesujące wątki wśród dziesiątek lub setek wątków JBoss, które spędzają większość czasu czekając na pracę w tym samym miejscu kodu, a zatem wszystkie mają taki sam ślad stosu.