Инструмент / метод анализа дампа резьбы [закрыто]

когда приложение Java висит, вы даже не знаете прецедент, который приводит к этому, и хотите исследовать, я понимаю, что дампы потоков могут быть полезны.

но как мы можем легко получить полезные данные из дампов потоков, чтобы найти, где проблема? Серверное приложение, с которым я работал, создает очень длинные дампы потоков, потому что это архитектура EJB, а дампы потоков содержат много потоков контейнеров, которые я не уверен, что должен смотреть (т. е. потоки, которые не выполняют мой код приложения, но код JBoss).

вчера я попробовал Анализатор Дампа Потока. Этот инструмент определенно лучше, чем просмотр необработанных дампов потоков в текстовом редакторе, потому что вы можете отфильтровать потоки, которые вас не интересуют, просмотреть список потоков, щелкнуть по потоку, чтобы увидеть его детали, сравнить дампы потоков, чтобы найти длинные текущие потоки и т. д. Смотрите скриншот ниже:

но есть еще слишком много данных для анализа - почти 300 нитей. Я не знаю никаких критериев, которые я мог бы использовать для фильтрации всех потоков JBoss, в которых я не заинтересован. Я не уверен, должен ли я смотреть на потоки, которые в настоящее время находятся только в состоянии "runnable" или если "ожидание при условии" и "в объекте.подождите " также важны.

каков подход, которому вы обычно следуете, и инструменты, которые вы обычно используете?

3 61
javascript debugging deadlock thread-dump

3 ответа:

один набор дампов потоков в одиночку не будет слишком полезным, чтобы добраться до основной причины.

трюк состоит в том, чтобы взять 4 или 5 наборов дампов потоков с интервалом в 5 секунд между каждым. таким образом, в конце у вас будет один файл журнала, который имеет около 20 - 25 секунд действия на сервере приложений.

то, что вы хотите проверить, когда происходит застрявший поток или длительная транзакция, все дампы потоков покажут, что определенный идентификатор потока находится в одной строке в вашей java трассировка стека. Проще говоря, транзакция (скажем, в EJB или базе данных) охватывает несколько дампов потоков и, следовательно, нуждается в большем исследовании.

теперь, когда вы запускаете их через самурай (Я сам не использовал TDA), он выделит их красным цветом, чтобы вы могли быстро щелкнуть по нему и добраться до строк, показывающих проблемы.

пример здесь. Посмотрите на выходное изображение самурая в этой ссылке. Зеленые клетки в порядке. Красные и серые клетки нужно смотреть.

пример самурая из моего собственного веб-приложения ниже показывает застрявшую последовательность для потока ' 19 ' через промежуток 5-10 секунд

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

обновление

Я недавно использовал Анализатор Дампа Потока Java указано в ответ и это было очень полезно для Tomcat в отличие от Samurai

28

Я знаю, что это старый вопрос, но я просто написал инструмент, чтобы помочь сделать длинные дампы потока более читаемыми.

Java Thread Dump Analysis Tool

этот инструмент группирует потоки вместе, которые имеют одну и ту же трассировку стека и позволяет отображать только потоки, которые находятся в определенных состояниях (например, запускаемые или заблокированные).

Это делает его немного быстрее, чтобы найти интересные темы среди десятков или сотен нитей с JBoss, которые проводят большую часть время их работы на одном месте в коде, и поэтому все имеют одинаковую трассировку стека.

28

Я не уверен, что должен смотреть потоки, которые в настоящее время находятся в состояние "runnable" только или если " ожидание по условию " и " в объекте.погоди" это тоже важно.

последние два на самом деле the вещи, которые нужно искать при диагностике тупика, как вы, кажется, делаете. "Runnable" означает, что поток делает что-то прямо сейчас (или ждет, чтобы получить процессор). "заблокировано "и" ожидание " - это то, из чего сделаны тупики.

Of конечно, контейнер приложения будет иметь много потоков, ожидающих законно. Чтобы отфильтровать интересные случаи, посмотрите на трассировку стека. Если это классы фреймворка (и особенно те, которые называются "рабочий" или "очередь"), это, вероятно, нормально. Если это код приложения, вы должны посмотреть на него более внимательно.

6