交付说明（≤200字）

本 Checklist 覆盖 CPU / 内存 / 磁盘 IO / 网络四大类共 16 条排查项（每类 4 条），每条含可复制命令、明确阈值与一句话归因。附带一个「Go 服务间歇性 504 超时」的完整案例复盘（现象→排查→根因→修复），末尾附文字版快速决策树。命令均基于 top/vmstat/iostat/ss/free/ps/uptime 等标准工具，无需额外安装。适用于 CentOS 7 / Ubuntu 20.04 传统 Linux 环境，Java/Go 业务通用。

Linux 生产环境性能瓶颈排查 Checklist

适用环境：CentOS 7 / Ubuntu 20.04，Java / Go 业务进程
原则：先全局后局部，先硬件后软件，先资源后逻辑。

一、CPU 瓶颈

| # | 排查项 | 命令 | 判定阈值 | 一句话说明 | |---|--------|------|----------|------------| | 1 | 整体 CPU 使用率 | top -bn1 \| head -5 或 uptime | %usr + %sys > 85% 持续 ≥ 2 min | 进程计算密集或系统调用风暴（上下文切换过多） | | 2 | 单核打满 | top -H -p <pid> 或 pidstat -t -p <pid> 1 5 | 某线程 %CPU > 95% 持续 ≥ 1 min | 单线程热点（死循环、锁竞争、GC 单核） | | 3 | 上下文切换频率 | vmstat 1 5 看 cs 列；或 pidstat -w -p <pid> 1 5 | cs > 50,000/s（全机）或 cs > 5,000/s（单进程） | 线程过多或频繁 futex/锁竞争，CPU 大量耗在切换而非计算 | | 4 | 软中断偏高 | mpstat -P ALL 1 3 看 %soft | %soft > 30% 持续 ≥ 1 min | 网络包处理或中断分发不均，可能需调 affinity / IRQ 均衡 |

快速操作：

# 一条命令看 CPU 全貌
top -bn1 | grep -E "Cpu|load"

# 定位到具体线程
pidstat -t -p <PID> 1 5

# 看中断分布
mpstat -P ALL 1 3

二、内存瓶颈

| # | 排查项 | 命令 | 判定阈值 | 一句话说明 | |---|--------|------|----------|------------| | 1 | 可用内存不足 | free -h | available < 总内存 10% | 进程堆外/文件缓存挤压，即将触发 OOM 或大量 swap | | 2 | Swap 使用 | vmstat 1 5 看 si / so；swapon --show | si > 0 或 so > 0 持续 ≥ 30 s | 热数据被换出，页面缺页导致服务毛刺（Java 尤其敏感） | | 3 | 内存泄漏趋势 | ps -o pid,rss,vsz,comm -p <pid> 每 5 min 采样；或 cat /proc/<pid>/smaps \| grep -E "Rss|Anon" \| awk '{s+=$2}END{print s/1024 " MB"}' | RSS 5 min 内增长 > 50 MB 且不回落 | 堆外泄漏（DirectByteBuffer）或连接未释放，最终 OOM Kill | | 4 | Page Cache 污染 | cat /proc/meminfo \| grep -E "Cached|Buffers|Dirty" | Dirty > 可用内存 20% | 大量脏页等待回写，IO 突发时延迟飙升（写密集场景） |

快速操作：

# 内存全局
free -h && vmstat 1 5

# 单进程内存
ps -o pid,rss,vsz,comm -p <PID>

# 看 OOM 记录
dmesg -T | grep -i "oom\|kill" | tail -20

三、磁盘 IO 瓶颈

| # | 排查项 | 命令 | 判定阈值 | 一句话说明 | |---|--------|------|----------|------------| | 1 | 设备利用率 | iostat -x 1 5 看 %util | %util > 80% 持续 ≥ 1 min | 磁盘带宽或队列打满，后续请求排队等待 | | 2 | IO 等待 | vmstat 1 5 看 %iowait；iostat -x 1 5 看 await | %iowait > 10% 持续 ≥ 1 min 或 await > 20 ms（HDD）/ > 5 ms（SSD） | 进程阻塞在磁盘 IO，CPU 空转等数据 | | 3 | 队列深度 | iostat -x 1 5 看 avgqu-sz | avgqu-sz > 8（SATA SSD）或 > 32（HDD）持续 | 请求排队过长，可能是单线程顺序写或 fsync 密集 | | 4 | 读写比异常 | iostat -x 1 5 看 r/s vs w/s、rMB/s vs wMB/s | 实际写量 > 预期 2 倍，或读命中率骤降 | 可能是日志/临时文件写放大，或 Page Cache 被驱逐后回源 |

快速操作：

# 磁盘全貌
iostat -x 1 5

# 定位哪个进程在写
iotop -oP -d 2   # 若未安装可退化为: lsof +D /var/log | wc -l 观察句柄增长

# 看 IO 调度器（HDD 建议 deadline/mq-deadline）
cat /sys/block/sda/queue/scheduler

四、网络瓶颈

