线程转储分析工具/方法 [英] Thread Dump Analysis Tool / Method

查看:35
本文介绍了线程转储分析工具/方法的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

当 Java 应用程序挂起时,您甚至不知道导致这种情况的用例并想进行调查,我知道线程转储很有用.

When the Java application is hanging, you don't even know the use case that is leading to this and want to investigate, I understand that thread dumps can be useful.

但是我们如何轻松地从线程转储中获取有用的数据以找出问题所在?我一直在使用的服务器应用程序产生了很长的线程转储,因为它是一个 EJB 体系结构,并且线程转储包含许多我不确定我应该查看的容器线程(即没有运行我的应用程序代码的线程), 但 JBoss 的代码).

But how can we easily derive useful data from the thread dumps to find where the problem is? The server application that I've been working with produces very long thread dumps, because it is an EJB architecture and thread dumps contains many container threads that I'm not sure I should be looking at (i.e. threads that are not running my application code, but JBoss's code).

昨天我尝试了 线程转储分析器 工具.该工具绝对比在文本编辑器中查看原始线程转储更好,因为您可以过滤掉您不感兴趣的线程,查看线程列表,单击线程查看其详细信息,比较线程转储以查找长时间运行的线程等

Yesterday I tried the Thread Dump Analyzer tool. The tool is definitely better than looking at the raw thread dumps in a text editor, because you can filter out threads that you're not interested in, see the thread list, click on a thread to see its details, compare thread dumps to find long running threads, etc.

但仍有太多数据需要分析 - 将近 300 个线程.我不知道有什么标准可以用来过滤掉我不感兴趣的所有 JBoss 线程.我不确定是否应该查看当前处于可运行"状态的线程.仅声明或等待条件"和在 Object.wait"中也很重要.

But there's still too much data to analyse - almost 300 threads. I don't know of any criteria that I could use to filter out all the JBoss threads, in which I'm not interested. I'm not sure if I should be looking at threads that are currently in "runnable" state only or if "waiting on condition" and "in Object.wait" are also important.

您通常遵循的方法和通常使用的工具是什么?

What's the approach that you would normally follow and tools that you would in general use?

推荐答案

单独的一组线程转储不会帮助找到根本原因.

One set of thread dumps alone will not be too helpful to get to the root cause.

诀窍是每隔 5 秒进行 4 或 5 组线程转储.因此,最后您将拥有一个日志文件,其中在应用服务器上有大约 20 到 25 秒的操作时间.

The trick is to take 4 or 5 sets of thread dumps at an interval of 5 seconds between each. so at the end you will have a single log file which has around 20 - 25 seconds worth of action on the app server.

您要检查的是,当发生卡住的线程或长时间运行的事务时,所有线程转储都会显示某个线程 ID 位于您的 Java 堆栈跟踪中的同一行.简单来说,事务(比如在 EJB 或数据库中)跨越多个线程转储,因此需要更多调查.

What you want to check is when a stuck thread or long running transaction happens, all the thread dumps will show a certain thread id is at the same line in your java stack trace. In simpler terms, the transaction (say in an EJB or database) is spanning across multiple thread dumps and hence needs more investigation.

现在,当您通过 Samurai 运行这些时(我自己还没有使用 TDA),它将以红色突出显示这些内容,以便您可以快速点击它并找到显示问题的行.

Now when you run these through Samurai (I havent used TDA myself), it will highlight these in Red colour so you can quickly click on it and get to the lines showing issues.

在此处查看 的示例.查看该链接中的 Samurai 输出图像.绿色单元格很好.需要查看红色和灰色单元格.

See an example of this here. Look at the Samurai output image in that link. The Green cells are fine. Red and Grey cells need looking at.

下面来自我自己的 Web 应用程序的 Samurai 示例显示了 Thread'19' 在 5 到 10 秒的范围内的卡住序列

A Samurai example from my own web app below shows a stuck sequence for Thread'19' across a span of 5 - 10 seconds

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

更新

我最近使用了在这个答案中,它对 Tomcat 非常有用,而不是 Samurai

I recently used the Java Thread Dump Analyzer mentioned in this answer and it's been very useful for Tomcat as opposed to Samurai

这篇关于线程转储分析工具/方法的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