线上事故处理记录
线上事故处理记录
一、MySQL 导致的服务器 CPU 飙升
有一天，突然收到了服务器 CPU 飙升的告警信息，打开普罗米修斯查看 CPU 的使用情况，发现 CPU 确实飙升了，下面开始去进行问题定位了。 1. 首先连接到对应的服务器，然后执行
top
查看导致 CPU 飙升的进程是什么，发现是 mysqld 进程导致的
- 进入 MySQL 服务器中，执行下面的命令
show processlist
补充： show processlist 命令的主要用途
- 查看当前有哪些客户端连接
- 查看当前执行的 SQL 语句,能看到慢 SQL、长时间阻塞的查询等
- 排查锁等待、死锁等问题,发现“Locked”的状态，表示线程在等待锁
- 排查连接数过多问题,判断是否有连接未正确释放或连接池配置不当
其实，此时通过查看结果，我基本可以确认是慢 SQL 导致的问题了，但是我还不能那么 100%确认，为了保险起见，我是这么处理的，我先将对应的 SQL 粘出来，然后使用 kill 命令将对应的线程杀死，来判断是不是因为这个查询 sql 导致的 CPU 飙升，结果发现确实 kill 之后，CPU 有所下降，那么说明这个 sql 肯定性能很差，先不说别的，这个 SQL 肯定要先优化一下
- 使用 explain 去分析这个 sql
# 举个例子而已，不是真实的sql，不要较真偶
explain select xxx from table where code='xxx';
发现这个 SQL 没有使用索引，于是我去表中查看了一下表结构，发现确实在 code 这个字段上是没有索引的，于是给这个 code 增加了一个唯一索引，重新 explain 分析这个 SQL，发现效果大大提高
- 正当我认为这个问题被我处理完之后，没想到过了几分钟，又出现问题了，出现了大量请求超时问题，接着分析，发现是开启了慢日志查询，有很多 SQL 超过了设置的慢查询阈值。于是我将慢日志查询关闭，CPU 又有所下降，但是发现还不是特别理想。
- 接下来怎么做呢？我是这么想的，在 MySQL 这层我已经做了优化了，剩下的只能去看代码逻辑了，看看他是如何处理的，然后我就去扒代码，结果发现没有使用缓存，所有的查询都是直接走的 DB，所以我增加了 Redis 缓存层，重新发布后，发现 CPU 确实稳定下来了，也没有再进行飙升。
补充：
在最后再补充一下，有时候 MySQL 层出现问题可能是由于大量的连接导致的，这个时候就要分析为什么有大量的连接同时过来，以及设置一个比较合理的连接数。
本次事故总结： 本次事故是因为没有做好数据库评审，由于开发人员没有建立索引导致慢 SQL 的出现；以及所有查询都走 DB 没有使用缓存层导致 MySQL 压力大。
二、Java 进程导致 CPU 飙升
依然是先收到了 CPU 超载的告警信息，然后去普罗米修斯上看了一下，CPU 一直持续在高负荷，然后我进到对应的服务器中。
-
首先执行 top 命令
top查看导致 CPU 飙升的进程是什么，发现是对应的 Java 进程导致的 CPU 飙升
-
执行
top -Hp PID来查看对应的 Java 进程中的线程的资源占用情况，发现有多个线程 CPU 的利用率达到了 99.9%
-
将堆栈信息导出来
jstack -l 进程ID >/jstack_result.txt
4.堆栈信息导出来了，那么多内容如何快速定位到出现问题的线程代码呢，那么需要将第 2 步得到的线程 PID 转成对应的 16 进制
printf "%xn" PID
然后在堆栈信息中搜索 记得前面可以加一个 0x 开头
这样就可以定位到具体的代码行数了，你就可以去到代码里面看看是什么问题了
在这里我通过定位发现了一直在空循环，所以导致 CPU 飙升。 gggg…
本次问题总结：代码评审没做到位!!!