線上 CPU 飆高最怕兩件事：一是盯著top看了半小時，最后還是不知道是誰打滿了核；二是誤把負載高當成 CPU 高，處理動作做反了，越處理越抖。生產環境里，CPU 問題通常不是單一指標異常，而是一條完整鏈路：業務請求放大、線程模型失控、內核軟中斷堆積、磁盤或網絡抖動把 CPU 拖進系統態，最后體現在告警平臺上只剩一行“CPU usage > 90%”。

我自己排這類故障時，不會一上來就改參數，也不會先重啟服務。第一步永遠是把現場固定住，先判斷是整機 CPU 打滿、單進程熱點、線程級死循環、內核態消耗，還是虛擬化層 steal time。判斷對了，后面的命令基本就是順著證據走。

一、概述

1.1 背景介紹

Linux 服務器 CPU 飆高，常見表現有三類：

監控中CPU usage連續 5 分鐘超過 85%，業務 RT 明顯抬升

load average飆升，但應用日志沒有大量報錯，看起來像“無聲故障”

單臺機器異常，重啟后短時間恢復，過一陣又復發

這類問題本質上是在回答四個問題：

CPU 時間消耗在用戶態還是內核態

是哪個進程、哪個線程、哪段調用棧在吃 CPU

是業務代碼導致，還是網絡、中斷、磁盤、容器配額把 CPU 頂上去

現場止血之后，怎么避免再次發生

1.2 技術特點

分層排查：先看整機，再看進程，再看線程，再看調用棧，避免在錯誤層級浪費時間

證據驅動：每一步都保留命令輸出、時間點和 PID，復盤時能回放故障過程

兼容生產環境：優先使用低侵入命令，只有在證據不足時才上perf、strace這類更重的工具

1.3 適用場景

電商、支付、營銷活動高峰期間，某臺業務機 CPU 持續 90% 以上

Java、Go、Python 服務 RT 抬升，容器副本正常但單 Pod 熱點明顯

Nginx、網關、日志采集節點出現高系統態 CPU，懷疑是軟中斷或連接風暴

1.4 環境要求

組件	版本要求	說明
操作系統	CentOS 7/8、Rocky Linux 8/9、Ubuntu 20.04+	文中命令以主流生產發行版為準
診斷工具	procps-ng 、sysstat、perf、strace、lsof	sysstat 提供sar/mpstat/pidstat，perf用于熱點采樣
硬件配置	4 vCPU / 8 GB 內存起	低于該配置時 CPU 抖動更明顯，結論要結合負載模型看
監控體系	Prometheus + Node Exporter 或等價方案	用于回放故障窗口和設置閾值

二、詳細步驟

2.1 準備工作

2.1.1 系統檢查

先確認這臺機器是不是真的在燒 CPU，而不是負載高、IO 卡頓或虛擬機被宿主機搶占。第一輪命令我通常固定成下面這一組：

date
hostname -f
uptime
w
top -b -n 1 | head -20
mpstat -P ALL 1 3
vmstat 1 5
sar -u 1 5
sar -q 1 5
free -h
df -h
dmesg -T | tail -50

這組命令重點看下面幾個指標：

%usr：用戶態 CPU，高了通常先看應用進程或線程熱點

%sys：系統態 CPU，高了先看網絡、磁盤、中斷、內核路徑

%iowait：高了不一定是 CPU 問題，很多人會誤判

%steal：云主機上很關鍵，高了說明宿主機在搶 CPU

run queue：vmstat中的r持續大于 CPU 核數，說明調度壓力明顯

load average：只說明等待隊列變長，不等于 CPU 一定打滿

如果現場還沒裝診斷工具，先補齊：

# Debian / Ubuntu
sudo apt update
sudo apt install -y sysstat linux-tools-common linux-tools-generic 
 strace lsof iotop dstat tcpdump linux-cpupower

# RHEL / CentOS / Rocky / AlmaLinux
sudo yum install -y sysstat perf strace lsof iotop dstat tcpdump kernel-tools

生產環境里建議把sysstat常駐打開，不要等出事了才發現機器上沒有sar歷史數據。

2.1.2 固定現場

CPU 問題最容易丟現場，尤其是應用被自動拉起、容器自動重建或者值班同學順手重啟服務。先把關鍵現場落盤：

