线上事故处理记录

一、MySQL 导致的服务器 CPU 飙升

有一天，突然收到了服务器 CPU 飙升的告警信息，打开普罗米修斯查看 CPU 的使用情况，发现 CPU 确实飙升了，下面开始去进行问题定位了。 1. 首先连接到对应的服务器，然后执行

sh 复制代码

top

查看导致 CPU 飙升的进程是什么，发现是 mysqld 进程导致的

进入 MySQL 服务器中，执行下面的命令

sh 复制代码

show processlist

补充： show processlist 命令的主要用途

查看当前有哪些客户端连接

查看当前执行的 SQL 语句,能看到慢 SQL、长时间阻塞的查询等

排查锁等待、死锁等问题,发现"Locked"的状态，表示线程在等待锁

排查连接数过多问题,判断是否有连接未正确释放或连接池配置不当

其实，此时通过查看结果，我基本可以确认是慢 SQL 导致的问题了，但是我还不能那么 100%确认，为了保险起见，我是这么处理的，我先将对应的 SQL 粘出来，然后使用 kill 命令将对应的线程杀死，来判断是不是因为这个查询 sql 导致的 CPU 飙升，结果发现确实 kill 之后，CPU 有所下降，那么说明这个 sql 肯定性能很差，先不说别的，这个 SQL 肯定要先优化一下

使用 explain 去分析这个 sql

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 命令
sh 复制代码
```
top
```
查看导致 CPU 飙升的进程是什么，发现是对应的 Java 进程导致的 CPU 飙升
执行
sh 复制代码
```
top -Hp PID
```
来查看对应的 Java 进程中的线程的资源占用情况，发现有多个线程 CPU 的利用率达到了 99.9%
将堆栈信息导出来
sh 复制代码
```
jstack -l 进程ID >/jstack_result.txt
```

4.堆栈信息导出来了，那么多内容如何快速定位到出现问题的线程代码呢，那么需要将第 2 步得到的线程 PID 转成对应的 16 进制

bash 复制代码

printf "%xn" PID

然后在堆栈信息中搜索记得前面可以加一个 0x 开头

这样就可以定位到具体的代码行数了，你就可以去到代码里面看看是什么问题了

在这里我通过定位发现了一直在空循环，所以导致 CPU 飙升。 gggg...

本次问题总结：代码评审没做到位!!!