導讀：本文翻譯自 Brendan Gregg 去年的一篇部落格文章 “CPU Utilization is Wrong”，從標題就能想到這篇文章將會引起爭議。文章一上來就說，我們“人人皆用、處處使用，每個效能監控工具裡都在用”的 top 命令裡的 “%CPU” 指標，是不對的，其並非用於衡量 CPU 的繁忙程度的正確指標，作者譴責了一下眾人(或許也包括你我)的這一行為是具有很大的誤導性(deeply misleading)的，而且這種情況還在連年惡化。對於這麼大一頂帽子，讓我們暫且按下躁動的心，聽聽作者是怎麼深入闡釋他的觀點的。

1. 引言

可能你認為的 90% CPU 利用率意味著這樣的情形：

而實際卻可能是這樣的：

CPU 並非 90% 的時間都在忙著，很大一部分時間在等待，或者說“停頓(Stalled)”了。這種情況表示處理器流水線停頓，一般由資源競爭、資料依賴等原因造成。多數情況下表現為等待訪存操作，其中又以讀操作為主。在停頓週期內，不能執行指令，這意味著你的程式不往前走。

值得注意的是，圖中 “Stalled” 狀態所佔的比例是作者依據生產環境中的典型場景計算而來，具有普遍現實意義。因此，大多時候 CPU 處於停頓狀態，而你卻不知道，因為 CPU 利用率這個指標沒有告訴你真相。通過進一步分析 CPU 停頓的原因，可以指導程式碼優化，提高執行效率，這是我們深入理解CPU微架構的動力之一。

2. CPU 利用率的真實含義是什麼？

我們通常所說的CPU利用率是指 “non-idle time”：即CPU不執行 idle thread 的時間。作業系統核心會在上下文切換時記錄CPU的執行時間。假設一個 non-idle thread 開始執行，100ms 後結束，核心會認為這段時間內 CPU 利用率為 100%。這種度量方式源於分時複用系統。早在阿波羅登月艙的導航計算機中，idle thread 當時被叫做 “DUMMY JOB”，工程師通過比對執行 “DUMMY JOB” 和 “實際任務” 的時間來衡量導航系統的利用率。那麼這個所謂“利用率”的問題在哪兒呢？當今時代，CPU 執行速度遠遠大於記憶體訪問速度，等待訪存的時間成為佔用 CPU 時間的主要部分。當你在 top 中看到很高的 “%CPU”，你可能認為處理器是瓶頸，但實際上卻是記憶體。在過去很長一段時間內，CPU 頻率增長的速度大於 DRAM 訪存延時降低的速度（CPU DRAM gap），直到2005年前後，處理器廠商們才開始放棄“頻率路線”，轉向多核、超執行緒技術，再加上多處理器架構，這些都導致訪存需求急劇上升。儘管廠商通過增大 cache 容量、優化 cache 策略、提升匯流排頻寬來試圖緩解訪存瓶頸，但我們的程式仍深受 CPU stall 困擾。

3. 如何真正辨別 CPU 在做些什麼？

在 PMC(Performance Monitoring Counters) 的幫助下，我們能看到更多的 CPU 執行狀態資訊。下圖中，perf 採集了10秒內全部 CPU 的執行狀態。

這裡我們重點關注的核心度量指標是 IPC(instructions per cycle)，它表示平均每個 CPU cycle 執行的指令數量，很顯然該數值越大效能越好。上圖中IPC 為 0.78，看起來還不錯，是不是 78% busy 呢？現代處理器一般有多條流水線，執行 perf 的那臺機器，IPC 的理論值可達到 4.0。

如果我們從 IPC的角度來看，這臺機器只執行到其處理器最高速度的 19.5%（0.78 / 4.0)。幸運的是，在處理器內部，有很多 PMU event，可用來幫助我們分析造成 CPU stall 的原因。用好 PMU 需要我們熟悉處理器微架構，可以參考 Intel SDM。

4. 最佳實踐是什麼？

