一次生产CPU100%问题排查

Posted 2020-11-28 caiyao

现象：

CPU 100%

tomcat处理线程数升高

数据库访问次数升高

接口响应时间边长

 

结论：

Redis挂掉，缓存穿透

 

分析：

Redis挂掉，所有请求打到DB，所以DB访问量增加

由于每个请求都访问DB，所以接口响应时间边长

由于接口响应时间边长，所以tomcat创建更多线程来处理请求

由于大量请求堆积在服务端，且都需要请求DB重新组织数据，导致CPU100%，这个还需要再验证下，可以把Redis缓存关掉，看下CPU指标表现。

 

排查过程：

如果系统出现突然指标异常，肯定是有触发条件的，要么是外部，要么是内部，外部有两种可能： 1. 访问量升高。 2. 特定的访问参数触发了比较重的代码流程。 内部就是定时任务，定时任务外部存在的两种情况。

在遇到上面的问题时，先检查了没有定时任务在异常点触发，所以排除内部原因，然后观察应用所有接口访问量，在 异常点也没有升高，所以断定是异常点某个请求参数导致的资源耗尽，以至于其他请求得不到处理，于是开始翻异常点前后5分钟的日志看有没有一些线索，但是无果，由于应用请求量比较大，所以直接翻日志属于碰运气，极大可能找不到想要的答案，最后接到框架部门反馈，Redis在异常时间点有异常，导致get时Redis返回空，所以一切都可以解释了。

在这次排障过程中还有个问题，就是系统异常是非常短暂的，所以当发现问题的时候已经没有了现场，特别是线程栈，如果有线程栈可能还可以提供一些有效的参考。

 

思考：

1. 系统日志非常重要，日志是排障非常重要的工具。

如果设计一个高可用的日志系统？

业务系统如何选择记录的日志内容，和日志级别？

2. 当出现系统DB访问量突升，而且应用有使用缓存，可以首先想到是不是缓存穿透

3. 系统压力测试非常有必要，特别是没有缓存的场景

4. 有没有方法能让系统异常的时候自动记录一些必要的排障现场，比如线程栈？