2

我们正在使用 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，但一天中有几次说处理 5 条消息需要 4 秒。

注意：并发处理。

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

4

1 回答 1

4

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

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

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

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

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

一旦你有时间，你就可以在那个时候开始检查不同的原因。一份不详尽的清单将包括：

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

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

于 2014-03-14T10:30:19.593 回答