問(wèn)題背景

CPU 飆高是 Linux 服務(wù)器最常見(jiàn)的性能問(wèn)題之一。典型表現(xiàn)為：監(jiān)控告警觸發(fā)（CPU 使用率超過(guò) 90%）、業(yè)務(wù)響應(yīng)變慢、用戶投訴接口超時(shí)、ssh 操作卡頓。很多運(yùn)維同學(xué)遇到 CPU 飆高的第一反應(yīng)是重啟服務(wù)或直接 kill 進(jìn)程，這種方法治標(biāo)不治本，需要系統(tǒng)性地定位根因。

本文按照從全局到局部、從表象到根因的排查思路，分三階段展開(kāi)，覆蓋從 60 秒快速診斷到代碼級(jí)熱點(diǎn)分析的完整鏈路。

一、核心知識(shí)點(diǎn)速覽

排查 CPU 問(wèn)題前需要理解幾個(gè)關(guān)鍵概念：

load average：系統(tǒng)的"平均活躍進(jìn)程數(shù)"，包含正在運(yùn)行和等待 I/O 的進(jìn)程。如果 load > CPU 邏輯核數(shù)，說(shuō)明有進(jìn)程在排隊(duì)。

%us / %sy / %wa / %id / %st：CPU 時(shí)間的分布——用戶態(tài)、內(nèi)核態(tài)、I/O 等待、空閑、被虛擬機(jī)管理程序偷走。

**上下文切換 (context switch)**：CPU 在不同進(jìn)程/線程間切換的頻率，過(guò)高會(huì)浪費(fèi) CPU 時(shí)間在調(diào)度上而非業(yè)務(wù)上。

**運(yùn)行隊(duì)列 (run queue)**：處于可運(yùn)行狀態(tài)但等待 CPU 調(diào)度的進(jìn)程數(shù)，超過(guò)核數(shù)意味著 CPU 飽和。

不區(qū)分物理核和邏輯核的場(chǎng)景：排查時(shí)關(guān)注的是 CPU 的調(diào)度單位（邏輯核），nproc或lscpu輸出的 CPU(s) 就是邏輯核總數(shù)。

二、第一階段：60 秒全局掃描

登錄服務(wù)器后，不要急著翻日志，先用一組命令快速了解系統(tǒng)整體狀態(tài)。這一階段的目標(biāo)是定性：到底是 CPU 瓶頸、內(nèi)存瓶頸、IO 瓶頸，還是網(wǎng)絡(luò)問(wèn)題。

2.1 uptime —— 看負(fù)載基線

$ uptime
1415 up 12 days, 3:21, 2 users, load average: 18.52, 15.34, 10.87

如果 load average 超過(guò) CPU 邏輯核數(shù)，說(shuō)明有任務(wù)在排隊(duì)。單看 load 不夠，需要結(jié)合后面的命令判斷瓶頸在哪。

2.2 top —— 看 CPU 時(shí)間分布和 TOP 進(jìn)程

$ top
top - 1415 up 12 days, 3:21, 2 users, load average: 18.52, 15.34, 10.87
Tasks: 256 total,  3 running, 253 sleeping,  0 stopped,  0 zombie
%Cpu(s): 12.5 us, 8.3 sy, 0.0 ni, 45.8 id, 33.3 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 31967.6 total,  1224.5 free, 18234.2 used, 12508.9 buff/cache
MiB Swap:  4096.0 total,  345.2 free,  3750.8 used.  7123.4 avail Mem

 PID USER   PR NI  VIRT  RES  SHR S %CPU %MEM   TIME+ COMMAND
3456 root   20  0 ......

關(guān)鍵要看的是%Cpu(s)這一行的分布：

操作技巧：

按P鍵按 CPU 使用率排序

按1鍵展開(kāi)每個(gè)邏輯核的負(fù)載分布

按c鍵顯示完整命令行

2.3 vmstat —— 看調(diào)度和阻塞

$ 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
16 2 204800 12245  ...

只看前四列和 CPU 列：

