凌晨三点，监控告警：CPU使用率100%。你登录服务器，top一看，有个进程占满了CPU，但你不认识它。或者更糟——你认识，但不知道为什么突然飙了。
别慌。CPU 100%不是绝症，是症状。今天给你一套排查流程，5步定位元凶，让你从“懵了”到“我知道怎么回事”。
先看一个数据
某云厂商统计，超过40%的“服务器卡顿”投诉，根源是某个进程的CPU异常飙升，而非硬件故障。这些异常里，有一半是代码问题（死循环、SQL没索引），三成是被攻击（挖矿、CC），两成是正常业务高峰。
也就是说，大部分CPU飙高，你都能自己查出来。
第一步：用top看是谁在吃CPU
登录服务器，执行：
bash
top
按P（大写），让进程按CPU使用率排序。看看排第一的是谁。
看什么：
- 进程名：是正常服务（nginx、php-fpm、mysqld），还是陌生名字（xmr、[kworker]伪装）？
- CPU使用率：是持续100%还是一阵一阵？
- 用户：是root还是www-data还是别的？
记住这个进程的PID，后面要用。
反常识点：有些挖矿病毒会把自己伪装成系统进程，比如叫[kworker]或[httpd]。如果你看到陌生的进程名，或者在/tmp、/var/tmp目录下运行的进程，大概率中招了。
第二步：看是不是挖矿病毒
挖矿病毒有几个典型特征：
- CPU持续100%
- 进程名随机或者冒充系统进程
- 执行文件在临时目录（/tmp、/var/tmp、/dev/shm）
- 连接外部矿池IP（端口通常是4444、5555、7777、8080）
验证方法：
bash
# 找到PID后，看进程的执行文件位置 ls -l /proc/PID/exe
如果路径在/tmp下，或者显示“deleted”（表示文件被删了但进程还在跑），基本就是恶意程序。再看进程的网络连接：
bash
netstat -tunp | grep PID
如果看到连接到陌生IP，尤其是常用矿池端口，确认了。
处理：kill进程 → 删文件 → 清理定时任务 → 改密码。如果清不干净，重装系统是最稳的。
第三步：看是不是正常服务异常
如果吃CPU的是你自己的服务（比如php-fpm、mysqld、nginx），需要进一步定位。用top按1看每个核心的使用情况，用htop更直观。
PHP-FPM异常：
bash
# 看PHP-FPM进程数 ps aux | grep php-fpm | wc -l
如果进程数超过配置的pm.max_children，说明请求太多。看具体是哪个脚本在消耗资源：
bash
# 记录当前请求的慢日志 grep "execution time" /var/log/php-fpm/slow.log
或者在php.ini里开启request_slowlog_timeout = 5，把执行超过5秒的请求记下来。
MySQL异常：
bash
# 查看当前运行的SQL mysql -e "SHOW PROCESSLIST;"
如果看到大量Copying to tmp table或Sending data状态的查询，说明SQL效率低，需要加索引或优化语句。
反常识点：很多人一看到MySQL CPU高就重启。但重启只是临时缓解，问题很快会回来。查慢查询日志，加索引，才是根治。
第四步：看是不是系统问题（软中断、内存交换）
某些情况下，CPU高但top里找不到明显耗CPU的进程，因为问题出在内核层面。
软中断过高：网络流量太大时，软中断处理会占用大量CPU。查看方法：
bash
# 看软中断CPU使用率 top # 按1看每个核心，si列是软中断
或者用mpstat -P ALL 1看更详细的数据。如果软中断高，说明网卡流量过大，可能是被攻击或业务流量激增。
内存交换导致CPU高：当内存不足时，内核会频繁地把数据换出到磁盘，这个过程消耗CPU。查看：
bash
# 看内存和swap使用 free -h # 看swap in/out频率 vmstat 1
如果si和so列持续大于0，说明内存不够，系统在频繁交换数据，CPU被拖慢。解决方案：加内存，或者优化应用减少内存占用。
第五步：看是不是正常业务高峰
如果前面都排除了，CPU高可能是正常业务增长。
验证方法：
bash
# 看nginx访问日志，统计请求量 tail -100 /var/log/nginx/access.log | wc -l
对比昨天、上周同一时段的数据。如果确实涨了，说明业务在发展，是好消息。但需要应对：加服务器、上负载均衡、优化代码。
反常识点：业务增长导致CPU增加，说明你的优化速度没赶上增长速度。这时候该考虑架构升级，而不是责怪服务器。
一个真实案例
有个电商网站，下午3点CPU突然飙到100%，持续半小时后自动恢复。每天如此。
用top看到是MySQL进程高。看SHOW PROCESSLIST，发现下午3点准时有一个统计报表在跑，SQL没有索引，全表扫描。
优化方案：给统计SQL加索引，执行时间从30秒降到0.2秒。CPU恢复正常。老板问：“你做了什么？”他说：“加了一个索引。”
最后一句
CPU 100%并不可怕。可怕的是你不知道怎么查，只能重启。
重启治标不治本。按这5步走，找到元凶，解决它。
下次你收到CPU告警，先别慌。打开终端，从第一步开始。
你的服务器不是随便发脾气的。它在告诉你，哪里需要你的关注。