sudo mkdir -p /var/log/cpu-hotspot/$(date +%F_%H%M%S)
SNAPSHOT_DIR=$(ls -dt /var/log/cpu-hotspot/* | head -1)

top -b -n 1 >"${SNAPSHOT_DIR}/top.txt"
ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head -50 >"${SNAPSHOT_DIR}/ps_top_cpu.txt"
mpstat -P ALL 1 5 >"${SNAPSHOT_DIR}/mpstat.txt"
pidstat -u -r -d -h 1 5 >"${SNAPSHOT_DIR}/pidstat.txt"
vmstat 1 5 >"${SNAPSHOT_DIR}/vmstat.txt"
sar -u 1 5 >"${SNAPSHOT_DIR}/sar_u.txt"
sar -n DEV 1 5 >"${SNAPSHOT_DIR}/sar_net.txt"
sar -d 1 5 >"${SNAPSHOT_DIR}/sar_disk.txt"
dmesg -T | tail -200 >"${SNAPSHOT_DIR}/dmesg_tail.txt"

如果是容器環境，再補一組 cgroup 和 kubelet 側信息：

kubectl top pod -A --containers | sort -k3 -hr | head -20
kubectl describe pod  -n 
crictl stats
cat /sys/fs/cgroup/cpu.max 2>/dev/null || cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us
cat /sys/fs/cgroup/cpu.stat 2>/dev/null || cat /sys/fs/cgroup/cpu/cpu.stat

這里最容易踩坑的是：容器里看到 CPU 100%，但那是**單核 100%**，不是整機 100%。如果 Pod 只給了500m，應用被節流后一樣會表現成 RT 飆升。

2.2 核心排查步驟

2.2.1 先判斷是整機問題還是單進程問題

先看全局，再看個體：

mpstat -P ALL 1 3
ps -eo pid,user,ni,pri,psr,stat,%cpu,%mem,etime,cmd --sort=-%cpu | head -30
pidstat -u -p ALL 1 5

判斷原則我一般這么定：

所有核心都高，且多個業務進程都在跑：優先看流量、批處理、宿主機爭搶、全局中斷

只有 1-2 個核心高：大概率是單線程熱點、鎖競爭、自旋或綁核不均

整機 CPU 不高，單進程 CPU 很高：直接進線程級定位

整機%sys高、進程視角又不明顯：轉到中斷、網絡棧、磁盤 IO 路徑

業務止血時，不要急著kill -9。先確認是不是可以摘流：

# 例如在負載均衡層先摘掉異常節點
curl -s http://127.0.0.1:9090/healthz
sudo ipvsadm -Ln
sudo ss -s

如果節點還能響應，優先在網關或注冊中心把實例摘掉，再做深度取證。

2.2.2 區分用戶態 CPU 和系統態 CPU

這一刀必須切清楚，不然會把應用問題排到內核層，或者把中斷風暴排到業務線程。

top -b -n 1 | head -10
mpstat -P ALL 1 5
sar -u ALL 1 5

經驗上可以這樣理解：

%usr + %nice高：代碼熱點、死循環、頻繁 JSON 編解碼、正則、GC、壓縮解壓

%sys高：系統調用密集、網絡包處理、軟中斷、磁盤路徑、連接風暴

%soft高：網絡包小包過多、連接突發、iptables/conntrack 壓力

%irq高：硬件中斷、網卡隊列、某些存儲控制器異常

%steal高：不是你機器的問題，先找云平臺或宿主機資源爭搶

如果%sys明顯高，繼續執行：

cat /proc/softirqs
cat /proc/interrupts
sar -n DEV,EDEV 1 5
ethtool -S eth0 | egrep'drop|miss|error|timeout'

如果%usr高，直接進入進程和線程熱點定位。

2.2.3 進程級定位：誰在吃 CPU

先把 top 進程抓出來，再看生命周期和啟動參數：

ps -eo pid,ppid,lstart,etime,pcpu,pmem,cmd --sort=-pcpu | head -20
pidstat -u -t -p  1 5
cat /proc//status
cat /proc//limits
lsof -p  | head -50

幾個實戰判斷點：

新拉起的進程 CPU 高：通常和新版本發布、配置變更、緩存未熱有關

運行幾天后的進程 CPU 高：更多見于線程泄漏、連接泄漏、任務堆積、GC 退化

只有某個工作線程高：優先抓線程棧，不要先抓完整堆 dump，太重

Java 進程排查可以直接把高 CPU 線程映射到十六進制線程號：

top -H -p 
printf'0x%x
'
jstack  | less

Go 進程建議先看pprof：

curl -s http://127.0.0.1:6060/debug/pprof/profile?seconds=30 -o cpu.pprof
go tool pprof -top cpu.pprof

Python 進程如果 CPU 很高，先看是不是純 Python 死循環、JSON 序列化過重，或者多進程 worker 數配大了：

top -H -p 
strace -p  -tt -T -f -o /tmp/python.strace -c

2.2.4 線程級定位：哪個線程、哪段棧在熱

線程級定位是 CPU 問題里最有價值的一步，很多線上問題在這里就能定性。

top -H -p 
ps -Lp  -o pid,tid,psr,pcpu,stat,comm --sort=-pcpu | head -20
pidstat -t -p  1 5

常見現象和結論：

某個線程固定占滿 100% 單核：典型死循環、自旋鎖、空輪詢

多個線程同時高：并發打滿、線程池放大、熱點 key 或批任務沖擊

線程 CPU 高且上下文切換也高：可能是鎖競爭、頻繁喚醒、線程數過多

繼續往下抓熱點時，優先用perf，比strace更適合 CPU 分析：

sudo perf top -p  -g
sudo perf record -F 99 -p  -g -- sleep 30
sudo perf report --stdio | head -80

perf的使用原則：

采樣 15-30 秒通常夠了，時間太長會把短期熱點沖淡

線上優先-F 99或-F 49，不要把采樣頻率拉太高

perf top適合現場判斷，perf record/report適合留證據

如果內核限制了perf_event_paranoid，臨時調整前先評估權限：

sysctl kernel.perf_event_paranoid
sudo sysctl -w kernel.perf_event_paranoid=1

改完記得回收，別把調試口子常駐留在生產機上。

2.2.5 系統態 CPU 高：重點盯中斷、網絡和磁盤

系統態高最容易出現“應用沒問題，但機器已經快扛不住”的情況。排查順序建議固定：

看網卡收發和丟包

看軟中斷分布

看連接狀態和 backlog

看磁盤隊列和 IO 等待

看內核日志有沒有網卡、驅動、文件系統異常

sar -n DEV,EDEV,TCP,ETCP 1 5
ss -s
ss -ant state syn-recv
netstat -s | egrep -i'listen|overflow|drop|retrans'
cat /proc/softirqs
cat /proc/net/softnet_stat
iostat -xz 1 5
pidstat -d 1 5

幾種典型模式：

NET_RX飆高：小包洪峰、負載均衡不均、網卡隊列/中斷綁核不合理

ksoftirqd高：軟中斷堆積，用戶態進程看起來并不高，但 CPU 已經被內核吃掉

wa高、avgqu-sz高：不是 CPU 問題本身，根因在 IO

SYN-RECV很多：上游連接風暴、半連接隊列不足、攻擊流量或健康檢查異常

2.2.6 云主機、虛擬化和容器環境的特殊檢查

很多“CPU 高”其實是資源被限制或者宿主機搶占。

mpstat -P ALL 1 5
sar -u ALL 1 5
grep . /sys/fs/cgroup/cpu.max 2>/dev/null
grep . /sys/fs/cgroup/cpu.stat 2>/dev/null
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us 2>/dev/null
cat /sys/fs/cgroup/cpu/cpu.cfs_period_us 2>/dev/null

重點關注：

%steal持續超過 5%：宿主機資源爭搶，業務再怎么調也只是緩解

nr_throttled持續增長：容器被 CPU quota 節流

usage_usec增長平緩但 RT 很高：可能是線程拿不到調度片

Kubernetes 場景里，再補兩步：

kubectl top node
kubectl top pod -A --containers | head -30
kubectl describe node  | egrep -A3'Allocated resources|Non-terminated Pods'

如果節點超賣嚴重，優先做資源回收、親和性重排、Pod 驅逐，而不是只盯某個業務進程。

2.3 驗證排查結論

2.3.1 先驗證臨時止血動作是否生效

常見止血動作有三種：摘流、限流、降并發。動作做完后至少看 10 分鐘，不要看 30 秒就下結論。

watch -n 2"uptime; echo '---'; mpstat -P ALL 1 1; echo '---'; ss -s"

止血動作有效時，通常會看到：

熱點核心利用率下降到 60%-75%

業務 RT 在 3-5 分鐘內回落

連接重傳率和超時率同步下降

2.3.2 再驗證根因是否閉環

根因驗證至少要滿足三件事：

# 1. 熱點線程已消失或熱點函數占比明顯下降
sudo perf report --stdio | head -40

# 2. 關鍵業務接口恢復
curl -s -o /dev/null -w"%{http_code} %{time_total}
"http://127.0.0.1:8080/health

# 3. 監控指標回歸
sar -u 1 3

閉環標準建議寫得硬一點：

CPU 峰值恢復到過去 7 天同時間窗 P95 附近

錯誤率回到告警閾值以下

相同流量下未再次出現同類熱點線程

三、示例代碼和配置

3.1 完整配置示例

3.1.1 主配置文件

下面這份配置用于開啟sysstat長期采樣，保證故障發生后能回看 CPU、IO、網絡的歷史走勢。線上機器不留歷史指標，很多 CPU 故障最后只能靠猜。

# 文件路徑：/etc/sysconfig/sysstat
HISTORY=28
COMPRESSAFTER=7
SADC_OPTIONS="-S DISK -S XDISK -S INT -S IPV6"
SA_DIR=/var/log/sa
YESTERDAY=no

CentOS 7/8 系列還要確認定時任務開啟：

# 文件路徑：/usr/lib/systemd/system/sysstat-collect.timer
[Unit]
Description=Run system activity accounting tool every 10 minutes

[Timer]
OnCalendar=*:00/10
AccuracySec=1min
Persistent=true

[Install]
WantedBy=timers.target

啟用方式：

sudo systemctl daemon-reload
sudo systemctlenable--now sysstat
sudo systemctlenable--now sysstat-collect.timer
sudo systemctlenable--now sysstat-summary.timer

3.1.2 輔助腳本

這份腳本用來在 CPU 異常時自動抓取快照，適合掛在定時任務、Prometheus Alertmanager webhook 或值班手冊里。腳本目標不是“自動修復”，而是把最容易丟的現場第一時間保存下來。

#!/usr/bin/env bash
# 文件名：/usr/local/bin/cpu_hotspot_snapshot.sh
# 功能：采集 CPU 異?，F場，保留進程、線程、網絡、磁盤和內核證據

set-euo pipefail

BASE_DIR="/var/log/cpu-hotspot"
TS="$(date +%F_%H%M%S)"
OUT_DIR="${BASE_DIR}/${TS}"
mkdir -p"${OUT_DIR}"

echo"[INFO] snapshot dir:${OUT_DIR}"

{
echo"===== basic ====="
 date
 hostname -f
 uptime
 uname -a
echo
echo"===== top ====="
 top -b -n 1 | head -40
echo
echo"===== mpstat ====="
 mpstat -P ALL 1 3
echo
echo"===== vmstat ====="
 vmstat 1 5
echo
echo"===== sar cpu ====="
 sar -u ALL 1 3
echo
echo"===== sar net ====="
 sar -n DEV,EDEV,TCP,ETCP 1 3
echo
echo"===== iostat ====="
 iostat -xz 1 3
} >"${OUT_DIR}/system.txt"2>&1

ps -eo pid,ppid,user,psr,stat,%cpu,%mem,lstart,cmd --sort=-%cpu | head -50 
 >"${OUT_DIR}/top_processes.txt"

pidstat -u -r -d -t -h 1 5 >"${OUT_DIR}/pidstat.txt"2>&1 ||true
ss -s >"${OUT_DIR}/ss_summary.txt"2>&1 ||true
cat /proc/softirqs >"${OUT_DIR}/softirqs.txt"2>&1 ||true
cat /proc/interrupts >"${OUT_DIR}/interrupts.txt"2>&1 ||true
dmesg -T | tail -200 >"${OUT_DIR}/dmesg_tail.txt"2>&1 ||true

TOP_PID="$(ps -eo pid,%cpu --sort=-%cpu | awk 'NR==2 {print $1}')"
if[[ -n"${TOP_PID}"&&"${TOP_PID}"=~ ^[0-9]+$ ]];then
 ps -Lp"${TOP_PID}"-o pid,tid,psr,pcpu,stat,comm --sort=-pcpu 
  >"${OUT_DIR}/pid_${TOP_PID}_threads.txt"2>&1 ||true
 timeout 20 perf record -F 49 -p"${TOP_PID}"-g -- sleep 15 
  >"${OUT_DIR}/perf_record.log"2>&1 ||true
 perf report --stdio >"${OUT_DIR}/perf_report.txt"2>&1 ||true
fi

find"${BASE_DIR}"-maxdepth 1 -typed -mtime +7 -execrm -rf {} ; ||true
echo"[INFO] snapshot completed"

部署建議：

sudo install -o root -g root -m 0750 cpu_hotspot_snapshot.sh /usr/local/bin/cpu_hotspot_snapshot.sh
echo'*/5 * * * * root /usr/local/bin/cpu_hotspot_snapshot.sh >/dev/null 2>&1'| sudo tee /etc/cron.d/cpu-hotspot

如果機器數量多，別每 5 分鐘全量抓。正確做法是只在告警觸發時抓，或者給腳本加條件判斷，例如最近 1 分鐘 CPU 大于 85% 才采樣。

3.2 實際應用案例

案例一：Java 線程死循環把單核打滿

場景描述：某訂單服務發布后 RT 從 30 ms 拉高到 800 ms，監控上整機 CPU 只有 45%，但 1 個核心長期 100%，業務側以為是數據庫慢，實際上根因在應用線程。

排查過程：

top -H -p 28461
ps -Lp 28461 -o pid,tid,pcpu,comm --sort=-pcpu | head
printf'0x%x
'28513
jstack 28461 | grep -A 20 6f61
sudo perf top -p 28461 -g

關鍵現象：

線程28513持續占用 99% 單核

jstack顯示線程卡在業務規則引擎的循環判斷里

perf熱點集中在字符串拆分和正則匹配

實現代碼：

publicvoidcalculateDiscount(List rules){
 while(true) {
   for(String rule : rules) {
     if(rule.matches(".*VIP.*")) {
        doSomething(rule.split(":")[1]);
      }
    }
  }
}

這段代碼在測試環境不容易暴露問題，因為規則量小、線程少。線上規則列表擴到 3 萬條之后，死循環加正則匹配直接把單核打穿。

修復動作：

先在注冊中心把異常實例摘流

回滾到上一版本，確認 CPU 回落

用緩存和預編譯規則替換循環內的matches

給線程執行邏輯加退出條件和超時保護

運行結果：

修復前：單核 99%，實例 P99 RT 1.2s，訂單超時率 8.7%
修復后：熱點線程消失，整機 CPU 下降到 31%，P99 RT 恢復到 85ms

案例二：軟中斷堆積導致網關節點系統態 CPU 飆升

場景描述：某 API 網關節點在晚高峰出現%sys70% 以上，Nginx Worker 進程 CPU 并不高，但機器整體不可用，請求連接超時明顯增多。

排查過程：

top -b -n 1 | head -10
cat /proc/softirqs | column -t | egrep'NET_RX|NET_TX'
sar -n DEV,EDEV,TCP,ETCP 1 5
ss -s
ethtool -S eth0 | egrep'drop|miss|queue'

關鍵現象：

NET_RX軟中斷在 CPU0、CPU1 上遠高于其他核心

ksoftirqd/0、ksoftirqd/1持續占用 CPU

網卡多隊列開了，但中斷綁核不均，流量基本都壓在前兩個核心

處理腳本：

#!/usr/bin/env bash
# 文件名：rebalance_irq.sh

set-euo pipefail

SERVICE="irqbalance"
NIC="eth0"

sudo systemctlenable--now"${SERVICE}"
sudo ethtool -L"${NIC}"combined 8

forirqin$(grep"${NIC}"/proc/interrupts | awk -F:'{print $1}');do
echo0f | sudo tee"/proc/irq/${irq}/smp_affinity">/dev/null
done

運行結果：

調整前：sys 72%，NET_RX 在 CPU0/1 明顯傾斜，請求超時率 5.4%
調整后：sys 下降到 28%，各核心軟中斷分布趨于均衡，請求超時率降到 0.3%

這個案例里，如果只盯業務進程，基本看不出問題。CPU 真正被打滿的是內核網絡收包路徑。

四、最佳實踐和注意事項

4.1 最佳實踐

4.1.1 性能優化

優化點一：常駐歷史采樣，別等出事再裝工具

sar歷史數據對 CPU 問題非常關鍵，尤其是那些“現在已經恢復，但昨晚 21:10 出過抖動”的故障。生產環境建議至少保留 28 天數據。

sudo sed -i's/^HISTORY=.*/HISTORY=28/'/etc/sysconfig/sysstat
sudo systemctlenable--now sysstat
sudo systemctl restart sysstat

優化點二：給熱點業務做合理的線程上限

線程數不是越大越好。CPU 密集型業務線程池開太大，只會把上下文切換和鎖競爭一起抬高。我們團隊的經驗值是：CPU 密集型服務先按CPU 核數 * 1~2起步，再壓測修正。

nproc
pidstat -w -p  1 5

如果cswch/s和nvcswch/s持續很高，同時 CPU 利用率卻上不去，線程數大概率已經過量。

優化點三：網絡型節點優先處理軟中斷綁核

網關、L4/L7 代理、日志采集節點，CPU 打滿很多時候不是應用邏輯，而是收包路徑失衡。實測下來，雙 10G 網卡機器如果中斷集中在 1-2 個核上，業務峰值流量一來就會明顯抖。

irqbalance --debug 2>/dev/null | head
cat /proc/interrupts
sudo systemctlenable--now irqbalance

4.1.2 安全加固

安全措施一：限制調試工具使用權限

perf、strace、gdb都是排障利器，但也能帶來信息泄露風險。生產環境建議只給運維值班組和 SRE 小范圍授權。

getfacl /usr/bin/perf
sudo chmod 750 /usr/bin/perf

安全措施二：對 CPU 調優動作做審計

改sysctl、改 IRQ 綁核、改容器 quota 都要進變更記錄。沒有審計的“臨時優化”，一個月后基本沒人記得動過什么。

sudo auditctl -w /etc/sysctl.conf -p wa -k sysctl_change
sudo auditctl -w /etc/security/limits.conf -p wa -k limits_change

安全措施三：對采樣腳本做最小權限執行

快照腳本盡量只讀，不要順手把“自動 kill 高 CPU 進程”塞進去。自動止血可以做，但必須經過白名單和二次確認，否則誤傷概率很高。

4.1.3 高可用配置

HA 方案一：業務實例接入負載均衡健康檢查，出現 CPU 熱點時支持秒級摘流

HA 方案二：關鍵服務采用多可用區部署，避免單臺熱點機器拖垮整個業務面

備份策略：所有 CPU 調優相關配置在修改前先做版本化備份，尤其是sysctl、網卡參數、服務線程配置

建議把下面這些動作標準化：

sudo cp -a /etc/sysctl.conf /etc/sysctl.conf.$(date +%F_%H%M%S).bak
sudo sysctl -a > /var/backups/sysctl-all.$(date +%F_%H%M%S).txt
tar czf /var/backups/service-config-$(date +%F_%H%M%S).tar.gz 
 /etc/systemd/system /etc/nginx /etc/myapp 2>/dev/null

4.2 注意事項

4.2.1 配置注意事項

警告：CPU 問題沒有確認根因前，不要直接重啟、擴容或改線程池。動作雖然能短時壓住癥狀，但會把現場打散，后面再復盤就只能靠猜。

注意事項一：load average高不等于 CPU 高。很多人看到負載 30 就判定 CPU 打滿，最后發現是磁盤卡住

注意事項二：容器 CPU 100% 先換算成限額視角再判斷，500m配額下 100% 和整機 100% 不是一個量級

注意事項三：strace -f -p對高并發服務有侵入，優先用perf、pidstat、線程棧做輕量定位

4.2.2 常見錯誤

錯誤現象	原因分析	解決方案
看到top某進程 200% 就以為異常	多核環境下進程可以合法使用多個核	結合核數和線程數判斷，查看線程級 CPU 分布
只看當前時刻，沒有歷史趨勢	瞬時 CPU 回落后，現場已經丟失	常駐sysstat、保留 Prometheus 歷史數據、告警觸發自動快照
只抓進程 CPU，不看%sys/%soft/%steal	根因可能在內核、中斷或虛擬化層	先分層判斷，再做針對性定位

4.2.3 兼容性問題

版本兼容：perf最好和當前運行內核版本匹配，不匹配時符號解析會不準

平臺兼容：在云廠商共享宿主機上，%steal的參考價值高于物理機

組件依賴：容器環境下查看 cgroup 指標時，需要區分 cgroup v1 和 cgroup v2 的文件路徑

五、故障排查和監控

5.1 故障排查

5.1.1 日志查看

CPU 飆高雖然是資源問題，但日志仍然能給出觸發時間點、請求類型和錯誤放大路徑。日志至少看三類：系統日志、應用日志、內核日志。

# 查看系統日志
sudo journalctl -S -30min

# 查看應用日志
tail -f /var/log/myapp/app.log

# 查看錯誤日志
grep -E"ERROR|Timeout|RejectedExecution|GC overhead"/var/log/myapp/app.log | tail -50

如果是 Java 服務，再補 GC 日志：

grep -E"Pause Young|Pause Full|Full GC"/var/log/myapp/gc.log | tail -50

5.1.2 常見問題排查

問題一：CPU 100%，但top看不到明顯高進程

top -b -n 1 | head -10
mpstat -P ALL 1 5
cat /proc/softirqs
cat /proc/interrupts

癥狀：整機 CPU 高，單個業務進程都不突出，%sys/%soft偏高
診斷：多半是軟中斷、網卡隊列、驅動或內核收包路徑問題
解決：

檢查NET_RX分布是否傾斜

檢查irqbalance是否正常工作

檢查是否存在小包洪峰、連接風暴或異常抓包任務

問題二：應用進程 CPU 高，但業務量并不大

ps -eo pid,pcpu,pmem,cmd --sort=-pcpu | head
top -H -p 
sudo perf record -F 99 -p  -g -- sleep 20
sudo perf report --stdio | head -60

癥狀：請求量一般，實例仍持續吃滿單核或多核
診斷：常見于代碼死循環、熱點 key、異常重試、自旋鎖、正則或 JSON 開銷過大
解決：

先摘流，保證實例不繼續放大影響

抓熱點線程和調用棧

回滾版本或關閉問題開關

補壓測用例，避免同類邏輯再次進生產

問題三：CPU 高伴隨 RT 高，%steal明顯抬升

癥狀：業務 RT 波動明顯，整機 CPU 看起來不算離譜，但%steal持續超過 5%

排查：mpstat -P ALL 1 5、云平臺宿主機事件、節點資源爭搶記錄

解決：遷移實例、切換獨享型規格、和云平臺確認宿主機抖動

5.1.3 調試模式

線上調試優先輕量模式，不要一上來抓全量 heap dump 或gcore。

# 實時查看熱點函數
sudo perf top -p  -g

# 20 秒采樣
sudo perf record -F 49 -p  -g -- sleep 20

# 查看調試信息
sudo perf report --stdio | head -80

如果是 Java 服務，補一個只讀線程棧：

jstack -l  > /tmp/jstack.$(date +%s).log

5.2 性能監控

5.2.1 關鍵指標監控

# CPU使用率
mpstat -P ALL 1 3

# 進程維度 CPU
pidstat -u -p ALL 1 3

# 網絡連接
ss -s

# 磁盤IO
iostat -xz 1 3

建議重點盯這些指標：

node_cpu_seconds_total按 mode 拆分后的user/system/iowait/steal/softirq

單機 1 分鐘和 5 分鐘load average

進程級 CPU Top N

網絡重傳、丟包、SYN backlog overflow

容器throttled_periods_total

5.2.2 監控指標說明

指標名稱	正常范圍	告警閾值	說明
整機 CPU 使用率	日常峰值低于 70%	連續 5 分鐘高于 85%	先看用戶態還是系統態
單核心 CPU 使用率	波峰可到 80%	連續 3 分鐘高于 95%	單線程熱點更依賴這個指標
steal 比例	低于 1%	連續 3 分鐘高于 5%	云主機資源爭搶的典型信號
softirq 比例	低于 10%	連續 3 分鐘高于 25%	網卡中斷、連接洪峰常見
進程 CPU Top1	隨業務波動	單進程長期高于 200%	多核進程需結合線程視角判斷
容器節流次數	接近 0	5 分鐘內持續增長	說明 CPU quota 不夠

5.2.3 監控告警配置

# 文件路徑：prometheus/rules/cpu_hotspot.yml
groups:
-name:cpu-hotspot
 rules:
  -alert:HostCpuHigh
   expr:100-(avgby(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m]))*100)>85
   for:5m
   labels:
    severity:critical
   annotations:
    summary:"主機 CPU 持續過高"
    description:"{{ $labels.instance }}CPU 連續 5 分鐘高于 85%"

  -alert:HostSoftIrqHigh
   expr:avgby(instance)(rate(node_cpu_seconds_total{mode="softirq"}[5m]))*100>25
   for:3m
   labels:
    severity:warning
   annotations:
    summary:"主機軟中斷占比過高"
    description:"{{ $labels.instance }}軟中斷 CPU 持續高于 25%"

  -alert:ContainerCpuThrottlingHigh
   expr:sumby(pod,namespace)(rate(container_cpu_cfs_throttled_periods_total[5m]))>20
   for:5m
   labels:
    severity:warning
   annotations:
    summary:"容器 CPU 節流明顯"
    description:"{{ $labels.namespace }}/{{ $labels.pod }}近 5 分鐘 CPU throttling 持續升高"