關(guān)鍵判斷：如果r高但wa低，CPU 是瓶頸；如果b高且wa高，磁盤(pán)是瓶頸；如果cs極高，說(shuō)明線程過(guò)多或鎖競(jìng)爭(zhēng)嚴(yán)重。

2.4 mpstat —— 看各核負(fù)載是否均衡

$ mpstat -P ALL 1 3
Linux 5.15.0-91-generic ... 08/15/2025 _x86_64_ (32 CPU)

1415 CPU  %usr  %sys  %iowait  %idle
1416 all  12.50  8.30   33.30  45.80
1416  0  3.20  5.10   12.40  79.30
1416  1  60.50 15.30   5.20  19.00
...

關(guān)注點(diǎn)：如果個(gè)別核 %usr 或 %sys 明顯高于其他核，說(shuō)明存在綁核或單線程瓶頸。如果所有核負(fù)載一致偏高，說(shuō)明是全局限流（如 CPU 密集型任務(wù)、連接數(shù)打滿）。

2.5 第一階段判斷矩陣

三、第二階段：定位進(jìn)程與線程

全局掃描定位了方向后，接下來(lái)鎖定嫌疑進(jìn)程。

3.1 pidstat —— 按進(jìn)程統(tǒng)計(jì) CPU

# 每 1 秒統(tǒng)計(jì)一次，取 CPU 使用率最高的前 15 個(gè)
$ pidstat -u 1 5 | sort -k 8 -nr | head -15

Linux 5.15.0-91-generic ... 08/15/2025 _x86_64_ (32 CPU)

1422   UID    PID  %usr %system %guest  %wait  %CPU  CPU Command
1423    0   3456  85.30  2.10  0.00  0.00  87.40   2 java
1423   999   5678  12.40  1.20  0.00  0.00  13.60  15 nginx

%wait列（需要 procps-ng 4.0+）表示進(jìn)程處于可運(yùn)行狀態(tài)但等待 CPU 調(diào)度的百分比。如果%wait高說(shuō)明 CPU 確實(shí)是瓶頸，進(jìn)程在排隊(duì)等待調(diào)度。

3.2 top -H —— 看線程級(jí) CPU 消耗

找到嫌疑進(jìn)程后，看是進(jìn)程內(nèi)的哪個(gè)線程在吃 CPU：

$ top -H -p 3456

或者一步到位：

$ ps -p 3456 -To pid,tid,%cpu,cmd --sort=-%cpu | head -10
 PID  TID %CPU CMD
3456 3456 0.0 java
3456 6789 42.5 java
3456 6790 38.1 java

記下高 CPU 的 TID，轉(zhuǎn)成十六進(jìn)制用于線程 dump：

$printf"%x
"6789
1a85

這個(gè)十六進(jìn)制值在線程 Dump（jstack、pstack、/proc//task//stack）中用于查找對(duì)應(yīng)線程。

3.3 perf top —— 實(shí)時(shí)代碼級(jí)熱點(diǎn)

perf top能直接顯示哪個(gè)函數(shù)在消耗 CPU，比top精確到代碼級(jí)別：

# 實(shí)時(shí)查看 CPU 熱點(diǎn)函數(shù)（建議先裝 linux-tools-common）
$ sudo perf top -p 3456 -g

輸出示例：

Samples: 1M of event'cpu-clock', 4000 Hz, Event count (approx.): ...
Overhead Shared Object    Symbol
35.20% java        [.] JFFS2_write_super
12.50% libjvm.so      [.] Unsafe_GetLongVolatile
 8.30% [kernel]      [k] _raw_spin_unlock_irqrestore

-g參數(shù)顯示調(diào)用鏈，可以逐層回溯是誰(shuí)調(diào)用了這個(gè)熱點(diǎn)函數(shù)。

3.4 perf record：生成火焰圖

當(dāng)需要更精確的分析或?qū)ν鈪R報(bào)時(shí)，用采樣模式：

# 采樣 30 秒
$ sudo perf record -F 99 -p 3456 -g --sleep 30
$ sudo perf report --no-children

參數(shù)說(shuō)明：

