【问题标题】:Analyze the "runnable" thread dump under high load server side分析高负载服务器端下的“可运行”线程转储
【发布时间】:2011-07-19 20:16:30
【问题描述】:

来自基于 java 的应用程序的线程转储很容易获得但很难分析!

我们可以从线程转储中看到一些有趣的东西。

假设我们在一个负载很重的 java web 应用程序中。而且我经常在高峰时间(在高负载下)使用 10 或 15 个线程转储文件来制作宽数据。所以首先,毫无疑问,我们需要调整状态为 BlockedMonitor 的代码。其余的 Runnable 线程我无法深入研究。

那么,如果“方法”多次出现在线程转储中,我们可以说它在高负载服务器端比另一个慢或快吗?当然,我们可以使用更多的分析工具来检查,但是线程转储可能会给我们同样有用的信息,尤其是我们在生产环境中。

谢谢你的建议!

万斯

【问题讨论】:

  • 等等..什么?!你的问题到底是什么?
  • 我的问题是,我们有时可能会“忽略”线程转储中的“可运行”状态。你认为它们的真正含义是什么?它们只是在运行状态下真的“正常”,还是我们可以从中看到一些性能问题?很抱歉我发布的误解问题。
  • 我建议你关注堆栈跟踪发生变化的线程。对于那些有静态堆栈跟踪的人来说,他们很可能什么也没做。
  • 理想情况下,您会在生产环境或类似生产环境中使用分析器。这需要大量的猜测才能解决问题。
  • 谢谢!由于线程转储的开销低于分析器,因此这是我在调查性能问题时的首选。

标签: java analysis performance


【解决方案1】:

无论线程的状态如何,我都会仔细查看每个转储中线程的调用堆栈,并询问“在那个时间点它到底在做什么或等待什么,为什么?”

您不仅查看调用堆栈上的函数,还查看调用函数的代码行。这会告诉您呼叫的本地原因。如果您结合堆栈上调用的本地原因,则可以为您提供当时线程正在做什么的完整原因(“为什么链”)。

您正在寻找的是出现在多个快照上的不好的原因。 (只需一次对堆栈进行不必要的调用即可使整个样本可改进,因此堆栈越深,搜索效果越好。) 由于它们很糟糕,因此可以修复它们,您将获得更高的性能。性能改进的数量大致是显示它们的快照的一部分。 那是this technique

【讨论】:

  • 谢谢!将练习更多使用线程转储进行调查/分析!
【解决方案2】:

我会说,如果一个方法经常出现在线程转储中,你必须要么

  1. 优化该方法,因为它被多次调用或
  2. 检查该方法是否被频繁调用

如果您看到线程运行在特定方法中花费大量时间,则可能还有一些错误(就像我们使用特殊的正则表达式时遇到的正则表达式引擎中的错误一样)。所以你需要调查一下。

【讨论】:

    猜你喜欢
    • 2016-10-23
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-01-18
    相关资源
    最近更新 更多