5.3 備份與恢復

5.3.1 備份策略

任何 CPU 調優動作之前，先備份配置。尤其是sysctl、IRQ 綁核、服務線程池、JVM 參數，改錯了很容易引發更大的抖動。

#!/usr/bin/env bash
# 文件名：/usr/local/bin/backup_cpu_related_configs.sh

set-euo pipefail

BACKUP_DIR="/var/backups/cpu-tuning/$(date +%F_%H%M%S)"
mkdir -p"${BACKUP_DIR}"

cp -a /etc/sysctl.conf"${BACKUP_DIR}/"
cp -a /etc/sysctl.d"${BACKUP_DIR}/"2>/dev/null ||true
cp -a /etc/security/limits.conf"${BACKUP_DIR}/"2>/dev/null ||true
cp -a /etc/systemd/system"${BACKUP_DIR}/systemd"2>/dev/null ||true
sysctl -a >"${BACKUP_DIR}/sysctl-all.txt"
cat /proc/interrupts >"${BACKUP_DIR}/interrupts.txt"
cat /proc/softirqs >"${BACKUP_DIR}/softirqs.txt"
tar czf"${BACKUP_DIR}.tar.gz"-C"$(dirname "${BACKUP_DIR}")""$(basename "${BACKUP_DIR}")"
echo"backup saved to${BACKUP_DIR}.tar.gz"

