公有雲EC2超賣StealTime怎麼測

用mpstat實測EC2 Steal Time，識別超賣與惡鄰

更新於 2026-08-13 · CloudWorth

Steal TimeEC2超賣效能審計NitroFinOpsCloudWorth雲伺服器超賣VPS檢測

Steal Time偏高不等於超賣，需結合Nitro與積分機制綜合判斷。

mpstat實測超賣

在公有雲EC2上測Steal Time，最直接的方法是 mpstat -P ALL 1 觀察幾輪 %steal。但別看到數字高就喊超賣——我踩過坑：T3實例CPU積分耗盡時，%steal也能飆到30%+，但那根本不是鄰居搶佔，是積分池空了。真正要區分Nitro虛擬化下的正常調度開銷、Burstable積分耗盡和惡鄰搶佔，必須搭配/proc/schedstat和CloudWatch的CPUCreditBalance指標一起看。

實作時我習慣先跑sudo apt install sysstat && mpstat 1 5，重點看%steal是否持續>10%。如果只是瞬間抖動，多為Host正常的CPU資源競爭；若長時間居高，且cpustat中steal時間佔比穩定，才懷疑超賣。注意：Steal Time高不等於超賣，也可能是你自己買小了——T3實例開Unlimited後，持續高負載會先把未來積分預支掉，表現就是steal升高。

到這裡還不算完。我會順手把mpstat輸出匯出成CSV，連同CloudWatch截圖打包成PDF——萬一要開維權工單，這是硬證據。AWS共享型實例的性價比看起來誘人，但FinOps算帳時要把潛在steal風險折成溢價率：同樣是4 vCPU，與其賭運氣搶鄰居，不如算清楚Dedicated Host vs 共享實例的長期成本差。

完整稽核思路可看EC2 StealTime巡檢指南，或直接進維運稽核台自動跑一輪。

Nitro 超賣與 T3 積分

AWS EC2 的 Nitro 架構與一般 KVM 超賣不同：Nitro 的 CPU 排程較為硬隔離，但共用宿主機依然存在鄰居資源爭搶。真正容易混淆的是 T3/T3a/T4g 這類可突增執行個體。當 CPU 積分耗盡且未啟用 Unlimited，效能會被強制拉回基準，此時 mpstat 中的 %steal 不一定會飆升，反而更像是自己「卡頓」。而啟用 Unlimited 後，積分可以透支，但會產生額外費用。

所以排查時，先用 mpstat 1 連續取樣，再對照 CloudWatch 的 CPUCreditBalance 指標。若 steal 高但積分充足，才是超賣證據；否則可能是 Nitro 虛擬化的正常開銷。實測中，若持續高 steal，建議收集 /proc/stat 時間戳證據，用於提交工單或降配論證——畢竟從 FinOps 的角度看，為超賣買單代表溢價率不划算。

取證工單與FinOps溢價

當你在EC2上抓到持續偏高的steal time，先別急著給AWS扣上「超賣」的帽子。我的習慣是：先用mpstat -P ALL 1連續取樣15分鐘，再擷取CloudWatch的CPUCreditBalance和CPUCreditUsage做對照。如果T3/T4g的積分餘額歸零，那steal time高多半是CPU積分耗盡，而不是鄰居搶CPU。真正要坐實「惡鄰」，得看Nitro虛擬化下steal是否超過5%且伴隨irq抬升——但Nitro本身有少量調度開銷，所以別拿VPS那套0.5%閾值硬套。

到了取證階段，我會同時匯出CloudWatch的CPUUtilization、StealTime指標（EC2的StealTime是自訂命名空間，得用GetMetricData擷取），再用/proc快照記錄cpu行。把這三樣按時間戳拼接成PDF，在工單中直接附上。AWS Support看到帶時間軸和截圖的資料，通常會更願意查底層宿主機——雖然他們極少承認超賣，但會幫你更換實例或調整placement group。

最後說FinOps溢價：同樣規格的c7i.large，在共享宿主機上跑批次處理，steal time 3%和8%的實例，實際吞吐量能差12%以上。如果算上積分耗盡後的額外計費（T系列unlimited），綜合成本可能比專用主機還貴。建議把steal time納入每月成本報表，超過5%的按「性能損耗溢價」折算，再對照Dedicated Host的包年價——很多時候，給關鍵任務升級宿主反而更划算。