在IDC运维日常工作中，CPU负载告警是最常见的问题之一。面对top命令里飙升的%us和%sy，新手运维往往不知所措。本文分享一套标准化的CPU排查流程，帮你快速定位根因。

第一步：快速确认负载来源

登录服务器后，先用top命令按P排序，查看CPU占用最高的进程。注意区分：

  • %us高：用户态进程占用，通常是应用程序bug、死循环或业务量突增
  • %sy高：内核态占用，大概率是上下文切换过多、IO等待或系统调用异常
  • %wa高：IO等待，这时候CPU其实在等磁盘，不是真的忙

如果看到某个Java进程占了200%CPU，别急着kill——先用jstack <pid>抓线程栈，看是不是GC频繁或者线程死锁。

第二步：深挖进程细节

找到可疑进程后，用ps -Lfp <pid>看线程级CPU占用，找到最忙的线程ID。再用strace -p <pid> -c统计系统调用耗时，看是哪个syscall拖慢了系统。

对于Web服务器，建议配合netstat -an | grep :80 | wc -l看连接数，有时候是CC攻击导致的请求风暴。这时候不要只盯着CPU，先看网络连接和访问日志。

第三步：优化建议

CPU优化不是一味地加核数。我们在IDC实践中总结了几条经验：

  1. 把CPU绑定到特定NUMA节点，避免跨节点内存访问延迟
  2. 调整进程nice值，让核心业务进程优先获得CPU资源
  3. 禁用不必要的内核调试和审计功能
  4. 定期清理僵尸进程和孤儿进程，用ps -ef | grep defunct检查

最后提醒：CPU负载100%不一定是坏事——只要业务响应正常，说明CPU资源被充分利用了。真正需要告警的是持续高负载伴随响应超时，这才是真的有问题。