問題背景

2025 年 6 月，某電商平臺在年中促銷活動期間，線上 Web 服務(wù)器（配置 24 核 CPU / 32GB 內(nèi)存）于 14:30 左右觸發(fā) CPU 負載告警。監(jiān)控數(shù)據(jù)顯示 load average 從正常值 5~8 飆升至 42+，同時業(yè)務(wù)監(jiān)控顯示接口 P99 響應(yīng)時間從 200ms 升高到 3800ms，用戶側(cè)開始出現(xiàn)超時和 502 錯誤。

本文以這次故障的完整排查過程為線索，展示服務(wù)器負載過高的系統(tǒng)性排查方法。文章以第一人稱敘事展開，每步都給出實際命令輸出和決策思路。

一、接到告警：第一反應(yīng)

收到告警后，登錄服務(wù)器執(zhí)行第一個命令：

$ uptime
1445 up 15 days, 6:12, 3 users, load average: 42.35, 28.17, 15.42

load average 的三個值分別是 1 分鐘 / 5 分鐘 / 15 分鐘的平均負載。42.35 對于 24 核的服務(wù)器意味著平均每個 CPU 核上有 1.76 個任務(wù)在競爭——CPU 已經(jīng)飽和。

但負載高不等于 CPU 使用率高，需要進一步區(qū)分瓶頸類型。

二、全局掃描：定性瓶頸類型

2.1 top —— 看 CPU 時間分布

$ top
top - 1450 up 15 days, 6:12, 3 users, load average: 42.35, 28.17, 15.42
Tasks: 325 total,  4 running, 321 sleeping,  0 stopped,  0 zombie
%Cpu(s): 8.5 us, 5.2 sy, 0.0 ni, 32.1 id, 53.8 wa, 0.0 hi, 0.4 si, 0.0 st
MiB Mem : 31967.6 total,  4284.5 free, 14234.2 used, 13448.9 buff/cache
MiB Swap:  4096.0 total,  945.2 free,  3150.8 used. 13233.4 avail Mem

 PID USER   PR NI  VIRT  RES  SHR S %CPU %MEM   TIME+ COMMAND
5678 www    20  0 0.356t 0.042t 32768 S  2.2  0.6 12:34.56 java
2345 root   20  0 175240  5300  4212 S  1.8  0.1  2:15.30 nginx

最關(guān)鍵的發(fā)現(xiàn)是 **wa（I/O 等待）= 53.8%**，說明大量 CPU 時間在等待 I/O 完成。結(jié)合 id（空閑）= 32.1%，說明 CPU 并沒有滿載（us + sy = 13.7%），但系統(tǒng)負載高的原因是 I/O 阻塞導(dǎo)致進程排隊。

這是典型的"負載高因為 I/O 瓶頸"場景——CPU 有空閑時間，但進程在等 I/O 完成，所以 load average 中的"等待進程"數(shù)量很高。

2.2 vmstat —— 確認阻塞情況

$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b  swpd  free  buff cache  si  so  bi  bo in cs us sy id wa st
3 38 204800 42845  ...

b列（不可中斷睡眠進程數(shù)）為 38，說明有 38 個進程阻塞在 I/O 上。r列（運行隊列）為 3，說明 CPU 調(diào)度并沒有明顯積壓。

判斷：系統(tǒng)瓶頸在 I/O 子系統(tǒng)，不是 CPU。

2.3 free —— 檢查內(nèi)存和 swap

$ free -h -w
       total    used    available   buffers   cache
Mem:      31G     14G      13G     2.2G     11G
Swap:     4.0G     3.0G     1.0G

available 內(nèi)存 13G，不是內(nèi)存瓶頸。但 swap 使用了 3GB，說明存在一定程度的內(nèi)存壓力，進程被換出到磁盤，可能加重 I/O 負擔。

2.4 第一階段小結(jié)

全局掃描結(jié)論：

瓶頸類型：I/O 瓶頸（wa=53.8%，b=38）

資源情況：CPU 有余量（id=32.1%），內(nèi)存充足，swap 有少量使用

方向：下一步定位哪個進程在產(chǎn)生大量 I/O

三、定位 I/O 來源

