蝨孨槑黽凌晨两点半，手机屏幕上跳出第三十四条告警，内容从“CPU使用率超过95%”变成了“主机失联”。我揉着眼睛爬起来，打开笔记本连上跳板机，第一件事不是看监控面板，而是直接敲下 top——这是所有运维遇到“机器卡死”时最本能的动作。如果你也经历过类似的夜晚，或者正在为手头某台CPU飙到100%的服务器发愁，这篇文章就是写给你的。它不会教你背命令，而是把从“发现卡死”到“揪出元凶”再到“止损恢复”的完整排查链路拆开揉碎，让你下次遇到同样问题时，能少走弯路，别在告警风暴里手足无措。
CPU 100%不算罕见，但“卡住了”这三个字背后有太多歧义：是整机完全无响应，还是某个服务请求超时？是用户态进程算满了CPU，还是内核态资源被耗尽？不同的表现对应完全不同的排查方向。下面我按自己惯用的排查顺序，把整个诊断过程一步步展开，每一步做什么、为什么这么做，都交代清楚。
1. 先分清“卡死”的三种真实面貌，再决定要不要冲上去
接到“CPU 100%”的告警后，我从不直接杀进程，而是先花一两分钟确认故障现象。经验告诉我，很多“CPU打满”其实是表象，底层原因差异巨大，动手前没搞清楚状况，可能把小问题搞成大事故。
1.1 整机无响应 vs 单服务卡顿，处理方式完全不同
- 整机完全卡死：鼠标动不了、SSH连不上、ping偶尔通偶尔不通。这种情况通常是CPU资源被完全耗尽，或者内核层面出了问题（比如IO死锁、内存耗尽触发OOM后系统疯狂swap）。处理时要先想办法进系统，进不去就只能通过带外管理（如IPMI、iDRAC）重启，或者用云控制台强制重启，风险最大，要谨慎。
- SSH还能连，但执行命令很慢：这是最常见的“半卡死”状态。
top能打开但刷新很慢，ls都要等好几秒。说明系统还有残余资源在处理你的请求，通常是一个或几个进程把CPU吃满了，系统在“抢”时间片。这种情况是排查的黄金窗口，一定要稳住，别急着敲一堆命令加重负载。 - 单个服务响应超时，但机器整体负载不高：有时候告警来自应用监控（比如Nginx 502、Java接口超时），而登上去看
top发现CPU才20%。这种“假CPU告警”可能是应用线程阻塞、连接池耗尽、锁竞争导致的，CPU只是背锅侠。虽然标题是CPU100%，但实操时也常有这类干扰项，我会顺便提一句，免得你被误导。
1.2 先看 load average，它是“卡死”程度的体温计
登录进系统后，第一件事是 uptime 或 top 左上角的 load average：
code复制load average: 8.41, 6.32, 3.78
这三个数字分别代表1分钟、5分钟、15分钟的平均负载。load average 不等于CPU利用率，它是处于可运行状态和不可中断状态的进程平均数量。如果服务器是4核，load average长期大于4，说明任务排队严重——这就是“卡”的直接原因。
- 1分钟负载 > 5分钟负载 > 15分钟负载：说明负载正在上升，故障正在发生。
- 三个数字都很高且接近：说明系统已经高负载持续了一段时间，需要尽快处理。
- 15分钟负载很高但1分钟降下来了：可能已经在恢复中，可以再观察一会。
判断好负载水平后，下一步才是真正定位进程。我见过不少同事一上来就 kill -9，结果杀错了进程导致业务中断，这就是没分清故障性质的后果。记住：第一步永远是观察，不是动手。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. top 第一屏的信息量，比你想象的更大
很多运维用 top 就直接看进程列表里的CPU列，这没错，但太浪费了。第一屏信息量极大，够挖出很多线索。
2.1 从 top 切换出真正的“CPU大户”进程
进入 top 后，默认按CPU降序排列吗？不一定。有些系统默认按PID排序。所以第一件事是按下键盘 P（大写P），按CPU使用率排序。这时候进程列表顶部基本就是元凶候选者。
观察CPU列的数字：
- 单个进程CPU超过100%（比如显示300%）：说明它在多核并行运行，是个多线程程序，消耗极大。
- 多个进程CPU都是90%-100%：可能是fork了大量子进程的程序，比如PHP-FPM、Java的线程池扩张、或者一个崩溃循环疯狂拉起的worker进程。
- CPU列不高但load很高：说明不是CPU算力不够，而是大量进程在等待IO或锁，这种情况看
wa列和D状态进程。
top里还有个细节容易忽略——%Cpu(s)那一行的 us、sy、wa、st：
us高：用户态程序在跑，通常是业务代码死循环或复杂计算。sy高：内核态消耗过高，可能是系统调用频繁、上下文切换爆炸。wa高：IO等待，CPU其实