关注「Raymond运维」公众号，并设为「星标」，也可以扫描底部二维码加入群聊，第一时间获取最新内容，不再错过精彩内容。

一、概述

1.1 背景介绍

凌晨三点，手机疯狂震动，监控告警显示某台服务器 CPU 使用率飙到 98%。这种场景对于运维来说再熟悉不过了。问题是，很多时候我们手忙脚乱地登上服务器，top 一看全是进程，却不知道从哪下手。更糟糕的是，等领导问起来"到底是什么原因"，我们支支吾吾说不清楚，最后锅就背上了。

这篇文章要解决的就是这个问题：建立一套标准化的 CPU 飙高排查流程，让你在 5 分钟内定位到问题根因，留下完整的证据链，不再稀里糊涂地背锅。

1.2 技术特点

• 快速响应：从告警到定位，控制在 5 分钟内完成初步判断
• 证据留存：每个排查步骤都有对应的数据采集，事后复盘有据可查
• 根因导向：不止于"杀进程"，而是找到真正的问题所在
• 标准化流程：形成 SOP，团队成员都能执行，不依赖个人经验

1.3 适用场景

• 场景一：生产环境突发 CPU 告警，需要快速响应处理
• 场景二：应用上线后出现性能问题，需要定位 CPU 消耗点
• 场景三：周期性 CPU 飙高，需要抓取现场数据用于后续分析
• 场景四：事后复盘，需要完整的故障分析报告

1.4 环境要求

二、详细步骤

2.1 准备工作

2.1.1 工具预装检查

很多人到了现场才发现工具没装，这是大忌。提前把排查工具装好是基本功。

# CentOS/RHEL 系统sudo yum install -y sysstat perf strace htop iotop lsof# Ubuntu/Debian 系统sudo apt install -y sysstat linux-tools-common linux-tools-$(uname -r) strace htop iotop lsof# 验证安装which mpstat pidstat perf strace

2.1.2 建立现场保护意识

处理故障时最重要的原则：先采集，再操作。

# 创建故障现场目录INCIDENT_DIR="/tmp/incident_$(date +%Y%m%d_%H%M%S)"mkdir -p $INCIDENT_DIRcd$INCIDENT_DIR# 记录当前时间戳，后续所有数据都以此为基准echo"故障处理开始时间: $(date '+%Y-%m-%d %H:%M:%S')" > timeline.log

2.2 第一阶段：快速定位（2分钟内完成）

2.2.1 整体态势感知

# 第一眼：看整体负载和 CPU 分布uptime# 输出示例：10:30:01 up 45 days, 3:22, 2 users, load average: 12.53, 8.21, 4.15# load average 三个数字分别是 1分钟、5分钟、15分钟的平均负载# 如果 1分钟 >> 15分钟，说明是刚刚飙起来的# CPU 各核心使用情况mpstat -P ALL 1 3

说明：mpstat 输出中重点关注 %usr（用户态）、%sys（内核态）、%iowait（IO等待）这三列。如果 %usr 高，问题在应用代码；如果 %sys 高，可能是系统调用频繁或内核问题；如果 %iowait 高，其实是 IO 问题伪装成 CPU 问题。

2.2.2 锁定问题进程

# 方法一：top 实时查看（按 P 键按 CPU 排序）top -bn1 -o %CPU | head -20 > $INCIDENT_DIR/top_snapshot.txt# 方法二：ps 一次性快照ps aux --sort=-%cpu | head -20 > $INCIDENT_DIR/ps_snapshot.txt# 方法三：pidstat 持续采样（更准确）pidstat -u 1 10 > $INCIDENT_DIR/pidstat_cpu.txt &

实战经验：top 看到的 CPU% 是瞬时值，有时候会"漏掉"那些短暂飙高的进程。pidstat 持续采样 10 秒取平均值，数据更可靠。

2.2.3 记录进程详情

找到可疑进程后，立刻记录它的详细信息：

# 假设发现 PID 12345 是问题进程PID=12345# 记录进程的完整命令行cat /proc/$PID/cmdline | tr '\0'' ' > $INCIDENT_DIR/proc_cmdline.txt# 记录进程的环境变量（有时候能看出是哪个应用）cat /proc/$PID/environ | tr '\0''\n' > $INCIDENT_DIR/proc_environ.txt# 记录进程打开的文件描述符ls -la /proc/$PID/fd > $INCIDENT_DIR/proc_fd.txt# 记录进程的内存映射（能看出加载了哪些库）cat /proc/$PID/maps > $INCIDENT_DIR/proc_maps.txt

