java - JVM 在 RHEL 5.2 的压力下崩溃

Question

在 4 到 24 小时 4 小时到 8 天后，我在(当前最新的)tomcat 6.0.24 上运行 Web 应用程序时，(当前最新的)jdk 1.6.0.18 意外崩溃压力测试(30 个线程以 600 万次/天的浏览量访问应用程序)。这是在 RHEL 5.2 (Tikanga) 上。

崩溃报告位于 http://pastebin.com/f639a6cf1崩溃的一致部分是:

• 正在抛出一个 SIGSEGV
• 在 libjvm.so 上
• eden 空间总是满的 (100%)

JVM 使用以下选项运行:

CATALINA_OPTS="-server -Xms512m -Xmx1024m -Djava.awt.headless=true"

我还使用 http://memtest.org/ 测试了内存的硬件问题48 小时(整个内存的 14 次传递)没有任何错误。

我已启用 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 来检查任何 GC 趋势或空间耗尽，但没有任何可疑之处。 GC 和完整 GC 以可预测的时间间隔发生，几乎总是释放相同数量的内存容量。

我的应用程序不直接使用任何 native 代码。

关于我接下来应该看哪里的任何想法？

编辑 - 更多信息:

1)这个JDK中没有客户端vm:

[foo@localhost ~]$ java -version -server
java version "1.6.0_18"
Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Java HotSpot(TM) 64-Bit Server VM (build 16.0-b13, mixed mode)

[foo@localhost ~]$ java -version -client
java version "1.6.0_18"
Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Java HotSpot(TM) 64-Bit Server VM (build 16.0-b13, mixed mode)

2) 无法更改操作系统。

3) 我不想更改 JMeter 压力测试变量，因为这可能会隐藏问题。由于我有一个使 JVM 崩溃的用例(当前压力测试场景)，我想修复崩溃而不是更改测试。

4) 我已经完成了 static analysis在我的申请上，但没有什么严重的事情发生。

5) 内存不会随时间增长。内存使用量很快(启动后)以非常稳定的趋势平衡，这似乎并不可疑。

6)/var/log/messages 在崩溃之前或期间不包含任何有用的信息

更多信息:忘记提及有一个使用 mod_jk 1.2.28 的 apache (2.2.14) fronting tomcat。现在我在没有 apache 的情况下运行测试，以防 JVM 崩溃与连接到 JVM(tomcat 连接器)的 mod_jk native 代码有关。

之后(如果 JVM 再次崩溃)我将尝试从我的应用程序中删除一些组件(缓存、lucene、quartz)，稍后将尝试使用 jetty 。由于崩溃目前发生在 4 小时到 8 天之间的任何时间，因此可能需要很长时间才能查明发生了什么。

Answer 1

你有编译输出吗？即 PrintCompilation(如果你觉得特别勇敢，LogCompilation)。

我在这部分调试了这样的情况，通过观察编译器在做什么，最终(这花了很长时间直到灯泡时刻)，意识到我的崩溃是由编译中的特定方法引起的Oracle jdbc 驱动程序。

基本上我会做的是；

• 开启PrintCompilation
• 因为它不提供时间戳，所以编写一个脚本来监视该日志文件(就像每秒 hibernate 并打印新行)并报告方法何时被编译(或未编译)
• 重复测试
• 检查编译器输出以查看崩溃是否与某些方法的编译相对应
• 再重复几次，看是否有规律

如果存在可识别的模式，则使用 .hotspot_compiler(或 .hotspotrc)使其停止编译有问题的方法，重复测试并查看它是否不会崩溃。显然，在您的情况下，我担心这个过程理论上可能需要几个月的时间。

一些引用资料

• 用于处理日志编译输出 --> http://wikis.sun.com/display/HotSpotInternals/LogCompilation+tool
• 有关 .hotspot_compiler 的信息 --> http://futuretask.blogspot.com/2005/01/java-tip-7-use-hotspotcompiler-file-to.html或 http://blogs.oracle.com/javawithjiva/entry/hotspotrc_and_hotspot_compiler
• 一个用于观察编译器输出的非常简单、快速且肮脏的脚本 --> http://pastebin.com/Haqjdue9
• 请注意，这是为 solaris 编写的，与 gnu 等价物相比，solaris 始终具有奇怪的实用程序选项，因此毫无疑问，在其他平台上或使用不同的语言更容易做到这一点

我要做的另一件事是系统地更改您正在使用的 gc 算法并检查 gc Activity 的崩溃时间(例如，它是否与新的或旧的 gc 相关，TLAB 呢？ ？)。你的转储表明你正在使用并行清除所以尝试

• 串行(年轻)收集器(IIRC 它可以与并行旧的结合)
• ParNew + CMS
• G1

如果它在不同的 GC 算法中没有重复出现，那么您就知道问题出在这里(并且您没有解决办法，只能更改 GC 算法和/或返回旧的 JVM，直到找到该算法的版本'吹)。