一次解决jvm GC过于频繁的经历

最近有一个朋友打我电话,说他们的web服务挂了,让我看看。

JVM配置是这样的: jre1.6, 堆的最大空间是3G,线程执行栈的大小是256K,新生代的大小是1G,老年代的大小是2G.如下图:

qq%e5%9b%be%e7%89%8720161014131308

结果在日志发现了这个错误:

Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded

这个错误产生的原因是,jvm在进行gc的时候, 使用大于98% 以上的时间去释放小于 2% 的heap空间时,才会报这个异常。

这其实是jvm预判将会发生OutOfMemery异常,就提早抛出这个异常。并不代表jvm没有内存空间了。

于是在tomcat的启动参数里,加入-XX:-UseGCOverheadLimit参数,关闭jvm的预判功能。

再观察,发现没过多久,就发生了java.lang.OutOfMemoryError异常,同时发现年轻代的GC非常频繁(如下图),而且年轻代的内存还有很多剩余空间就发生了GC。怀疑业务代码里执行了System.gc(), 人工触发GC。

qq%e5%9b%be%e7%89%8720161014131230

我让那个朋友扫描代码,果然发现了System.gc()。于是在tomcat启动参数里加入-XX:+DisableExplicitGC,表示关闭人工GC。意思是,即使在业务代码里有System.gc()的调用,也不会执行GC,相当于执行了一个空调用。

重新启动tomcat再观察:年轻代的GC明显少了,而且每次都是到年轻代的内存空间没有了才GC。这就正常了。

但是这个问题还没有被真真解决,GC正常了,但是还是会发生OutOfMemoryError异常。通过使用jstat -gc pid 3s观察,还会发现:新生代的S1使用空间一直是0,即使发生GC也是0.这说明了两个问题:

1.S1分配了内存,但是一直没有被使用,简直就是浪费。

2.新生代发生GC的时候,Eden和S0的存活对象的总大小,要大于S1的大小。

下图是Heap的分配情况:

qq%e5%9b%be%e7%89%8720161014131320

为了一次性解决问题,我把堆得大小设置为5G,新生代3G,老年代2G。同时,扩大S0和S1的大小。最后的参数是这样的:

-XX:-UseGCOverheadLimit -XX:+DisableExplicitGC -Xms5G -Xmx5G -XX:NewSize=3G -XX:MaxNewSize=3G  -XX:SurvivorRatio=3

最后问题解决,服务稳定。

此条目发表在IT分类目录,贴了, , , 标签。将固定链接加入收藏夹。

发表评论

电子邮件地址不会被公开。

*