java - Websphere 7 线程转储分析

Question

我们使用的是 WAS 7，我们的耳朵部署在其上。

环境详细信息

操作系统:AIX 7.1

处理器架构:ppc64

处理器数量:8

Java 版本:JRE 1.6.0 AIX ppc64-64 构建 jvmap6460sr10fp1-20120202_101568 (pap6460sr10fp1-20120321_01(SR10 FP1))

虚拟机版本:VM 内部版本 20120202_101568 即时(JIT)编译器开关，提前(AOT)编译器开关，编译器版本:r9_20111107_21307ifx1

垃圾收集器版本:GC - 20120202_AA_CMPRSS

Java堆信息

最大 Java 堆大小:1024m

初始 Java 堆大小:512m

我尝试使用IBM Thread and Monitor Dump Analyzer工具来分析堆转储。

以下是主题摘要

但我无法分析这个静态数据是否良好或需要改进？

由于我们有如此多的线程始终处于“ parking /等待条件”状态(每天进行线程池 10 次)，有时应用程序需要 4 秒来处理 5 条消息，假设每秒处理 5 条消息。

应用程序运行良好，并达到每秒 5 条消息的 SLA，但一天中有几次需要 4 秒才能处理 5 条消息。

注意:并发处理。

如果我当时试图获取线程转储，就像我上面分享的那样。

Answer 1

除非您有充分的理由认为线程争用是原因，否则我不认为线程转储是开始调查为什么“一天中有几次需要 4 秒处理 5 条消息”的最佳位置。 ”。导致该问题的原因可能有很多很多，线程争用只是其中之一。

首先，我会识别这些消息。大概消息的速度被记录在某个地方，如果没有，我会从那里开始。 Web 服务器访问日志可以帮助识别这些消息吗？

一旦你有了它们，这些消息有什么独特之处吗？如果您自己访问这些消息，您是否能够复制缓慢的情况？他们是否总是在一天中的同一时间/他们是否尝试访问相同的实体或执行相同的操作？消息是否由同一用户发送？

如果它是可重现的，那么你的工作就完成了一半。您现在可以开始使用分析工具来确定为什么需要这么长时间。

即使缓慢的消息不可重现，并且您无法识别消息的任何显着特征，至少您现在知道它何时发生，并且可以更精确地向下钻取。

一旦你有时间，你就可以开始检查当时的不同原因。不详尽的列表包括:

• 当时是否正在进行全面垃圾收集？
• 当时应用服务器上是否运行着其他进程？
• 如果它访问数据库，当时是否处于负载状态？
• 日志中是否有当时的错误消息？
• 当时有任何线程争用吗？
• 当时是否存在任何运行缓慢的数据库查询(例如，如果您使用 Oracle，Oracle AWR 可能会给出此信息)？
• 此时有很多用户使用该网站吗？

识别这些问题需要根据自己的权利找到答案，但 Stackoverflow 应该有很多答案。 关于线程争用 - 是在问题发生时进行的线程分析。就我个人而言，我希望从那一刻开始进行线程转储，以尝试查看哪些线程被其他线程阻塞。