3.1 iostat —— 看磁盤到底有多忙

$ iostat -xdm 1 3
Linux 5.15.0-91-generic ... 06/15/2025 _x86_64_ (24 CPU)

Device   r/s   w/s   rkB/s   wkB/s r_await w_await aqu-sz %util
vda   120.5 4500.3  3840.0 360000.0   2.1  112.3  248.5  98.7

關(guān)鍵指標解讀：

w/s = 4500：每秒 4500 次寫請求，非常高

w_await = 112.3ms：每次寫請求平均等待 112ms，遠高于 SSD 的正常范圍（<2ms）

aqu-sz = 248.5：平均隊列長度 248，說明 IO 請求大量積壓

**%util = 98.7%**：磁盤接近飽和

這是一塊通用型 SSD 云盤（極速型 SSD 的 IOPS 上限一般在 2 萬左右，但 4500 w/s 不至于打到上限）。112ms 的寫延遲說明單次寫入遇到了抖動——可能是磁盤層的資源爭搶或日志落盤的大量小 IO。

# 查看磁盤隊列深度（內(nèi)核側(cè)）
$ cat /sys/block/vda/queue/nr_requests
256

# 查看調(diào)度器
$ cat /sys/block/vda/queue/scheduler
[mq-deadline] none

3.2 iotop —— 找到 I/O 最多的進程

$ iotop -o
Total DISK READ: 3.84 M/s | Total DISK WRITE: 360.00 M/s
 TID PRIO USER   DISK READ DISK WRITE SWAPIN   IO>  COMMAND
3456 be/4 root    0.00 B/s 320.00 M/s 0.00 % 95.20 % java
5678 be/4 www    3.84 M/s  0.00 B/s 0.00 %  2.10 % nginx

Java 進程以 320MB/s 的速度在寫入磁盤，幾乎占了全部 IO。IO> 列顯示該進程 95.2% 的時間在等待 I/O。

3.3 pidstat -d —— 按進程確認

$ pidstat -d 1 3
Linux ... 06/15/2025 _x86_64_ (24 CPU)

1422   PID  kB_rd/s  kB_wr/s kB_ccwr/s Command
1423   3456   0.00 320000.00  0.00   java

3.4 確認文件級寫入

用lsof看 Java 進程打開了哪些文件在寫：

$ ls -la /proc/3456/fd/ | grep -E'REG.*W'| sort -k7 -rn | head -5
lrwx------ 1 root root 64 Jun 15 14:33 23 -> /var/log/app/app.log
lrwx------ 1 root root 64 Jun 15 14:33 24 -> /var/log/app/app.log.1
lrwx------ 1 root root 64 Jun 15 14:33 25 -> /var/log/app/error.log

關(guān)鍵發(fā)現(xiàn)：進程打開了app.log.1（輪轉(zhuǎn)后的日志文件）—— 這意味著日志輪轉(zhuǎn)后舊文件被重命名，但 Java 進程仍在往舊文件中寫入。

# 檢查這些 fd 是否已被刪除
$ ls -la /proc/3456/fd/23
... /var/log/app/app.log (deleted)
$ ls -la /proc/3456/fd/24
... /var/log/app/app.log.1

確認第 23 號 fd 對應(yīng)的文件已被刪除（logrotatecreate方式導(dǎo)致），而第 24 號 fd 對應(yīng)的app.log.1文件仍在寫入。

四、根因確認

4.1 排查發(fā)現(xiàn)

完整排查后，根因鏈路如下：

應(yīng)用日志配置為 DEBUG 級別：促銷活動期間開發(fā)團隊在線開啟了 debug 日志，日志寫入量從平時的 20MB/min 暴增到 20GB/min。

logrotate 使用 create 而非 copytruncate：默認的 logrotate 配置是create，輪轉(zhuǎn)時執(zhí)行mv app.log app.log.1+create new app.log。Java 進程持有的舊文件句柄仍然指向app.log.1（即被重命名后的文件），所以日志繼續(xù)向app.log.1寫入。

寫放大效應(yīng)：日志寫入量激增 + 雙文件寫入（app.log和app.log.1）→ 磁盤寫 IO 打滿 → 所有需要磁盤 I/O 的進程排隊（包括數(shù)據(jù)庫持久化、session 持久化）→ load average 飆升 → 業(yè)務(wù)響應(yīng)變慢。

