首先，如果我没有提供足够的信息来正确解决此问题，我深表歉意。这类事情不是我的专长，所以这是一个学习过程。如果我需要提供什么，请告诉我，我很乐意尽我所能。与我的问题相关的图片位于本文底部。
我们正在处理由四台 WebLogic 9.2 Java 应用服务器组成的集群环境。该集群采用循环负载算法。其他详细信息包括：
- Java(TM) 2 运行时环境，标准版（版本 1.5.0_12-b04）
- BEA JRockit(R)（构建 R27.4.0-90_CR352234-91983-1.5.0_12-20071115-1605-linux-x86_64，编译模式）
基本上，我开始关注服务器的性能，因为我们的客户在一天中的不同时间都发现了很多延迟。我们的服务器应该可以轻松处理给定的负载，所以不清楚到底发生了什么。使用 HP Performance Manager，我生成了一些图表，表明 CPU 使用率完全失控。似乎在任何给定点，一台或多台服务器的 CPU 利用率都超过 50%。我知道这不是特别高，但根据 WebLogic 集群中其他服务器的 CPU 利用率，我会说这是一个危险信号。
值得注意的一些有趣的事情：
- 高 CPU 利用率仅出现在 server02 上，持续了数周。服务器崩溃（极其罕见；我们不确定是否与此有关），重新启动后，所有 4 台服务器的 CPU 利用率均恢复正常。
- 昨天（2 月 28 日），我们重启了所有 4 台托管服务器和应用服务器（在 server01 上）。如您所见，server03 和 server04 恢复了之前在 server02 上看到的行为。
- CPU 利用率是应用程序用户 (appown) 拥有的 Java 进程。
- 所有服务器的交易数量一致。似乎没有任何一台服务器处理的交易量实际上比另一台服务器多。
如果有人有任何想法或至少能给我指明正确的方向，那就太好了。再次，如果我需要发布任何其他信息，请告诉我。谢谢！
答案1
负载平衡是完全循环的还是基于 IP 或 cookie 进行粘性？您可能会有一些用户流量粘在一台服务器上并在重新启动时移动 - 特别是如果您的另一台服务器正在调用集群上的应用程序。因此，请将其与服务器的实际访问量进行交叉检查。
您的应用程序中还可能存在竞争条件，即某些操作会使其陷入循环。为此，您可以获取线程转储 (kill -3 pid) 并将其从 stdout 日志中拉出，然后对其运行 Samurai 之类的程序以查看发生了什么。
我还会打开垃圾收集日志并查看 GC 时间是否与感知的滞后时间相关。
答案2
我不是集群或 Bea 专家，但在性能分析问题中，不仅仅只有 CPU。内存、磁盘和网络的数据是什么？获取数据的工具是 top（cpu 和内存，包含许多详细信息，也包含每个进程）、vmstat（内存、cpu、磁盘）、sar（linux 上的 sysstat 包，包含所有可能的数据和历史记录）。那么，这些机器的操作系统是什么，哪个版本？
答案3
我会安装 Java 探测器和配置文件Web 应用程序来进一步调查那 50% 的 CPU 到底去哪儿了。
答案4
在每台服务器上触发一个或两个线程转储。您可能会发现其中一台服务器正在运行一个线程，而其他服务器上没有运行。还可以通过控制台检查内存利用率。我曾看到 WebLogic 在内存不足时陷入垃圾收集循环。