如果 IPC < 1.0, 很可能是 Memory stall 佔主導，可從軟體和硬體兩個方面考慮這個問題。軟體方面：減少不必要的訪存操作，提升 cache 命中率，儘量訪問本地節點記憶體；硬體方面：增加 cache 容量，加快訪存速度，提升匯流排頻寬。如果IPC > 1.0, 很可能是計算密集型的程式。可以試圖減少執行指令的數量：消除不必要的工作。火焰圖CPU flame graphs，非常適用於分析這類問題。硬體方面：嘗試超頻、使用更多的 core 或 hyperthread。作者根據PMU相關的工作經驗，設定了1.0這個閾值，用於區分訪存密集型(memory-bound)和計算密集型(cpu-bound)程式。讀者可以根據自己的實際工作平臺，合理調整這個閾值。

5. 效能工具應該告訴我們什麼？

作者認為，效能工具中使用 %CPU 時都應該附帶上 IPC，或者將 %CPU 拆分為指令執行消耗 cycle(%INS) 和 stalled 的 cycle(%STL)。對應到 top，在 Linux 系統有一個能夠顯示每個處理器 IPC 的工具 tiptop:

6. 其他可能讓 CPU 利用率引起誤解的因素

除了訪存導致的 stall 容易讓人誤解 CPU 利用率外，還有其他一些因素：

• 溫度原因導致處理器 stall；
• Turboboost 干擾了時鐘速率；
• 核心使得時鐘速率加快；
• 平均帶來的問題：1分鐘利用率平均 80%，掩蓋了中間 100% 部分；
• 自旋鎖: CPU 一直在被使用，同時 IPC 也很高，但是應用邏輯上並沒有任何進展。

7. 更新：CPU 利用率真的錯了嗎?

這篇文章引起了大量留言：

• http://www.brendangregg.com/blog/2017-05-09/cpu-utilization-is-wrong.html 的留言欄;

• https://news.ycombinator.com/item?id=14301739

• https://www.reddit.com/r/programming/comments/6a6v8g/cpu_utilization_is_wrong/

總結下作者的回答是：這裡討論的並不是 iowait (那是磁碟IO)，而且如果你已經確認是訪存密集型，是有些處理辦法（參考上面）。

那麼 CPU 利用率指標是確確實實錯誤的，還是隻是容易誤導？如作者前面所說，他認為許多人把高 CPU 利用率理解為瓶頸在 CPU 上，這一行為才是錯誤的；

其實單看 CPU 利用率並不清楚瓶頸在何處，很多時候瓶頸是在外部。這個指標技術上看是否正確？如果 CPU stall 的週期並不能被其他地方使用，它們是不是也就因此是“忙於等待“（聽起來有點矛盾）？在有些情況，確實如此，你可以說 CPU 利用率作為作業系統級別的指標技術上看是對的，但是容易產生誤導。

從另一個角度來說，有超執行緒的情況下，那些 stalled 的週期是可以被其他執行緒使用的，這時 “%CPU” 可能會將可用的週期統計為正在使用，這種情況是錯誤的。這篇文章作者想關注的是解釋清楚這個問題，並給出解決方法建議，但沒錯，CPU 利用率這個指標本身也是存在一些問題的。

當你可能會說利用率作為一個指標已經不對，Andrian Cockcroft之前討論已經指出過 (http://www.hpts.ws/papers/2007/Cockcroft_HPTS-Useless.pdf )。

8. 結論

CPU 利用率已經開始成為一個容易誤導的指標：它包含訪存導致的等待週期，這樣會影響一些新應用。也許 “%CPU” 應該重新命名為 “%CYC”（cycles的縮寫）。要清楚知道 “%CPU” 的含義，需要使用其他指標進行輔助，其中就包括每週期指令數(IPC)。IPC < 1.0 多半意味著訪存密集型，IPC > 1.0 多半意味著計算密集型。作者之前的文章中涵蓋有 IPC 說明，以及用於測量 IPC 的 Performance Monitoring Counters（PMCs）的介紹。所有的效能監控產品如果展示 “%CPU”，都應該同時展示 PMC 指標用於解釋其真實意義，不要誤導使用者。比如，可以把 “%CPU” 和 “IPC” 一起放，或者說指令執行消耗週期和 stalled 週期。有這些指標之後，開發者和操作者就能夠知道該如何更好地對應用和系統進行調優。

轉自

CPU 利用率背後的真相，只有 1% 人知道 https://www.toutiao.com/a6639092067458875917/?tt_from=mobile_qq&utm_campaign=client_share&timestamp=1545787216&app=news_article&utm_source=mobile_qq&iid=26112390770&utm_medium=toutiao_ios&group_id=6639092067458875917