记录线上RT规律性增加问题排查

背景

营销中心一个新工程上线，工程上线后，监控平台显示RT水位呈规律性上涨降低

初次排查

初次看监控图，认为是redis key批量同时失效致使的，由于波峰的相隔时间正好是15分钟，redis的key失效时间也正好设置了这个时间。同时，当时公司运维反馈给个人，该表的sql请求量较大，15分钟调用了 36530次，占了该库性能的80%.

从链路监控中发现部分mysql的RT很高。

初次问题定位

结合db响应时间，初步定位问题为：缓存穿透后，大量的sql请求量致使RT上升。

可是其实没法解释规律性上涨问题。

因而乎，增长缓存击穿保护，发布上线，发现RT居然下来了！认为问题已经解决。

问题再次出现

过了个端午，今天再看RT状况，又恢复第一张图的状况

问题排查

感受问题并不是当初想象的那样。因而检查服务器状况，发现服务器CPU使用也很是奇葩。

因而使用jstack 排查工程中多线程使用状况，发现无异常。

使用 top -Hp pid 查看CPU使用最频繁的线程

printf "%x\n" 19838 获取到十六进制值 4d7e

jstack 19832 | grep "4d7e" 查看线程状况

发现消耗CPU最多的居然是gc线程

jstat -gc 19832 1000 查看GC状况

发现大bug了。老年代只配置了64M，线上一直在fullgc，端午三天已经fullgc了19万次多了。。好了，能够找运维小哥哥喝茶去了

结论

线上老年代配置的过小，致使系统一直在fullgc，fullgc的时候STW，阻塞用户线程，通常阻塞时间在100ms左右，致使RT飙升。fullgc后恢复正常，rt恢复，而后再次继续fullgc。

思考

1. 监控平台缺乏对jvm监控

2. 对于请求量大的接口，评估缓存击穿风险

3. 问题排查要结合CPU，内存，IO，JVM多方面同时考虑