Linux SRE 运维手册：系统性解决高 CPU 占用问题

场景

在生产环境中，高 CPU 占用是常见的严重问题，可能导致应用延迟和服务降级。作为 SRE，需要系统性地诊断和缓解 CPU 高峰，避免造成更大的中断。本手册涵盖了在 Linux 服务器上排查高 CPU 占用的关键步骤。

症状

• 监控告警：CPU 利用率超过阈值（例如 5 分钟内持续 >90%）。
• 用户反馈：应用响应时间增加，用户遇到超时。
• 系统指标：top 或 htop 中 %idle 很低，负载平均值超过 CPU 核心数，进程列表显示高 CPU 消耗。

诊断

1. 找出 CPU 消耗最高的进程：运行 ps aux --sort=-%cpu | head -20 列出按 CPU 排序的进程。记录 PID、%CPU 和命令。
2. 检查系统级 CPU 分解：使用 mpstat -P ALL 1 3 查看每个核心的利用率，找出是否有一个核心被独占（例如由于内核或中断处理）。
3. 区分用户态与内核态时间：vmstat 1 5 显示 us（用户）和 sy（系统）列。sy 高表示内核级活动（系统调用、中断）。
4. 检查 I/O 等待：vmstat 中的 wa 高或 iostat -x 1 表示 CPU 在等待 I/O。这可能伪装成 CPU 饱和。
5. 查看线程级细节：对于特定 PID，top -H -p <PID> 或 ps -Lp <PID> -o pid,tid,%cpu,comm 揭示导致问题的线程。
6. 追踪系统调用（高级）：使用 strace -c -p <PID> 查看系统调用计数，但仅在有权限且影响最小时使用。更好的方法是使用 perf top -p <PID> 进行采样。

命令（附安全注意事项）

# 安全：列出最耗 CPU 的进程，不修改状态
ps aux --sort=-%cpu | head -20

# 安全的定期监控（低侵入性）
top -b -d 5 -n 10

# 每个核心的 CPU 分解（安全）
mpstat -P ALL 1 3

# 检查进程创建爆发（如果可用，使用 perf-tools 中的 execsnoop）
execsnoop -T

# 降低特定进程的 CPU 影响（谨慎使用）：
# 降低优先级：
renice +10 -p <PID>
# 注意：对于计算密集型进程，renice 可能不会显著影响 CPU 占用。

# 仅在确认进程非关键且获得批准后杀死进程：
# kill -9 <PID>   # 除非绝对必要，否则避免

# 如果怀疑 Java/Python 有无限循环，生成线程转储：
# kill -3 <PID>   # 向 JVM 发送 SIGQUIT

风险控制

• 杀死前确认：使用 systemctl status <service> 或查看监控仪表板了解进程角色。
• 记录操作：记录每个命令和观察结果，用于事后分析。
• 避免在生产环境使用 strace/perf，除非团队明确批准且使用低开销工具（例如 perf record -F 99 -p <PID> -g -- sleep 10 短时间安全）。
• 设置 CPU 告警，以便提前应对模式。

回滚

• 如果杀死了关键进程，立即重启：systemctl start <service>。
• 如果更改了优先级，恢复默认：renice 0 -p <PID>。
• 如果应用了临时配置更改，恢复原状。

验证

• 缓解后，使用 top 或常用工具监控 CPU 5-10 分钟。
• 检查应用健康端点（例如 /healthz）。
• 确保负载平均值降至 CPU 核心数以下。
• 确认其他指标（内存、磁盘 I/O）未受影响。

何时提交 OpsGlobal 工单

• 应用基本缓解措施（renice、重启）后 CPU 仍然高。
• 根本原因不明确（例如内核错误、硬件中断风暴）。
• 问题需要代码分析或更改应用逻辑。
• 需要具备更深 Linux 内核知识或供应商支持的 SRE。

OpsGlobal 提供 24/7 远程 SRE 支持，帮助诊断和解决复杂生产问题，确保团队保持高可用性。