云服务器CPU跑满怎么排查和解决：从定位到止损的实战指南

云服务器CPU跑满是运维工作中的高频问题，处理不当容易导致业务中断。面对CPU持续飙高，不要急着重启，可以按照以下步骤系统排查和解决。

先确认是真跑满，还是云平台“限频”

登录机器后，先运行 top 命令，重点观察 load average 和 %Cpu(s) 里的 us、sy、wa 值。如果 1 分钟 load 持续高于 CPU 核心数，且 us 很高，大概率是业务进程在消耗算力。但如果发现 cpu MHz 被压得很低，同时云监控里 CPU 积分已经归零，那多半是突发性能实例积分耗尽被限频了。这种情况升级实例规格或开启无性能约束模式，往往比优化代码见效快。

另一个容易误判的是 I/O 等待。在 vmstat 1 5 的输出中，如果 wa 长期超过 30%，而 us 不高，说明瓶颈在磁盘，不应在 CPU 上死磕。

定位具体进程和线程

确认是用户态 CPU 高之后，在 top 中按 P 键排序找到占用最高的 PID。如果是 Java、Nginx 等多线程应用，单看进程级不够，需用 top -H -p 查看线程。找到耗 CPU 的线程 ID 后，转换为十六进制，再用 jstack 抓取栈信息定位到具体方法。

有些进程生命周期短，top 可能抓不到。这时可用 pidstat -u 1 做一秒间隔采样，或使用 atop 查看历史记录。如果是容器环境，先用 docker stats 圈定异常容器，再进入容器内部排查，避免在宿主机上盲目翻找。

sy 内核态高怎么办

当 top 中的 sy 超过 20% 时，需怀疑内核态问题。最常见的是软中断，可通过 /proc/softirqs 查看 NET_RX 是否在疯涨。如果是，检查网卡多队列是否压在单个核上，通过 ethtool -L 调整队列数，并使用 irqbalance 或手动绑核分散压力。

若软中断不高，可用 perf top -g 扫描内核热点，排查是否卡在文件系统、iptables 规则过多或某个内核模块上。perf 抓出的热点函数通常能提供明确的排查方向。

紧急止血与保留现场

如果业务已受影响，应先止损再排查。不建议直接 kill -9，可使用 kill -STOP 挂起可疑进程，保留现场方便后续分析。同时用 renice 提升核心服务的优先级，争取恢复部分流量。

若是外部流量激增导致，可通过 iptables 临时限流或应用层降级争取时间。事后使用 sar 导出 /var/log/sa/ 中的数据存档，结合监控做复盘。建议为关键服务配置 cgroup 的 CPU 配额限制，防止单个容器或进程再次拖垮整机。