崩溃报告在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以可预见的间隔发生,几乎总是释放相同的内存容量.
我的应用程序不直接使用任何本地代码.
任何关于我应该在下面看的想法
编辑 – 更多信息：
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)不能更改O / S.
3)我不想改变JMeter压力测试变量,因为这可能会隐藏问题.因为我有一个用例(目前的压力测试场景)崩溃了我想修复崩溃的JVM,而不改变测试.
4)我在应用程序上做了static analysis,但没有什么严重的.
5)内存不会随着时间的推移而增长.内存使用情况在非常稳定的趋势(启动后)平稳很快,似乎并不可疑.
6)/ var / log / messages在崩溃之前或过程中不包含任何有用的信息
更多信息：忘记说,有一个apache(2.2.14)前面tomcat使用mod_jk 1.2.28.现在我运行测试没有apache,以防万一JVM崩溃与连接到JVM(tomcat连接器)的mod_jk本机代码.
之后(如果JVM再次崩溃),我将尝试从我的应用程序(缓存,lucene,石英)中删除一些组件,稍后将尝试使用jetty.由于事故现在发生在4小时至8天之间的任何时间,因此可能需要很多时间来了解发生了什么.
解决方法
我已经通过观察编译器在做什么来调试一个这样的情况,最终(这花了很长时间,直到灯泡的时刻),意识到我的崩溃是由oracle jdbc驱动程序中的一个特定方法的编译引起的.
基本上我会做的是
>打开PrintCompilation
>因为没有给出时间戳,写一个脚本来监视该日志文件(比如每秒睡一次打印新行),并在编译方法时报告(或不)
>重复测试
检查编译器输出,看看崩溃是否与某些方法的编译相对应
再重复几次,看看是否有图案
如果有一个可辨别的模式,则使用.hotspot_compiler(或.hotspotrc)使其停止编译违规方法,重复测试,看看它是否不会爆炸.显然,在你的情况下,这个过程理论上可能需要几个月的时间我害怕.
一些参考
>用于处理logcompilation输出 – > 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等价物相比,它总是具有奇怪的选项,而无需在其他平台上使用不同的语言更容易的方法
我会做的另一件事是系统地更改您使用的gc算法,并检查与gc活动的崩溃时间(例如,它是否与年轻或旧的gc相关,TLAB呢？).您的转储表明您正在使用并行扫描,所以尝试
>系列(年轻)收藏家(IIRC,可以并行老化)
> ParNew CMS
> G1
如果它不再与不同的GC algos重现,那么你知道它是这样的(你没有修复,但是要更改GC算法和/或回溯到较旧的JVM,直到找到一个不会吹动的算法的版本).