现象
生产环境突然间大量接口超时告警,监控发现,问题发生的时间,cpu使率飙升,网络磁盘抖动大,内存使用率飙升,大约3-5分钟后系统自动恢复。


异常分析思考
从监控看到,cpu,内存,磁盘,网络在异常发生时都有明显的抖动。
内存使用率突然飙升,应用IO也突然陡增。猜测可能是该时刻有定时任务,或者大量请求导致。问题发生时刻,细致对比变化时间,发现是首先网络IO飙升,磁盘突然增加,猜测可能是该时刻有大量请求导致。
综合分析下,我们猜测,最大可能是请求量突然暴增,导致系统负载过高,内存,cpu使用率飙升。
问题排查
接口调用量异常排查
根据监控异常,我们猜测最有可能的是该时刻有大量的请求,或者定时任务,导致系统负载突然增加。我们从监控上找到对应的几个问题发生时间段,调用量明显增多的接口。排查代码后,发现没有变更,调用量突然增大是因为cpu异常导致积累了一些请求,所以会看起来调用量突然增加。
内存使用率异常排查
应用异常时,根据监控发现内存使用率飙升,我们找到当时该实例的jvm相关指标监控,发现发生问题时,触发了FullGc,Full Gc次数明显增多,gc耗时增加,堆内存飙升,老年代空间飙升。这里使用的是默认的垃圾收集器 Parallel Scavenge(新生代)+ Serial Old(老年代),后续我们调整为G1垃圾收集器。
下图可见,full gc次数增加多

本文记录了一次由于Full GC导致的CPU飙升问题的排查过程。监控显示,系统在异常时段出现CPU、内存使用率及网络磁盘抖动。通过分析,发现是请求量增加触发了Full GC,导致内存飙升,且使用了Parallel Scavenge + Serial Old垃圾收集器。调整为G1收集器后,问题依然存在。通过JVM内存设置和线程堆栈分析,定位到特定SQL查询加载大量数据,引发内存溢出。解决方案包括调整JVM参数、增加SQL监控和告警。

1572

被折叠的 条评论
为什么被折叠?