# 確認日志文件大小
$ ls -lh /var/log/app/
-rw-r--r-- 1 root root 5.2G Jun 15 14:34 app.log
-rw-r--r-- 1 root root 4.8G Jun 15 14:34 app.log.1

# 確認 logrotate 配置
$ cat /etc/logrotate.d/app
/var/log/app/*.log{
  daily
  rotate 7
  create   # <- 問題在這里，應(yīng)該用 copytruncate
? ? compress
? ? delaycompress
? ? missingok
? ? notifempty
}

4.2 立即恢復(fù)操作

第一步：讓 Java 進程釋放舊文件句柄，釋放 deleted 文件的磁盤空間

# 查找 Java 進程 PID
$ ps aux | grep java
# 發(fā)送 USR1 信號讓 log4j2 重新加載配置（大多數(shù)日志框架支持）
$kill-USR1 

# 驗證空間是否釋放
$ df -h /

如果kill -USR1無效，可以用lsof確認哪個 fd 是 deleted 文件，然后清空：

# 找到 deleted 文件的 fd 編號
$ sudo lsof -p  | grep'(deleted)'
$ : > /proc//fd/

第二步：關(guān)閉 DEBUG 日志

修改 log4j2.xml 或 logback.xml，將日志級別恢復(fù)為 WARN 或 INFO，然后重新加載配置。

第三步：確認 IO 恢復(fù)正常

$ iostat -xdm 1 3
$ uptime

15 分鐘后負載恢復(fù)到正常水平。

4.3 根本解決方案

修改 logrotate 配置，使用copytruncate：

/var/log/app/*.log{
  daily
  rotate 30
  copytruncate
  compress
  delaycompress
  missingok
  notifempty
}

配置異步日志寫入（log4j2 AsyncAppender / logback AsyncAppender），避免日志 I/O 阻塞業(yè)務(wù)線程。

將 /var/log 獨立分區(qū)，避免日志寫滿根分區(qū)。

日志級別變更流程化：生產(chǎn)環(huán)境日志級別變更需審批，變更完成后自動恢復(fù)。

五、附加生產(chǎn)故障案例

上述案例是 I/O 阻塞型負載過高的典型場景。以下是另外三種在線上環(huán)境中反復(fù)出現(xiàn)的負載過高案例，供對比參考。

案例 A：數(shù)據(jù)庫雙 1 配置拖死磁盤

場景：某 MySQL 實例在業(yè)務(wù)高峰時 load 飆高到 60+，wa 持續(xù)在 70~80%。

$ iostat -xdm 1
sda  w/s=12000 w_await=92ms %util=99.5%

根因：innodb_flush_log_at_trx_commit=1（每次事務(wù)提交都刷盤）+sync_binlog=1（每次提交同步 binlog），在高并發(fā)事務(wù)下，磁盤 fsync 成為瓶頸。

-- 臨時降低持久化級別（風險：丟失 1 秒內(nèi)的事務(wù)）
SET GLOBAL innodb_flush_log_at_trx_commit=2;
SET GLOBAL sync_binlog=1000;

長期方案：

升級更高 IOPS 的云盤（如 ESSD PL3）

開啟組提交（group commit），MySQL 5.7+ 默認支持

考慮 semi-sync 復(fù)制代替強同步

案例 B：TIME_WAIT 堆積導(dǎo)致連接失敗

場景：高并發(fā)短連接服務(wù)，load 上升到 9.2（16 核），業(yè)務(wù)開始報 Connection refused。

$ ss -s
Total: 65200 (kernel 65321)
TCP:  62134 (estab 12, closed 62000, orphaned 8, synrecv 0, timewait 62000)

$ netstat -s | grep"listen"
  18432timesthe listen queue of a socket overflowed

根因：短連接場景下 TIME_WAIT 堆積到 62000，占滿了系統(tǒng)連接表，新的連接無法建立。

# 立即緩解
$ sysctl -w net.ipv4.tcp_tw_reuse=1
$ sysctl -w net.ipv4.tcp_fin_timeout=15

長期方案：客戶端改用長連接池或連接復(fù)用。

案例 C：apt-check 后臺進程 IO 打滿（小內(nèi)存服務(wù)器）

場景：低配云服務(wù)器（2 核 4GB）運行中突然 load 飆高到 15+，wa > 90%。

$ iotop -o
 TID PRIO USER   DISK READ DISK WRITE SWAPIN   IO>  COMMAND
1234 be/4 root   84.00 M/s  0.00 B/s 0.00 % 98.5 % apt-check

根因：Ubuntu 的unattended-upgrades自動更新檢查服務(wù)觸發(fā)，導(dǎo)致大量磁盤讀操作。小內(nèi)存服務(wù)器上磁盤 I/O 更容易成為瓶頸。

# 臨時停止
$ systemctl stop apt-daily.timer

# 永久關(guān)閉（如果不需要自動更新）
$ systemctldisableapt-daily.timer
$ systemctldisableapt-daily-upgrade.timer

六、Netflix 60 秒法則在實戰(zhàn)中的應(yīng)用

本次排查過程中使用的正是 Netflix 性能工程團隊總結(jié)的"60 秒法則"——登錄服務(wù)器后的前 60 秒內(nèi)執(zhí)行一組標準命令，快速建立整體認知。以下是針對負載過高場景的命令序列：

# 第 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                # snapshot of top processes
ss -s                 # connection summary

這套命令序列能在 1 分鐘內(nèi)完成系統(tǒng)的全面體檢，定位出瓶頸是 CPU、內(nèi)存、IO 還是網(wǎng)絡(luò)。

七、生產(chǎn)環(huán)境排查注意事項

不要在負載高時盲目重啟——重啟清除現(xiàn)場數(shù)據(jù)，根因可能永遠丟失。除非系統(tǒng)完全無響應(yīng)，否則優(yōu)先排查而非重啟。

先采集現(xiàn)場數(shù)據(jù)再操作：在執(zhí)行 kill / rm / restart 之前，先把關(guān)鍵指標保存下來：

$ mkdir -p /tmp/debug_$(date +%s)
$ uptime > /tmp/debug_*/uptime
$ top -bn1 > /tmp/debug_*/top
$ vmstat 1 5 > /tmp/debug_*/vmstat
$ iostat -xdm 1 5 > /tmp/debug_*/iostat
$ ss -s > /tmp/debug_*/ss