-F 99：每秒采樣 99 次，兼顧精度和開(kāi)銷

-g：記錄調(diào)用鏈

-k 1：強(qiáng)制包含內(nèi)核棧（重要，否則大量[unknown]）

--no-children：展開(kāi)真實(shí)調(diào)用深度，避免折疊優(yōu)化隱藏信息

生成火焰圖：

$ sudo perf script -i perf.data > out.perf
$ gitclonehttps://github.com/brendangregg/FlameGraph
$cdFlameGraph
$ ./stackcollapse-perf.pl ../out.perf > out.folded
$ ./flamegraph.pl out.folded > cpu.svg

火焰圖橫軸是采樣比例，縱軸是調(diào)用棧。找到最寬的"平頂"區(qū)域就是熱點(diǎn)函數(shù)，從那里往上看調(diào)用路徑。

3.5 strace -c —— 統(tǒng)計(jì)系統(tǒng)調(diào)用開(kāi)銷

如果%sy（內(nèi)核態(tài) CPU）偏高，用strace看系統(tǒng)調(diào)用耗時(shí)分布：

# 統(tǒng)計(jì) 5 秒內(nèi)系統(tǒng)調(diào)用的耗時(shí)分布（不帶 -p 則啟動(dòng)新進(jìn)程）
$ sudo strace -c -p 3456
strace: Process 3456 attached
^C
% time   seconds usecs/call   calls  errors syscall
------ ----------- ----------- --------- --------- ----------------
45.20  0.452000     12    376      futex
30.15  0.301500      5    603      epoll_wait
12.10  0.121000      4    302      write
 8.50  0.085000      3    283     read

常見(jiàn)高耗時(shí)系統(tǒng)調(diào)用：

四、第三階段：根因分類與深挖

根據(jù)前兩階段的數(shù)據(jù)，將 CPU 飆高歸入以下典型類別進(jìn)行針對(duì)性排查。

4.1 CPU 密集型任務(wù)

特征：%usr 高（> 70%），perf top顯示業(yè)務(wù)函數(shù)占主導(dǎo)。

排查方向：

查看是否有新上線的代碼邏輯變更

檢查定時(shí)任務(wù)（crontab）是否集中在同一時(shí)段

使用perf record生成火焰圖確認(rèn)業(yè)務(wù)熱點(diǎn)

典型場(chǎng)景：突發(fā)流量導(dǎo)致連接處理數(shù)暴增、某些查詢 SQL 通過(guò) ORM 映射成循環(huán)查詢、正則表達(dá)式回溯導(dǎo)致 CPU 打滿。

4.2 死循環(huán)或無(wú)限遞歸

特征：?jiǎn)芜M(jìn)程 CPU 固定 100%（單核），strace -c顯示某個(gè)系統(tǒng)調(diào)用頻率極高。

排查方向：

# 先確認(rèn)是單線程還是多線程在跑
$ top -H -p 
# 對(duì) Java 應(yīng)用取 Thread Dump
$kill-3 
# 結(jié)合前面十六進(jìn)制的 TID 定位線程

典型場(chǎng)景：某次 while 循環(huán)缺少 break 條件、遞歸調(diào)用缺少終止條件、異常重試機(jī)制進(jìn)入死循環(huán)。

4.3 鎖競(jìng)爭(zhēng)激烈

特征：%sy 高（> 30%），vmstat 1的cs列 > 50000，strace -e futex高頻。

# 只看 futex 相關(guān)調(diào)用
$ sudo strace -e futex -p 

# 或用 perf 分析鎖相關(guān)事件
$ sudo perf record -esched:sched_stat_runtime -p  -- sleep 10
$ sudo perf report

典型場(chǎng)景：高并發(fā)下 HashMap 擴(kuò)容死循環(huán)（JDK 1.7 及以前）、ArrayList 并發(fā)寫(xiě)入、熱門(mén)行數(shù)據(jù)庫(kù)鎖、Redis 熱點(diǎn) key。

4.4 上下文切換過(guò)高

特征：CPU 消耗不高（%idle 高），但load average高，vmstat的cs> 80000。

