「%CPU 利用率」其實是個謊言 （★ 135 分）
在 IT 營運中，常用命令工具如 top 或其他系統監控工具監視網路、記憶體與 CPU (中央處理器) 利用率，以判斷伺服器工作負載是否接近極限。然而實測發現，所謂的「%CPU 利用率」並不是線性指標：當系統回報 50% 利用率時，實際執行工作量往往已達到 60–100% 之間，事實與直覺大相逕庭。
作者在 Ubuntu 系統上使用 Ryzen 9 5900X (12 核心／24 執行緒) 處理器，並啟用 Precision Boost Overdrive (即 Turbo, AMD Turbo Core) 後，以自製腳本結合 stress-ng 進行壓力測試，先讓 24 個執行緒在 1% 至 100% 之間變化，再讓 1 至 24 個執行緒全速運行，並以 Bogo ops (參考 BogoMIPS 基準) 量化每秒執行次數。測試結果顯示，一般 CPU 基準與 64 位元整數運算在回報 50% 利用率時，實際效能已達 65–85%；矩陣運算更在相同回報下跑到 80–100%。主因在於超執行緒技術 (SMT, simultaneous multithreading) 共享實體核心資源，以及 Turbo 加速頻率隨核心數增加而下降等因素，使得「忙碌時脈數／總時脈數」的計算方式導致利用率指標被低估。作者建議以實際應用為基準：先做基準測試找出伺服器最大可接受負載，再以目前流量或請求量做相對比對，取代單純參考 CPU 利用率。
社群討論中，多位專業人士引用廚房與廁紙比喻說明超執行緒技術：就像兩位廚師共用廚房設備、或 2 層紙只能算 1 張紙，額外的執行緒提升了資源使用率卻無法倍增效能；也有人提醒不同處理器廠商 SMT 與 Turbo 設計差異甚大，記憶體頻寬、快取與鎖定機制等共享瓶頸同樣非線性。群組意見並建議與其盯著長秒級平均利用率，不如關注短毫秒量級的 p95 延遲 (95 百分位) 及 p99 延遲 (99 百分位) 表現，以及透過真實負載的基準測試來量化系統擴充／縮減時機。
其他觀點補充，可結合 perf 與 ftrace 等工具檢視快取失準、記憶體存取延遲等精細指標；GPU (圖形處理器，Graphics Processing Unit) 的利用率更容易產生誤導，須比對理論 FLOP/s 峰值；stress-ng 雖能呈現線性崩潰前的行為，但以 Memcached 或 Postgres 等實際服務負載測試，往往更貼近生產力需求並揭露高負載下的銳減效能。整體而言，最佳化策略應以應用實際效能與延遲需求為基準，而非單純仰賴 CPU 利用率。
👥 63 則討論、評論 💬
https://news.ycombinator.com/item?id=45110688