原文連結：
http://www.brendangregg.com/blog/2017-05-09/cpu-utilization-is-wrong.html
本文中若有任何疏漏錯誤，責任在於編譯者。有任何建議和意見，請回復內核月談微信公眾號，或通過 caspar at linux.alibaba.com 反饋。
導讀：本文翻譯自 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=14301739https://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 周期。有這些指標之後，開發者和操作者就能夠知道該如何更好地對應用和系統進行調優。