云服务器 CPU 被打满？从 top 到进程溯源的排查顺序

云服务器突然变卡，top 里 CPU 长期接近 100%，业务延迟飙升，最常见的反应是“是不是被打了”或“是不是程序写炸了”。多数时候两者都可能，但先别重启。按下面顺序走，能在几分钟内把“谁在吃 CPU、为什么吃”说清楚。命令在 EulerOS、CentOS、Ubuntu 上都适用。

一、先确认是整机打满，还是个别核打满

# 整体负载与 1/5/15 分钟平均
uptime

# 按核看利用率（按 1 看几秒）
mpstat -P ALL 1 5

• load average 远高于 CPU 核数，且 mpstat 多数核 %usr/%sys 都高：整机计算忙。
• 只有一两个核打满：更像单线程热点、某个 worker、或中断绑核问题。
• %iowait 很高而 %usr 不高：瓶颈在磁盘/网络 IO，不是纯 CPU，后面别只盯进程。

同时看一眼内存，避免把 swap 颠簸误当成 CPU 问题：

free -h
vmstat 1 5

si/so 持续不为 0，说明在换页，先处理内存再谈 CPU。

二、用 top / pidstat 锁定进程

top -c
# 或更干净：
pidstat -u 1 5

在 top 里按 P 按 CPU 排序，记下：

1. PID / 命令行（-c 显示完整命令）
2. 用户
3. %CPU 是否接近或超过 100（多线程可超过单核）

对可疑 PID 再拆线程：

top -H -p <PID>
# 或
ps -L -p <PID> -o pid,tid,pcpu,comm

若某个线程独占一核，再结合程序日志或 pstack/gdb 看卡在哪（生产环境慎用 gdb，优先日志与采样）。

三、区分“业务本身忙”和“异常进程”

常见几类：

对外连快速摸底（只看、不乱杀）：

ss -antp | head
# 若允许且已安装：
# nethogs 或 iftop 观察瞬时流量

四、采样比“猜”更省时间

对用户态热点，可用短时采样（需安装 perf，且内核允许）：

# 示例：采 10 秒，看热点符号（容器/精简镜像可能缺符号）
sudo perf top -p <PID>

没有 perf 时，至少保留：

• ps -efww 完整命令行
• 应用最近错误日志
• dmesg -T | tail 是否有 OOM、硬件错误

五、处理原则（避免越修越糟）

1. 先限流/摘流，再杀进程。 直接 kill -9 可能丢数据；对业务进程优先优雅重启或缩容异常实例。
2. 挖矿或不明进程： 记下文件路径与启动方式（systemd、crontab、~/.bashrc），清理持久化后再判断是否重装。
3. 确认是容量问题： 垂直升配只是缓兵之计，配合水平扩展与缓存/异步化更稳。
4. 改完再验证： 用同一组 mpstat/pidstat 对比，确认 %CPU 与延迟都下来，而不是只看瞬间。

六、可放进巡检的三条

# 1) 是否有持续高 CPU 进程
pidstat -u 1 3 | awk '$8+0 > 50 {print}'

# 2) 负载是否长期压过核数
# 结合 nproc 与 uptime

# 3) 是否在疯狂换页
vmstat 1 3

把这三条塞进监控告警（CPU > 80% 持续 5 分钟、load > 核数×1.5、swap 增长），比出事后再 SSH 上去瞎猜可靠得多。

CPU 打满不是结论，只是起点。先分清整机还是单核、用户态还是 IO，再锁定 PID 与线程，最后才决定限流、扩容还是清异常进程。按这个顺序，大多数“机器卡死”都能在一两次登录里定位到可执行的下一步。