2.3 第二阶段：深入分析（3分钟内完成）

2.3.1 线程级别定位

一个进程里可能有几十个线程，我们需要知道具体是哪个线程在消耗 CPU。

# 查看进程内各线程的 CPU 使用情况top -Hp $PID -bn1 | head -20 > $INCIDENT_DIR/threads_snapshot.txt# 或者用 pidstatpidstat -t -p $PID 1 5 > $INCIDENT_DIR/pidstat_threads.txt

说明：-H 参数让 top 显示线程而不是进程。找到 CPU 最高的那个线程 ID（TID），后面分析堆栈时会用到。

2.3.2 堆栈分析

知道了哪个线程消耗 CPU，下一步是看它在执行什么代码。

# 对于 Java 应用TID=12346  # 假设这是 CPU 最高的线程 IDprintf"%x\n"$TID# 转成十六进制，jstack 用得到# 假设输出 303a# 打印 Java 线程堆栈jstack $PID > $INCIDENT_DIR/jstack.txt# 然后在 jstack.txt 里搜索 nid=0x303a 就能找到这个线程的堆栈# 对于 C/C++/Go 等原生应用pstack $PID > $INCIDENT_DIR/pstack.txt 2>&1# 或者用 gdb（更详细但会短暂暂停进程）gdb -p $PID -batch -ex "thread apply all bt" > $INCIDENT_DIR/gdb_bt.txt 2>&1

2.3.3 系统调用分析

如果堆栈看不出问题，可能是在等待某个系统调用。

# strace 跟踪系统调用（注意：会影响性能，生产环境慎用）timeout 10 strace -c -p $PID > $INCIDENT_DIR/strace_summary.txt 2>&1# 如果需要看具体调用timeout 5 strace -tt -T -p $PID > $INCIDENT_DIR/strace_detail.txt 2>&1

警告：strace 对性能有影响，在生产环境只采集几秒钟就够了，千万别挂着不管。

2.3.4 perf 火焰图采集

perf 是 CPU 性能分析的大杀器，采集数据用于后续生成火焰图。

# 对特定进程采样 30 秒perf record -F 99 -p $PID -g -- sleep 30mv perf.data $INCIDENT_DIR/# 生成报告（文本格式）perf report --stdio > $INCIDENT_DIR/perf_report.txt# 如果安装了 FlameGraph 工具，可以生成火焰图# perf script | stackcollapse-perf.pl | flamegraph.pl > $INCIDENT_DIR/flamegraph.svg

2.4 第三阶段：应急处置

2.4.1 临时降级方案

在找到根因之前，可能需要先控制住局面。

# 方案一：降低进程优先级（让出 CPU 给其他服务）renice 19 -p $PID# 方案二：限制 CPU 使用（需要 cgroups）# 创建一个限制组sudo cgcreate -g cpu:/limit_group# 限制为 50% CPUecho 50000 | sudo tee /sys/fs/cgroup/cpu/limit_group/cpu.cfs_quota_usecho 100000 | sudo tee /sys/fs/cgroup/cpu/limit_group/cpu.cfs_period_us# 把问题进程放进去sudo cgclassify -g cpu:/limit_group $PID# 方案三：最后手段——重启服务（确保已经采集完数据）# systemctl restart xxx

2.4.2 验证处置效果

# 持续观察 CPU 使用情况watch -n 1 "ps -p $PID -o %cpu,cmd"# 或者用 top 盯着看top -p $PID

三、示例代码和配置

3.1 一键采集脚本

3.1.1 CPU 飙高现场采集脚本