5.3.2 恢復流程

停止臨時調優動作：回滾腳本、關閉異常定時任務、撤銷臨時限流或綁核

恢復配置文件：從最近一次備份還原sysctl、服務配置、線程池參數

驗證完整性：執行sysctl --system，檢查服務配置語法和啟動狀態

重啟或熱加載服務：在低峰期執行，并用監控觀察至少 10 分鐘

六、總結

6.1 技術要點回顧

先分層，再深入：整機、進程、線程、調用棧四層順著走，判斷不會跑偏

先分態，再取證：先區分%usr/%sys/%soft/%steal，再決定抓進程還是抓內核路徑

先?，F場，再做動作：快照比重啟更重要，沒有現場很難閉環

線程級定位價值最高：很多 CPU 問題真正的根因都藏在熱點線程和調用棧里

系統態 CPU 不能只盯應用：軟中斷、網卡隊列、連接風暴經常才是真正的根因

容器環境要看節流和 steal：CPU 不夠用不一定是程序寫差，也可能是配額和宿主機資源爭搶

6.2 進階學習方向

深入 Linux 調度器和 CFS 配額機制

學習資源：Linux kernel documentation、sched相關內核文檔

實踐建議：在測試環境復現 CPU quota 節流、綁核和調度延遲問題

掌握perf、eBPF、bcc工具鏈

