一次生产CPU100%问题排查
现象:
CPU 100%
tomcat处理线程数升高
数据库访问次数升高
接口响应时间边长
结论:
Redis挂掉,缓存穿透
分析:
Redis挂掉,所有请求打到DB,所以DB访问量增加
由于每个请求都访问DB,所以接口响应时间边长
由于接口响应时间边长,所以tomcat创建更多线程来处理请求
由于大量请求堆积在服务端,且都需要请求DB重新组织数据,导致CPU100%,这个还需要再验证下,可以把Redis缓存关掉,看下CPU指标表现。
排查过程:
如果系统出现突然指标异常,肯定是有触发条件的,要么是外部,要么是内部,外部有两种可能: 1. 访问量升高。 2. 特定的访问参数触发了比较重的代码流程。 内部就是定时任务,定时任务外部存在的两种情况。
在遇到上面的问题时,先检查了没有定时任务在异常点触发,所以排除内部原因,然后观察应用所有接口访问量,在 异常点也没有升高,所以断定是异常点某个请求参数导致的资源耗尽,以至于其他请求得不到处理,于是开始翻异常点前后5分钟的日志看有没有一些线索,但是无果,由于应用请求量比较大,所以直接翻日志属于碰运气,极大可能找不到想要的答案,最后接到框架部门反馈,Redis在异常时间点有异常,导致get时Redis返回空,所以一切都可以解释了。
在这次排障过程中还有个问题,就是系统异常是非常短暂的,所以当发现问题的时候已经没有了现场,特别是线程栈,如果有线程栈可能还可以提供一些有效的参考。
思考:
1. 系统日志非常重要,日志是排障非常重要的工具。
如果设计一个高可用的日志系统?
业务系统如何选择记录的日志内容,和日志级别?
2. 当出现系统DB访问量突升,而且应用有使用缓存,可以首先想到是不是缓存穿透
3. 系统压力测试非常有必要,特别是没有缓存的场景
4. 有没有方法能让系统异常的时候自动记录一些必要的排障现场,比如线程栈?