神刀安全网

记一次频繁FGC的简单排查


简书 占小狼
转载请注明原创出处,谢谢!
如果读完觉得有收获的话,欢迎点赞加关注

周末愉快,今天有时间记录一下上周遇到的一个问题,学习的脚步不能放慢,也不敢放慢。

记一次频繁FGC的简单排查

存在问题

在线上环境进行服务压测,压测完成后,cpu使用率居高不下,很是费解,按理说已经没有压测请求了,这时消耗cpu资源的只有GC线程了,可以通过jstat命令查看一下JVM的GC情况,然后就碰到了诡异的GC问题。

jstat命令

jstat [ generalOption | outputOptions vmid [interval[s|ms] [count]] ]

参数:
generalOption: 一般使用-gcutil查看GC情况
vmid: 虚拟机进程号,即当前运行的java进程号
interval: 间隔时间,单位为秒或毫秒
count: 打印次数,如果缺省则打印无数次

执行jstat -gcutil 9132 1000命令,线上服务器的GC情况如下:

记一次频繁FGC的简单排查

参数说明如下:
S0: 新生代中Survivor space 0区已使用空间的百分比
S1: 新生代中Survivor space 1区已使用空间的百分比
E: 新生代已使用空间的百分比
O: 老年代已使用空间的百分比
P: 永久带已使用空间的百分比
YGC: 从应用程序启动到当前,发生Yang GC 的次数
YGCT: 从应用程序启动到当前,Yang GC所用的时间【单位秒】
FGC: 从应用程序启动到当前,发生Full GC的次数
FGCT: 从应用程序启动到当前,Full GC所用的时间
GCT: 从应用程序启动到当前,用于垃圾回收的总时间【单位秒】

问题分析

通过打印的GC数据可以看出,JVM一直在进行FGC(cms gc),不过老年代的使用率反而没有下降,一直稳定在60.16%,对这一情况很疑惑,几乎每次都重现,后来去仔细查看了JVM的启动参数,发现其中CMSInitiatingOcupancyFraction参数,被设置成60,意味着当老年代的使用率达到阈值60%时会触发FGC,但是FGC之后,老年代的使用率还是大于60%,所以会不断的进行FGC,建议这个值不要设置的这么小。

至于为什么FGC之后,老年代的使用率没有下降,可以通过dump查看到底是哪些存活对象在作怪,在进行FGC时,通常会伴随着一次YGC,但这也不是一定的,如果执行YGC之后没有明显效果的话,会设置一个变量,表明下次不用进行YGC,所以如果老年代如果存在大量对象的GC ROOT在新生代的话,这些对象就不会被回收,这种情况必须强制执行一次YGC之后,才有可能回收这些老年代的对象,比如添加参数-XX:+CMSScavengeBeforeRemark,就可以解这个问题。

昨天正好笨神也遇到类似的问题,并写一篇文章《又抓了一个导致频繁GC的鬼–数组动态扩容》进行分析,可以参考一下。

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » 记一次频繁FGC的简单排查

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址