題幹與適用場景
一臺 Linux 主機的 %iowait 從 3% 升到 38%，業務 p99 延遲翻倍，而整體 CPU 使用率只有 30%。請說明如何區分本地塊裝置、NFS、記憶體回收、hypervisor steal，以及採集範圍不一致造成的假象。
這道題考察 SRE、DevOps、後端和系統職位的診斷能力。38%、30% 和 p99 翻倍是虛構練習資料，不是通用門檻。回答應先解釋 /proc/stat 的 iowait，再用 vmstat、iostat、pidstat、PSI、cgroup 和核心日誌建立證據鏈。
面試官考察點
記賬邊界
候選人要知道 iowait 是 CPU 統計欄位，不是磁碟使用率，也不等於所有工作等待 I/O 的總時長。多核排程會讓歸屬變得不精確。
證據分層
強回答會從主機平均值深入每核、執行緒、cgroup、裝置和業務尾延遲，說明每個觀測如何改變假設。
等待路徑
應區分本地塊 I/O、NFS/FUSE、資料庫 RPC、記憶體回收和 hypervisor steal。不同路徑需要不同工具和處置。
安全閉環
回答要包含留證、低風險止損和恢復驗收，避免直接重啟、殺行程或提高並行放大故障。
回答前需要澄清的問題
- iowait 來自主機還是容器？主機
/proc/stat與服務 cgroup 可能不是同一範圍。 - 是每核都高，還是單核高？平均值會隱藏 affinity、NUMA 或配額造成的局部飽和。
- 請求等待的是檔案、塊裝置還是網路 RPC？NFS、資料庫和 HTTP 的證據不同。
- p99 與 I/O 指標是否嚴格同窗？要對齊採樣、發佈、備份和流量。
- 是否有 swap、major fault、memory PSI 或 steal time？
- 是否有權限讀取執行緒棧和 cgroup 檔案？生產排查應採用最小權限。
30 秒回答框架
“38% iowait 是線索，不是磁碟故障結論。先對齊主機、服務和 p99 的時間窗，再看每核 mpstat、vmstat r/b、CPU/IO/memory PSI、cgroup 配額和 steal time。
若裝置佇列、延遲、行程讀寫與核心錯誤一起異常，查塊裝置；若執行緒停在 NFS 或檔案系統而本地裝置正常，查掛載、網路和伺服器端；若 memory PSI、swap、major fault 上升，查工作集；若 steal 上升，查宿主機。止損後同時驗證業務尾延遲、等待執行緒、PSI 和底層資源。”
分步驟深入解答
第一步：解釋 iowait 的邊界
/proc/stat 的 iowait 是等待 I/O 完成時的 CPU 時間記賬。CPU 可以在一個工作等待時執行其他工作；多核下等待工作也不一定歸屬於同一個 CPU。因此低 iowait 不能排除遠程儲存或核心等待，高 iowait 也不能單獨證明磁碟故障。
第二步：看每核和實時佇列
mpstat -P ALL 1 10
vmstat 1 10
cat /proc/loadavgr 持續高且 CPU busy 高，支援 CPU 排隊；b 持續高，優先調查不可中斷等待。每核資料、affinity、cgroup quota 和 throttling 能揭示“總體 30%、局部已飽和”。
第三步：用 PSI 量化停頓
for r in cpu io memory; do echo "[$r]"; cat /proc/pressure/$r; donePSI 的 some 表示至少部分工作因資源停頓，full 表示所有非 idle 工作同時停頓；avg10/60/300 表示趨勢。讀取目標 cgroup 的 pressure 檔案，才能區分服務自身壓力與同機噪聲。
第四步：定位執行緒和等待點
ps -eLo state,pid,tid,wchan:32,comm --sort=state
pidstat -d -p ALL 1 10按 R/D 狀態、命令、cgroup 和 wchan 聚合。權限允許時讀取代表性執行緒的 /proc/PID/stack。wchan 只是目前睡眠位置，必須和時間相關性、PSI、業務延遲互相印證。
第五步：進入對應子系統
iostat -xz 1 10
dmesg -T | tail -200
cat /proc/meminfo | egrep 'Swap|Dirty|Major'塊裝置看 await、佇列、吞吐和錯誤；NFS/FUSE 看掛載、重傳、網路和伺服器端；記憶體看 memory PSI、swap 和 major fault；資料庫或 HTTP RPC 要補應用追蹤和連線池指標。
第六步：止損並驗證
先保留執行緒、PSI、裝置和日誌快照，再按證據限流、暫停批工作、切換健康副本或修復掛載。不要反覆 kill -9 D 狀態工作，訊號通常要等等待返回後才能處理。修復後同時驗證 p99、錯誤率、R/D 數、PSI、資源延遲和積壓。
高品質示範回答
“我不會把 38% iowait 直接等同於磁碟故障。它是受多核排程影響的 CPU 記賬欄位。我先對齊範圍和時間窗，再看每核 mpstat、vmstat r/b、CPU/IO/memory PSI、cgroup quota 和 steal time。
若 D 執行緒和 I/O PSI 增加，wchan 指向塊 I/O，iostat 的延遲和佇列也上升，就檢查裝置、檔案系統和核心錯誤。若本地裝置正常而執行緒集中在 NFS，則查掛載、重傳、網路和伺服器端。若 memory PSI、swap 或 major fault 上升，則控制工作集；若 steal 上升，則查宿主機。
我會先暫停放大 I/O 的批工作、限流或切換健康副本並保留現場。恢復驗收看業務 p99/錯誤率、R/D 數、PSI、底層延遲和積壓，而不是只等 iowait 回落。”
常見錯誤
- 把 iowait 當磁碟使用率；應結合
iostat和裝置基線。 - 看到 iowait 高就擴 CPU；應先查每核、R/D 和 PSI。
- 看到 iowait 低就排除 I/O；應檢查 D 狀態、遠程儲存和 I/O PSI。
- 把所有 D 狀態歸因於本地磁碟；NFS、驅動和檔案系統也會等待。
- 只看主機指標；服務 cgroup 可能有不同配額與壓力。
- 只取一次樣本；應連續採樣並和業務曲線對齊。
- 立即重啟或殺行程；先保留現場並評估資料完整性。
- 只等 iowait 降低；應驗證使用者延遲和資源佇列。
追問與應對
追問一：為什麼 iowait 高但磁碟 util 不高？
等待可能在 NFS、FUSE、資料庫或網路 RPC，也可能是裝置映射和時間窗不一致。沿執行緒等待點、應用追蹤、I/O PSI、掛載和網路指標繼續定位。
追問二：為什麼 iowait 低但請求仍卡住？
工作可能等待鎖、連線池、CPU 配額、記憶體回收或遠程 RPC。比較 R/D、執行緒棧、CPU/memory PSI 和依賴延遲；CPU 記賬不會分類所有等待。
追問三：容器如何判斷自身 I/O 壓力？
讀取目標 cgroup 的 io.pressure、I/O 統計和 throttling 事件，再與主機 /proc/pressure/io 和服務 p99 比較。主機高、容器低時擴容服務未必有效。
追問四：D 狀態執行緒可以直接 kill 嗎？
可以發訊號，但通常要等不可中斷等待返回後才處理。先保留堆疊和等待點，修復裝置、掛載或驅動；重啟要先確認冗餘和資料安全。
追問五：如何設定 iowait 警示？
不要使用跨機器通用的固定百分比。把 iowait 與 I/O PSI、裝置或遠端儲存延遲、D 狀態、業務 SLO 和持續時間組合，並按基線校準。