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