CPU告警时先看整体负载和进程分布，用uptime或top判断是否真过载，再用top+pidstat定位高CPU进程及用户态/内核态占比，最后用perf、pstack等深入线程与调用栈分析，并排查资源争用与系统配置干扰。
CPU告警时先看整体负载和进程分布
收到CPU使用率高告警，不要直接杀进程。先用 uptime 或 top 看系统平均负载（Load Average），对比 CPU 核心数判断是否真过载。比如 4 核机器，load > 4 持续几分钟才需关注；若 load 正常但 top 显示单个进程占满一个核，可能是局部热点，不等于系统卡死。
定位高 CPU 进程：top + pidstat 组合排查
top -c 查看实时占用最高的进程（按 P 排序），记下 PID；再用 pidstat -u -p PID 1 5 观察该进程每秒的 CPU 使用波动，确认是否持续异常。注意区分是用户态（%usr）还是内核态（%sys）占比高：
- %usr 高：代码逻辑问题，如死循环、频繁计算、正则回溯
- %sys 高：可能在做大量系统调用，如频繁 open/read/write、锁竞争、上下文切换过多
- 若 %wait 高（需加 -w 参数），说明进程在等 I/O，实际不是 CPU 问题，告警可能误报
深入线程与调用栈：perf 和 pstack 辅助分析
对高 CPU 的进程进一步下钻：
- 用 ps -T -p PID 查看其线程列表，再用 top -H -p PID 找出具体哪个线程吃 CPU
- 用 perf top -p PID（需安装 perf）看热点函数，快速识别是 Java 的 GC 线程、Python 的 GIL 争抢，还是 C/C++ 的某个计算函数
- Java 进程可补打 jstack PID > jstack.log；Python 可用 py-spy record -p PID -o profile.svg 抓取调用栈
检查资源争用与系统配置干扰
有些“高 CPU”本质是资源错配或配置问题：
- 确认没有其他进程被 OOM Killer 杀掉后残留子进程反复重启（查 dmesg -T | grep -i "killed process"）
- 检查定时任务（crontab -l）、systemd 服务（systemctl list-timers --all）是否在告警时段密集触发
- 虚拟化环境注意 CPU 节流（cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us），云主机要核对实例规格是否被限频
- 某些驱动或内核模块（如旧版 nvidia 驱动、特定网卡驱动）会导致 sys CPU 异常飙升，更新内核或驱动常可缓解