#!/bin/bash# CPU高负载故障现场采集脚本# 文件名：cpu_incident_collector.shset -e# 检查是否为 rootif [ "$EUID" -ne 0 ]; thenecho"请使用 root 权限运行此脚本"exit 1fi# 创建采集目录INCIDENT_DIR="/tmp/cpu_incident_$(date +%Y%m%d_%H%M%S)"mkdir -p $INCIDENT_DIRcd$INCIDENT_DIRecho"=== CPU 故障现场采集开始 ===" | tee -a collect.logecho"采集时间: $(date '+%Y-%m-%d %H:%M:%S')" | tee -a collect.logecho"采集目录: $INCIDENT_DIR" | tee -a collect.log# 1. 系统基本信息echo"[1/8] 采集系统基本信息..." | tee -a collect.loguname -a > system_info.txtuptime >> system_info.txtcat /etc/os-release >> system_info.txt 2>/dev/null || cat /etc/redhat-release >> system_info.txt 2>/dev/null# 2. CPU 使用情况echo"[2/8] 采集 CPU 使用情况..." | tee -a collect.logmpstat -P ALL 1 5 > mpstat.txt &vmstat 1 10 > vmstat.txt &# 3. 进程快照echo"[3/8] 采集进程快照..." | tee -a collect.logps auxf > ps_tree.txtps aux --sort=-%cpu | head -50 > ps_cpu_top50.txttop -bn3 > top_3samples.txt# 4. 找出 CPU 最高的进程TOP_PID=$(ps aux --sort=-%cpu | awk 'NR==2{print $2}')echo"CPU 最高的进程 PID: $TOP_PID" | tee -a collect.log# 5. 采集问题进程详情echo"[4/8] 采集问题进程详情 (PID: $TOP_PID)..." | tee -a collect.logif [ -d "/proc/$TOP_PID" ]; then    mkdir -p proc_$TOP_PID    cat /proc/$TOP_PID/cmdline | tr '\0'' ' > proc_$TOP_PID/cmdline.txt    cat /proc/$TOP_PID/status > proc_$TOP_PID/status.txt    cat /proc/$TOP_PID/limits > proc_$TOP_PID/limits.txt    ls -la /proc/$TOP_PID/fd > proc_$TOP_PID/fd_list.txt 2>&1    cat /proc/$TOP_PID/maps > proc_$TOP_PID/maps.txt 2>&1# 线程信息    top -Hp $TOP_PID -bn1 > proc_$TOP_PID/threads.txt# 尝试获取堆栈ifcommand -v pstack &> /dev/null; then        pstack $TOP_PID > proc_$TOP_PID/pstack.txt 2>&1fifi# 6. pidstat 持续采样echo"[5/8] pidstat 持续采样中..." | tee -a collect.logpidstat -u 1 30 > pidstat_cpu.txt &pidstat -r 1 30 > pidstat_mem.txt &pidstat -d 1 30 > pidstat_io.txt &# 7. 网络和 IO 状态echo"[6/8] 采集网络和 IO 状态..." | tee -a collect.lognetstat -tlnp > netstat.txt 2>&1 || ss -tlnp > ss.txtiostat -x 1 5 > iostat.txt &# 8. 内存状态echo"[7/8] 采集内存状态..." | tee -a collect.logfree -h > memory.txtcat /proc/meminfo >> memory.txt# 9. perf 采样（如果可用）echo"[8/8] perf 采样..." | tee -a collect.logifcommand -v perf &> /dev/null; then    perf record -F 99 -p $TOP_PID -g -o perf.data -- sleep 10 2>&1 || echo"perf record failed" >> collect.log    perf report --stdio -i perf.data > perf_report.txt 2>&1 || truefi# 等待后台任务完成wait# 打包echo"=== 采集完成，正在打包 ===" | tee -a collect.logcd /tmptar czf cpu_incident_$(date +%Y%m%d_%H%M%S).tar.gz $(basename $INCIDENT_DIR)echo"采集结果已保存到: /tmp/cpu_incident_*.tar.gz"echo"请将此文件发送给开发人员进行分析"

3.2 实际应用案例

案例一：Java 应用死循环导致 CPU 100%

场景描述：某 Spring Boot 应用突然 CPU 飙到 100%，服务无响应。

排查过程：

# 1. 确认问题进程ps aux --sort=-%cpu | head -5# 输出：# USER  PID %CPU %MEM  COMMAND# app  8421 99.8 12.3  java -jar app.jar# 2. 找出最忙的线程top -Hp 8421 -bn1 | head -10# 输出：# PID   USER  %CPU  COMMAND# 8435  app   98.2  java# 8422  app    0.5  java# 3. 转换线程 IDprintf"%x\n" 8435# 输出：20f3# 4. 获取线程堆栈jstack 8421 > jstack.txt# 5. 搜索对应线程grep -A 30 "nid=0x20f3" jstack.txt

运行结果：