CPU 飙高三命令排查法

三命令组合拳，解决 90% 的 CPU 飙高问题。 案例：Python 进程持续占用 4.7% CPU（2 核虚拟机），根因是 DEBUG 级别日志疯狂写入。

排查流程

第 1 条命令：top — 找到可疑进程

top
# 按 %CPU 排序（默认），找到 CPU 占用最高的 PID
# PID 5621  python  4.7% CPU

能回答的问题： 谁在抢 CPU？

第 2 条命令：strace -c -p PID — 看它在做什么系统调用

strace -p 5621 -c
# 跑几秒后 Ctrl+C 停止，得到系统调用分布统计

# 输出示例：
# % time  seconds  usecs/call  calls  errors  syscall
# 47.66  0.076658       34     2230          stat
# 44.86  0.072144       32     2230          write
#  7.48  0.012028       53      223          select

能回答的问题： 它在做什么类型的操作？（write → 写数据 / stat → 检查文件状态）

strace 直接跟踪系统级调用。-c 参数做统计汇总而非逐条输出，开销可控，适合线上快速诊断。不要在生产环境用 -f（跟踪子进程），大量 fork 场景下 strace 本身会加剧负载。

第 3 条命令：ls -l /proc/PID/fd/ — 看它在操作什么文件

ls -l /proc/5621/fd/
# 输出：
# l-wx---. 1 root root 64 ... 3 -> /tmp/bad_app.log

能回答的问题： 它在读写什么文件？

/proc/PID/fd/ 目录记录了进程打开的所有文件描述符。箭头右侧即实际文件路径。

三命令排查法速查表

案例复盘

问题： 刚启动的 Python 进程持续占用 4.7% CPU（2 核虚拟机）。

排查链路：

top → PID 5621 (python)
  → strace -p 5621 -c → 2230 次 write + 2230 次 stat
    → ls -l /proc/5621/fd/ → /tmp/bad_app.log (23MB, 运行几分钟)

根因： 程序日志级别设置为 DEBUG，且在每次写入前调用 stat 检查文件状态（日志轮转配置不当导致反复 stat）。

解决：

kill 5621
# 修改日志配置：DEBUG → WARNING
# 或添加 logrotate 日志轮转

适用场景

这套组合拳适用于以下场景的快速定位：

• 应用进程 CPU 占用异常但原因不明
• 怀疑是日志/IO 导致的 CPU 飙高
• 需要快速判断进程行为（写文件 / 网络请求 / 死循环）

对于更复杂的 CPU 性能问题（死循环、锁竞争、GC 频繁等），配合 server-performance-four-dimensions 中的 pidstat、top -Hp、jstack 等工具做深度分析。

关联页面

• java-cpu-100-case-study — Java 应用 CPU 100% 排查案例（jstack + HashMap 死链 + Full GC）