CPU狂飙900%如何分析？怎么定位？怎么溯源处理

当你的服务器CPU飙升到900%，系统卡顿、响应迟缓、业务受阻，这种令人焦虑的场景是否让你束手无策？别慌，这并不是世界末日，只要掌握正确的分析与定位方法，就能快速找到问题根源，并有效解决。

CPU 飙升到 900%，到底是哪些因素导致？如何快速定位问题并溯源处理？

分析 CPU 飙升的常见原因

CPU 使用率异常高的情况，通常可以归因于以下几类问题：

代码问题： 死循环、大量的计算密集型任务或低效算法。
流量暴增： 高并发请求导致系统资源耗尽。
数据库瓶颈： SQL 查询未优化，导致数据库CPU占用高。
外部依赖问题： 消息队列、第三方接口阻塞。
恶意攻击： DDoS 攻击或者僵尸进程。

案例：
某电商平台在促销活动期间，用户访问量激增，导致多个服务的CPU飙升。排查发现，问题是由于缓存穿透，导致大量请求直接打到数据库，引发资源争夺。

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的查询频次。

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