JVM GC overheadlimit问题分析

134 阅读1分钟

本文已参与「新人创作礼」活动,一起开启掘金创作之路。

image.png

 

海西同学提出了这个问题

 

先按照关键词百度一下 这个错误

 

image.png

 

显然还是GC回收效果不好造成的

收不回来

 

那我们就用jstat来看下GC的状态

 

image.png

 

机器全面崩溃

所有的内存都占满了

新生代 老年代 统统完蛋

 

这个情况下不管是 Jmap命令还是 play status命令 都执行不了

无法实施监控

只能去看看日志

日志里暂时无法看到有价值的内容

 

所以只能重启了 然后观察 GC情况

image.png  

通过连续的观察

发现每次 YGC后 都会丢对象到老年代

老年代空间逐渐占满

1/7 1/6 1/5 1/4最后发生了fullgc

 

我观察的这段时间内发生了2次fullgc

这是有问题的 太频繁

 

JMAP拉一下堆内存

  image.png

image.png  

 

初步怀疑和数据库操作有关系

hibernate出现的频率太高

 

有一个可疑的JOB 先关闭掉了

 

image.png

 

关闭之后 GC情况虽然不好 但是 还是可以运行的

 

后来打开了它

 

image.png  

很快就飚满了内存

 

那么最大的问题就是它了。

 

这提供了一个思路,我们怀疑哪个就给它从程序卸掉,给他降级,看看他剥离之后有什么效果,自然就断定问题是不是他了。

 

剥离的方式,JOB好做。

如果是HTTP请求 则可以 返回空值或者异常值,让他不被调用到