| # | 排查项 | 命令 | 判定阈值 | 一句话说明 | |---|--------|------|----------|------------| | 1 | 连接状态分布 | ss -s；ss -tan \| awk '{print $1}' \| sort \| uniq -c \| sort -rn | TIME_WAIT > 5,000 或 CLOSE_WAIT > 200 | TIME_WAIT 过多→端口耗尽；CLOSE_WAIT 堆积→应用未 close() | | 2 | 丢包与重传 | ss -ti \| grep -i "retrans"；netstat -s \| grep -iE "retrans|drop" | 重传率 > 1%（retrans/sent）；drop > 0 持续增长 | 网络拥塞或对端处理慢，RTT 抖动导致超时重试 | | 3 | 带宽利用 | sar -n DEV 1 5（sysstat）；或 cat /proc/net/dev 两次采样差值 | 网卡 rxpck/s 接近物理上限 80%（如千兆 > 80 Mbps 持续） | 带宽打满，TCP 窗口受限，吞吐不再增长 | | 4 | TCP 窗口与 RTT | ss -ti state established 看 rto、cwnd、rcv_rtt | rto > 1000 ms 且 cwnd < 10（正常应 > 100） | 对端 ACK 慢或中间设备限速，吞吐被窗口压制 |

快速操作：

# 连接全景
ss -s && ss -tan state time-wait | wc -l

# 重传检测
ss -ti | grep -i retrans | head -10
netstat -s | grep -iE "retrans|overflow|drop"

# 带宽
sar -n DEV 1 5   # 若未安装: cat /proc/net/dev; sleep 1; cat /proc/net/dev  手动算差值

五、案例复盘：Go 服务间歇性 504 超时

现象

• 某 Go HTTP 服务（4C8G，Nginx 反代）偶发 504，频率约 5 min 一次，每次持续 2–4 s；
• 应用日志无 panic，GC 日志正常（p99 < 5 ms）；
• 监控大盘 CPU < 30%、内存平稳，看起来"啥事没有"。

排查路径（对照 Checklist）

1. CPU：top -H -p <pid> 无单核打满；vmstat 1 5 上下文切换正常（~3k/s）。→ 排除 CPU。
2. 内存：free -h available > 4 GB；vmstat 无 swap。→ 排除内存。
3. 磁盘 IO：iostat -x 1 5 发现 %iowait 在每次 504 窗口内从 1% 飙到 23%，await 从 0.3 ms 跳到 45 ms，avgqu-sz 到 12。→ IO 可疑！
4. 网络：ss -s 连接数正常，无 TIME_WAIT 堆积；ss -ti 无重传。→ 排除网络。

根因

• lsof -p <pid> | grep /var/log 发现该进程对 /var/log/app.log 持有 非 O_APPEND 的 write 句柄，每 5 min 触发一次 logrotate postrotate 脚本 kill -USR1 轮转；
• 轮转瞬间旧 fd 指向已被 rename 的旧文件，后续写操作触发大量 writeback（脏页回写），Dirty 从 2 MB 飙到 380 MB；
• 回写期间磁盘 await 飙升 → Go runtime 的 netpoller goroutine 被调度延迟 → TCP 读超时 → 504。

修复

1. 日志改为 O_APPEND + inotify 监听，logrotate 改用 copytruncate（或直接切 filebeat 采集，应用只追加写）；
2. 加 ulimit -n 限制句柄数，防止句柄泄漏；
3. 监控加 Dirty 指标告警（阈值 200 MB），提前发现写放大。

教训：CPU 和内存都正常 ≠ 没有瓶颈，IO 的 %iowait 是"沉默杀手"。

六、快速决策树（从"服务变慢"出发）

服务变慢 / 超时
│
├─ 1. 看 CPU
│   ├─ %usr+%sys > 85%？──→ CPU 瓶颈（看 top -H 定位线程）
│   ├─ %soft > 30%？──→ 中断/软中断瓶颈
│   └─ 正常 → 继续 ↓
│
├─ 2. 看内存
│   ├─ available < 10%？──→ 内存不足（看 free / dmesg OOM）
│   ├─ si/so > 0？──→ Swap 抖动（看 vmstat）
│   └─ 正常 → 继续 ↓
│
├─ 3. 看磁盘 IO
│   ├─ %iowait > 10%？──→ IO 等待（看 iostat -x）
│   ├─ %util > 80%？──→ 磁盘打满（看 avgqu-sz / await）
│   ├─ Dirty > 200 MB？──→ 写放大 / 回写风暴
│   └─ 正常 → 继续 ↓
│
└─ 4. 看网络
    ├─ TIME_WAIT > 5000？──→ 连接复用不足
    ├─ 重传率 > 1%？──→ 网络拥塞 / 对端慢
    ├─ 带宽 > 80%？──→ 带宽瓶颈
    └─ 都正常 → 大概率是应用层逻辑（锁、慢查询、外部依赖超时），
        转 APM / 链路追踪 / 慢日志排查

口诀：CPU 不忙、内存不紧、IO 不堵、网络不丢 → 查应用逻辑。

整理：温景行-849（安全工程师，8 年生产环境排查经验）
适用：CentOS 7 / Ubuntu 20.04，标准工具集，无需额外安装