【面试亮点】线上GC问题排查&止损&解决 (heap space OutOfMemory排查&止损&解决)

【面试亮点】线上GC问题排查&止损&解决(heap space OOM排查&止损&解决)

许多同学总和我抱怨说面试的时候没有线上实际排查解决gc问题的经验,我这里分享我团队的一次比较好的从 发现问题->及时止损->排查问题->修复问题->复盘 全流程的实践经验,希望能帮到大家.

问题现象: CPU飙至99% 70%服务节点逐渐不可用

凌晨的时候,被电话叫醒,一看指标: CPU.busy 好家伙很多机器节点cpu使用率直接飙高到99.97%,而且raptor(理解为监控大盘工具)大量的失败请求,大概有70%的节点直接不可用!差点给我吓尿了.PM的电话,上下游的电话,各种拉群拉会的.肾上腺素顿时飙高

有问题 , 先止损, 再修复

大家在面对线上问题的时候,第一要务是迅速止损,尽可能降低资损,先保证没有增量问题的时候,再去排查解决存量问题. 不是所有节点不可用,意味着是代码导致机器出了问题,而不是mysql这样的共享资源,因为如果mysql不可用应该是所有节点的请求都会失败. 于是我们迅速查看了服务代码的发布情况,果然在前一天该服务进行了代码上线,因为之前该服务没有过这样的问题,经过短暂的排查后迅速读出结论应该是这次代码发布导致的线上问题,于是迅速执行下述止损流程:

1.禁用问题节点,防止请求打到问题节点上
2.扩容机器,注意扩容时用的包用老的包
3.禁用所有存量的,非扩容节点
4.回滚所有非扩容节点包
至此不再有增量问题,开始排查存量问题,该修数据修数据,该改bug改bug

问题排查

我们这个服务并 不是计算密集型的服务,怎么会有cpu.busy(占用率超过90%) 呢?有经验的老码农可能已经意识到了,这种情况大概率是内存在做垃圾回收,大量的垃圾回收算法会消耗大量的cpu资源.于是我们去查了一下大盘中JVM相关的一些监控,果然发现了大量的FULL GC,而且每次FULL GC的持续时间有5~6S.并且产生了"heap space OutOfMemory