Linux CPU占用过高排查方法

本文系统讲解了Linux环境下CPU占用过高时的高效排查方法，强调top命令是必须第一时间执行的核心工具，并深入解析%Cpu(s)中us、sy、wa、id等关键指标的业务含义与对应诊断路径；随后分步指导如何从进程到线程精准定位“最烫的点”，结合strace、perf、py-spy、jstack等实用工具进行深度分析，还贴心提供了无perf或权限受限场景下的轻量替代方案；更重要的是，文章点明排查的终极目标不是单纯“杀掉高CPU进程”，而是结合业务逻辑、运行时段和历史基线，科学判断其行为是否真正异常——让运维从“救火队员”升级为“系统医生”。

top 是你第一个该敲的命令，不是“可能有用”，而是必须立刻执行。它能直接告诉你当前谁在吃 CPU、吃的是用户态还是内核态、有没有大量 I/O 等待——这些信息决定了后续排查方向，跳过这步等于蒙眼修车。

怎么看 top 输出里的关键指标

启动后别急着扫进程列表，先盯住顶部那行 %Cpu(s)：us、sy、wa、id 这几个值才是诊断起点。

• us 高（比如 >70%）且 wa 很低 → 问题大概率在你自己跑的程序里，比如 Python 脚本死循环、Java 应用某方法卡住
• wa 高（比如 >20%）而 us 和 sy 都很低 → CPU 其实在干等磁盘，不是真忙，得切到 iostat -x 1 看 %util 和 await
• sy 高（比如 >30%）→ 内核调用太频繁，可能是大量小文件读写、频繁 fork、或驱动异常，用 perf top -g -p 看内核栈
• id 接近 100% 但负载（load average）却很高 → 注意看有没有大量 D 状态进程（不可中断睡眠），这是磁盘卡死的典型信号，ps aux | awk '$8 ~ /D/ {print}' 可快速过滤

定位具体进程和线程的实操顺序

别一上来就 kill -9，先确认是不是真要杀。重点是快速锁定“最烫的那个点”：

• 在 top 里按 P（大写）按 CPU 使用率降序，记下第一行的 PID
• 再执行 top -Hp ，同样按 P，找线程级的“罪魁”——注意列名还是 PID，但这是线程 ID
• 把线程 ID 转成十六进制：printf "%x\n" ，结果用于下一步堆栈匹配
• Java 进程：直接 jstack | grep -A 10 ""，看是不是卡在 HashMap.get 或某个正则匹配上
• C/C++/Go 等原生进程：用 perf record -p -g -- sleep 10 录 10 秒，再 perf report -g 看热点函数

perf 不可用时的替代方案

很多生产环境没装 perf，或者权限受限。这时候别硬等，有更轻量的路径：

• 先试 strace -p -c（加 -c 是统计模式），几秒就能看到最耗时的系统调用，比如全是 epoll_wait 就可能是网络事件堆积，全是 read 就可能是日志刷太猛
• 对 Python 进程，py-spy record -p -o profile.svg（需提前装 py-spy）比 strace 更友好，能直接看到 Python 函数级火焰图
• 如果连 strace 都被禁用，就用 cat /proc//stack（仅限内核支持），看当前线程在内核哪条路径上卡住，常见输出如 [] __do_page_fault+0x2ad/0x4f0 表示缺页异常频繁

真正难的不是找到高 CPU 进程，而是判断“它该不该这么高”。比如一个定时归档脚本在凌晨 2 点把 CPU 拉到 95%，只要持续时间短、不影响业务，可能根本不用动；但同一个脚本白天持续 30 分钟不退，就得查它是不是误读了错误的文件路径导致遍历全盘。这类边界情况，工具给不出答案，得结合业务节奏和历史基线来判断。

本篇关于《Linux CPU占用过高排查方法》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！