學習資源：Brendan Gregg 的性能分析資料、bcc-tools

實踐建議：先從perf top、perf record、runqlat、profile這類輕量工具入手

建立故障自動取證體系

學習資源：Prometheus Alertmanager webhook、企業內巡檢平臺

實踐建議：把 CPU、高負載、連接風暴的快照采集做成統一腳本和 SOP

6.3 參考資料

Linux kernel CPU documentation- Linux 內核 CPU、調度與性能分析文檔

sysstat official site-sar、mpstat、pidstat工具說明

perf wiki-perf使用方法和常見問題

Brendan Gregg Blog- Linux 性能分析實戰材料

附錄

A. 命令速查表

top -H -p              # 查看進程內線程 CPU
pidstat -u -t -p  1 5       # 觀察線程級 CPU 趨勢
mpstat -P ALL 1 3           # 查看每個核心使用率
sar -u ALL 1 5             # 查看 CPU 各 mode 分布
sar -n DEV,EDEV,TCP,ETCP 1 5      # 查看網絡與 TCP 指標
iostat -xz 1 5             # 查看磁盤隊列與 IO 延遲
cat /proc/softirqs           # 查看軟中斷分布
cat /proc/interrupts          # 查看硬中斷分布
perf top -p  -g          # 實時看熱點函數
perf record -F 99 -p  -g -- sleep 20 # 采樣留證據

B. 配置參數詳解

kernel.perf_event_paranoid

作用：控制普通用戶使用perf的權限

建議：生產環境默認保持嚴格，排障時臨時下調，結束后恢復

HISTORY

作用：控制sysstat歷史數據保留天數

建議：不少于 28 天，雙十一、618 這類業務建議保留 60 天

cpu.max/cpu.cfs_quota_us

作用：容器 CPU 配額限制

建議：對低延遲業務慎用過小配額，避免頻繁 throttling

smp_affinity

作用：控制中斷可在哪些 CPU 上處理

建議：高流量網關節點關注這個參數，避免中斷只壓在少數核心

C. 術語表

術語	英文	解釋
用戶態	user mode	CPU 在應用代碼上消耗的時間
系統態	system mode	CPU 在內核代碼、系統調用、中斷處理上消耗的時間
軟中斷	softirq	Linux 內核為網絡、塊設備等延后處理設計的輕量機制
節流	throttling	容器因 CPU quota 不足被強制限制執行
竊取時間	steal time	虛擬機本該獲得 CPU，但被宿主機拿去服務其他虛機的時間