Websphere 7 线程转储分析

Question

我们正在使用 WAS 7，并且我们的耳朵已经部署在上面。

环境详情

操作系统：AIX 7.1

处理器架构：ppc64

处理器数量：8

Java 版本：JRE 1.6.0 AIX ppc64-64 build jvmap6460sr10fp1-20120202_101568 (pap6460sr10fp1-20120321_01(SR10 FP1))

虚拟机版本：VM build 20120202_101568 Just-In-Time(JIT) 编译器开关，Ahead-Of-Time (AOT) 编译器开关，编译器版本：r9_20111107_21307ifx1

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

Java 堆信息

最大 Java 堆大小：1024m

初始 Java 堆大小：512m

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

以下是主题摘要

但我无法分析，这个静态是好还是需要改进？

由于我们在 Parking/Waiting on Condition 中始终有这么多线程（每天使用线程 sump 10 次），有时应用程序需要 4 秒来处理 5 条消息，假设是每秒 5 条消息。

应用程序运行良好，实现了每秒 5 条消息的 SLA，但是说一天中有几次需要 4 秒来处理 5 条消息。

注意：并发处理。

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

Answer 1

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

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

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

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

即使慢速消息不可重现并且您无法识别消息的任何显着特征，至少您现在知道它何时发生并且可以更精确地深入研究。

一旦有时间，您就可以在这些时间开始检查不同的原因。一份不详尽的清单包括：

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

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