Инструмент/метод анализа дампа потока

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

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

Вчера я попробовал инструмент инструмент Dump Analyzer. Инструмент определенно лучше, чем просмотр исходных дампов потока в текстовом редакторе, потому что вы можете отфильтровывать потоки, которые вам не интересны, просматривать список потоков, нажимать на поток, чтобы увидеть его данные, сравнить потоки дампов, чтобы найти длинные потоки и т.д. Смотрите снимок экрана ниже:

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

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

Ответ 1

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

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

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

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

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

Пример Samurai из моего собственного веб-приложения ниже показывает застрявшую последовательность для Thread'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 Thread Dump Analyzer, упомянутый в этом ответе и это было очень полезно для Tomcat, в отличие от самурая

Ответ 2

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

Инструмент анализа дампа Java Java

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

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

Ответ 3

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

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

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