# 查看自愿/非自愿上下文切換
$ pidstat -w 1 5

**自愿切換 (cswch/s)**：線程等待 I/O 或鎖時(shí)主動(dòng)讓出 CPU，過(guò)高可能因?yàn)?IO 頻繁。

**非自愿切換 (nvcswch/s)**：時(shí)間片用完被強(qiáng)制調(diào)度，過(guò)高因?yàn)榫€程數(shù)過(guò)多（超過(guò) CPU 核數(shù)太多）。

4.5 中斷處理過(guò)多

特征：%si（軟中斷）或 %hi（硬中斷）異常高。

# 查看中斷分布
$ cat /proc/interrupts
# 查看軟中斷
$ cat /proc/softirqs

典型場(chǎng)景：網(wǎng)卡 RX 隊(duì)列中斷集中到單個(gè) CPU（RPS/RSS 未配置）、TPS 過(guò)高導(dǎo)致網(wǎng)絡(luò)軟中斷多。

4.6 云服務(wù)器 vCPU 爭(zhēng)搶

特征：%st（steal）持續(xù) > 5%，且 %idle 低。

# 持續(xù)觀察 steal 值
$ mpstat -P ALL 1 | grep -v Linux | awk'{print $1,$13}'

%st 表示 hypervisor 從當(dāng)前 VM 偷走的 CPU 時(shí)間。如果持續(xù)高于 10%，說(shuō)明宿主機(jī)的 CPU 已超分嚴(yán)重，直接提工單找云廠商。

五、CPU 飆高 8 大根因速查表

六、生產(chǎn)環(huán)境注意事項(xiàng)

采樣頻率控制：perf record的-F不要超過(guò) 10000Hz，否則 perf 本身的開(kāi)銷會(huì)成為干擾。生產(chǎn)環(huán)境推薦 99-997Hz。

必須包含內(nèi)核棧：perf record -k 1，否則大量熱點(diǎn)顯示為[unknown]。

謹(jǐn)慎使用 strace -p：在高并發(fā)進(jìn)程上附加 strace 會(huì)導(dǎo)致進(jìn)程顯著變慢（5~10 倍性能下降），建議只在低峰期使用或先統(tǒng)計(jì)后采樣。

不要直接 kill 高 CPU 進(jìn)程：除非確認(rèn)是惡意進(jìn)程，否則先確認(rèn)進(jìn)程歸屬（java、mysql、httpd 可能有業(yè)務(wù)在跑）。

綁核排查：如果看到單核 100% 而其他核空閑，檢查是否有taskset綁核或 irqbalance 未運(yùn)行。

云服務(wù)器注意 %st：如果 %st 高，本地優(yōu)化無(wú)效，直接聯(lián)系云廠商。

操作前記錄現(xiàn)場(chǎng)：

$ date +%F_%H:%M:%S > /tmp/cpu_debug_$(date +%s).txt
$ uptime >> /tmp/cpu_debug_*.txt
$ top -bn1 >> /tmp/cpu_debug_*.txt
$ vmstat 1 5 >> /tmp/cpu_debug_*.txt

七、總結(jié)

CPU 飆高排查的核心思路可以濃縮為三句話：

先 60 秒全局掃描——用 uptime / top / vmstat / mpstat 定性是 CPU、IO、內(nèi)存還是網(wǎng)絡(luò)問(wèn)題。

再鎖定嫌疑進(jìn)程——用 pidstat / perf top / strace 熱點(diǎn)分析定位到具體的進(jìn)程、線程、函數(shù)。

最后對(duì)癥下藥——根據(jù)根因分類走對(duì)應(yīng)的優(yōu)化路徑：算法優(yōu)化、鎖優(yōu)化、擴(kuò)容、配置調(diào)整。

盲目重啟或加機(jī)器只是暫時(shí)掩蓋問(wèn)題，只有找到根因才能徹底解決。建議將上述排查流程固化成一個(gè)排查腳本，每次 CPU 飆高時(shí)自動(dòng)采集現(xiàn)場(chǎng)數(shù)據(jù)，再按流程逐步分析。