CPU狂飙900%如何分析？怎么定位？怎么溯源处理01 场景1：MySQL进程飙升900% 评估：大家在使用MySQL

01
场景1：MySQL进程飙升900%

评估：

大家在使用MySQL过程，想必都有遇到过CPU突然过高，或者达到200%以上的情况。

数据库执行查询或数据修改操作时，系统需要消耗大量的CPU资源维护从存储系统、内存数据中的一致性。

并发量大并且大量SQL性能低的情况下，比如字段是没有建立索引，则会导致快速CPU飙升，如果还开启了慢日志记录，会导致性能更加恶化。生产上有MYSQL 飙升900% 的恶劣情况。

定位：

使用top 命令观察，确定是mysqld导致还是其他原因。
如果是mysqld导致的，show processlist，查看session情况，确定是不是有消耗资源的sql在运行。
找出消耗高的 sql，看看执行计划是否准确， index 是否缺失，或者实在是数据量太大造成。

处理：

kill 掉这些线程(同时观察 cpu 使用率是否下降)

一般来说，肯定要 kill 掉这些线程(同时观察 cpu 使用率是否下降)，等进行相应的调整(比如说加索引、改 sql、改内存参数)之后，再重新跑这些 SQL。

进行相应的调整(比如说加索引、改 sql、改内存参数)

index 是否缺失，如果是则建立索引。也有可能是每个 sql 消耗资源并不多，但是突然之间，有大量的 session 连进来导致 cpu 飙升，这种情况就需要跟应用一起来分析为何连接数会激增，再做出相应的调整，比如说限制连接数等；

优化的过程，往往不是一步完成的，而是一步一步，执行一项优化措辞，再观察，再优化。分析当前的数据量、索引情况、缓存使用情况。目测数据量不大，也就几百万条而已。接下来就去定位索引、缓存问题。

经过询问，发现很多查询都是走MySQL，没有用到缓存。

既然没有用到缓存，则是大量请求全部查询MySQL导致。通过下面的命令查看:

发现类似很多相同的SQL语句，一直处于query状态中。

初步分析可能是 user_code 字段没有索引导致。接着查询user表的索引情况：

发现这个字段是没有建立索引。增加索引之后，该条SQL查询能够正常执行。

没隔一会，又发生大量的请求超时问题。接着进行分析，发现是开启了慢日志查询。大量的SQL查询语句超过慢日志设置的阀值，于是将慢日志关闭之后，速度瞬间提升。CPU的使用率基本保持在300%左右。但还不是理想状态。

紧接着将部分实时查询数据的SQL语句，都通过缓存(redis)读写实现。观察一段时间后，基本维持在了70%~80%。

总结：

其实本次事故的解决很简单，就是添加索引与缓存结合使用。

不推荐在这种CPU使用过高的情况下进行慢日志的开启。因为大量的请求，如果真是慢日志问题会发生日志磁盘写入，性能贼低。

直接通过MySQL show processlist命令查看，基本能清晰的定位出部分查询问题严重的SQL语句，在针对该SQL语句进行分析。一般可能就是索引、锁、查询大量字段、大表等问题导致。

再则一定要使用缓存系统，降低对MySQL的查询频次。

对于内存调优，也是一种解决方案。

02
场景2：Java进程飙升900%

一般来说Java 进程不做大量 CPU 运算，正常情况下，CPU 应该在 100~200% 之间，但是，一旦高并发场景，要么走到了死循环，要么就是在做大量的 GC, 容易出现这种 CPU 飙升的情况，CPU飙升900%，是完全有可能的。