判斷依據(jù)要有數(shù)據(jù)支撐：不要說"我覺得是 IO 問題"，而是"wa=53.8%、b=38、w_await=112ms，所以 IO 是瓶頸"。

灰度執(zhí)行操作：如果有多個節(jié)點，先在一個節(jié)點上驗證恢復(fù)方案，確認有效再推全量。

回滾方案要提前準備：修改配置前備份（cp /etc/logrotate.d/app /etc/logrotate.d/app.$(date +%F)），確保改錯了能還原。

變更記錄要完整：誰在什么時間執(zhí)行了什么操作，影響范圍是什么，要記錄到故障復(fù)盤報告中。

八、總結(jié)

服務(wù)器負載過高的排查本質(zhì)是找到瓶頸資源的過程。負載高 ≠ CPU 高，負載高可能來自：

I/O 瓶頸（最常見）：wa 高、b 列高、iostat 顯示磁盤飽和

CPU 瓶頸：us 高、r 列高、各核負載均衡

內(nèi)存瓶頸：available 低、swap 活躍

網(wǎng)絡(luò)瓶頸：重傳率高、listen drops

排查流程可以固化為一個標準 SOP：

告警觸發(fā) → uptime 確認 → top 看 CPU 分布 → vmstat 看調(diào)度和阻塞 →
iostat/iotop 定位 IO → pidstat 確認進程 → lsof/straace 深挖根因 →
制定恢復(fù)方案 → 灰度執(zhí)行 → 驗證效果 → 根因整改

本次案例的核心教訓(xùn)是：日志輪轉(zhuǎn)配置不當 + 日志級別失控是最容易被忽視的生產(chǎn)隱患。建議將 lsof 檢查 deleted 文件作為新服務(wù)器上線檢查清單中的一項，同時規(guī)范日志級別變更流程。