服务器负载过高排查

负载高 ≠ CPU 高。负载高可能来自 I/O 瓶颈、CPU 瓶颈、内存瓶颈或网络瓶颈。 排查本质是找到瓶颈资源的过程。

Netflix 60 秒法则

登录服务器后前 60 秒内执行标准命令序列，快速建立整体认知：

# ── 第 1~5 秒 ──
uptime                          # load average
dmesg -T | tail -10             # kernel errors

# ── 第 6~15 秒 ──
vmstat 1 3                      # procs/memory/io/system/cpu
mpstat -P ALL 1 3               # per-CPU breakdown

# ── 第 16~25 秒 ──
pidstat -u 1 3                  # per-process CPU
pidstat -d 1 3                  # per-process IO

# ── 第 26~35 秒 ──
iostat -xzm 1 3                 # disk IOPS & latency
free -h -w                      # memory pressure

# ── 第 36~45 秒 ──
sar -n DEV 1 3                  # network throughput
sar -n TCP,ETCP 1 3             # TCP retransmits, listen drops

# ── 第 46~60 秒 ──
top -bn1                        # process snapshot
ss -s                           # connection summary

判断标准：

• wa 高 + b 列高 → I/O 瓶颈
• us / sy 高 + r 列高 → CPU 瓶颈
• si/so 持续不为 0 → 内存不足（swap 频繁）
• cs 高 + sy 高 → 上下文切换过多

实战案例：日志 IO 打满

电商平台促销期间，24 核 / 32GB 服务器，load average 从 5~8 飙升至 42+，P99 响应从 200ms 到 3800ms。

全局扫描

┌─ uptime: 42.35, 28.17, 15.42
├─ top: wa=53.8%, id=32.1%      → I/O 瓶颈
├─ vmstat: b=38, r=3             → 38 进程阻塞在 I/O
├─ free: Mem OK, Swap 3G used    → 轻度内存压力
└─ 结论：I/O 瓶颈，非 CPU

定位 I/O 源头

┌─ iostat:  w/s=4500, w_await=112ms, %util=98.7%
├─ iotop:   Java 进程 320MB/s 写入，IO> 95.2%
├─ pidstat: Java PID=3456, 320MB/s
├─ lsof:    fd→app.log(deleted) + fd→app.log.1
└─ 结论：日志双文件写入打满磁盘

根因链路

DEBUG 日志（20MB/min → 20GB/min）
  → logrotate 用 create（非 copytruncate）
    → Java 进程仍在写入旧文件 app.log.1
      → IO 翻倍 → 磁盘打满 → 进程排队 → load 飙升

恢复与修复

# 临时恢复
kill -USR1 <PID>                  # 日志框架重载
: > /proc/<PID>/fd/<FD_NUMBER>    # 清空 deleted 文件内容（等价 truncate -s 0，不可回滚）

长期方案：异步日志 + 独立分区 + 正确的轮转策略。 轮转策略不是无脑 copytruncate：

根治顺序是 reopen 机制 > copytruncate > 什么都不做。本案例的 Java 应用由 Logback/Log4j2 管理日志，正解是修好日志框架自己的轮转（或让 postrotate 发对信号），而不是默认切到 copytruncate——后者复制 20GB/min 级别的日志同样会把 IO 打满。

⚠️ 观点分歧（2026-09-02 标注）： 本页早期结论（2026-05-11）把「logrotate copytruncate」直接列为长期方案。2026-08-11 的来源指出 copytruncate 先复制再截断，对大日志意味着一次全量复制、I/O 翻倍，不适合高写入速率场景。完整证据链见 linux-deleted-file-disk-space-reclaim。

常见根因速查

生产排查纪律

① 不要盲目重启 — 重启清除现场，根因可能永远丢失
② 先采集数据再操作 — kill/rm/restart 前保存关键指标
③ 判断要有数据支撑 — "wa=53.8%、b=38" 而非"我觉得是 IO"
④ 灰度执行 — 多节点先验证一个，确认再推全量
⑤ 回滚方案提前准备 — 改配置前先备份
⑥ 变更记录完整 — 记入故障复盘报告

关联页面