内容简介：营销中心一个新工程上线，工程上线后，监控平台显示RT水位呈规律性上涨下降初次看监控图，认为是redis key批量同时失效导致的，因为波峰的相隔时间正好是15分钟，redis的key失效时间也正好设置了这个时间。同时，当时公司运维反馈给我的，该表的sql请求量较大，15分钟调用了 36530次，占了该库性能的80%.
背景
营销中心一个新工程上线，工程上线后，监控平台显示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多方面同时考虑
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Web Data Mining
Bing Liu / Springer / 2011-6-26 / CAD 61.50
Web mining aims to discover useful information and knowledge from Web hyperlinks, page contents, and usage data. Although Web mining uses many conventional data mining techniques, it is not purely an ......一起来看看 《Web Data Mining》 这本书的介绍吧!
JS 压缩/解压工具
在线压缩/解压 JS 代码
RGB HSV 转换
RGB HSV 互转工具