CPU利用率如何計算

這篇文章主要介紹了CPU利用率如何計算，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

我們平時使用的CPU利用率方法是極具誤導性的，并且一年更甚一年。那么什么是CPU利用率？是你的CPU到底有多忙，是像“% CPU”這樣到處在用的指標所顯示的那樣嗎？

在top命令里，你看到90%的CPU利用率是這樣：

然而它真正想表達的是這個意思：

Stall(這里譯作“怠速”)是說這個處理器沒有在跑指令，比如在等待內存I/O的時候。我上圖所畫的比例（“忙”與“怠速”之間）是我在真實生產環(huán)境中遇到的，并且你的CPU也很可能是處于“怠速”狀態(tài)。

這些對你有什么意義呢？理解CPU怠速多少，會直接影響到你在減少代碼或者減少內存I/O的調優(yōu)工作。

那么真正的CPU利用率怎么算呢？

平時的CPU利用都是非空閑時間，即CPU不運行idle線程（比如Windows里的空閑進程）的時間。你的操作系統(tǒng)那會平時會在上下文切換的時候跟蹤它，但是假如一個非idle線程開始運行100毫秒后停止，那內核會認為后面這段時間CPU也在這個非idle線程上。

在老舊的分時系統(tǒng)里，這么算沒毛病。阿波羅登月艙的導航系統(tǒng)計算機將這里的idle線程叫做“DUMMY JOB”，工程師用利用它來測算計算機的利用率，可以參考之前我寫過的這樣一篇文章（鏈接地址：http://www.brendangregg.com/usemethod.html#Apollo）。

那么它有什么毛病呢？

現(xiàn)在的CPU比內存已經快了很多倍，但等待內存的時間仍然被算進CPU時間中。當你在top命令中看到較高的“%CPU”的時候，你可能認為它到達了一個性能瓶頸，就是散熱片和風扇下面的那個CPU，但實際上，這是那一根根內存條的鍋。

如何分辨CPU到底在忙啥？

使用性能監(jiān)測計數器（PMC）——一種能夠用perf或者其他工具命令查看的硬件計數器。比如，觀測整個系統(tǒng)10秒鐘：

這里的一個關鍵指標就是instructions per cylce（IPC，每CPU周期執(zhí)行指令數），它能夠顯示每CPU周期內每個CPU運行了多少指令，越高說明效率越高。上述示例中，這一值為0.78，但這并不說明CPU利用率為78%，因為現(xiàn)代CPU的IPC最大值為4.0（新的已經到了5.0），也就是4-wide。CPU在執(zhí)行指令時，單個指令會被分割為多個步驟，比如取指令、解碼、執(zhí)行、內存訪問、寫寄存器等，這些命令如果在單個CPU周期內最多執(zhí)行一個，那么需要5個CPU周期來完成一條命令，IPC就是0.2，如果采用指令流水線，即3~5-wide的CPU，那么完美狀態(tài)下1個CPU周期就可以完成一條命令，IPC就是1。（譯者注：作者文中使用了CPU clock cycle表示通常所說的CPU周期，為了避免與晶振時鐘周期混肴我并沒有將其譯為CPU時鐘周期。）

當然，還有數百個其他你可以用來測量的性能計數器。

如果在虛擬化環(huán)境中，guest一般不能直接訪問PMC，這取決于hypervisor是否支持。我最近寫的一篇The PMCsof EC2: Measuring（鏈接地址：http://www.brendangregg.com/blog/2017-05-04/the-pmcs-of-ec2.html） IPC展示了AWS EC2中基于Xen的虛擬機如何使用PMC。

最佳實踐

如果你的IPC小于1.0，你可能遇到了內存操作密集型，軟件調優(yōu)策略可以有減少內存I/O，增強內存本地訪問性，尤其是在NUMA系統(tǒng)上。硬件調優(yōu)策略則是使用CPU cache較大以及更快的內存、總線和內聯(lián)技術。三門峽婦科醫(yī)院http://www.smxrlyy.com/

如果你的IPC > 1.0，你可能是指令密集型?？梢栽噲D減少指令的執(zhí)行數量，比如消除不必要的工作和緩存操作等，可以用一下CPU火焰圖（鏈接地址：http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html）。硬件調優(yōu)方面，可以嘗試高主頻、多核、超線程的CPU。

性能檢測產品應該告訴你什么呢？

性能檢測工具都應該顯示出每個進程的IPC，或者是按照指令周期與怠速周期，比如%INS和%STL，下圖為Linux中的tiptop命令：

CPU利用率具有誤導性的其他理由

1. 使得這個%CPU指標錯誤的理由除了CPU在內存的怠速周期外，還有如下因素：

2. 溫度也能使CPU進入怠速；

3. Turboboost（睿頻）引起時鐘頻率變化；

4. SpeedStep引起時鐘頻率變化；

5. 一分鐘內的80%的平均利用率并不能表示100%的突發(fā)利用率（類似網絡QoS）；

6. 自旋鎖：CPU在很嚴肅地瞎忙；

Update: CPU利用率真的錯了嗎？

自這篇文章發(fā)布以后，留言討論非常激烈，已經有了上百條了。首先謝謝你們對這話題感興趣并花時間閱讀，但我在這里還是要統(tǒng)一回復：我對disk的iowait并不關心（譯者注：PC CPU不能直接操作外部存儲），并且文中也已經給出了內存操作密集型的對應調優(yōu)措施。

然而，CPU利用率到底是從本質上錯了還是僅僅是有誤導性了？我認為需要人將高CPU利用率視為處理單元的瓶頸的事兒，是錯的。那么這個指標的計算方法從技術上講正確嗎？如果CPU在怠速期間不能被其他任何進程使用，那么這不就是所謂的“使用等待”（聽起來有點矛盾）。某些情況下，%CPU作為一個操作系統(tǒng)層面的指標是技術正確但是容易誤導人的。在超線程中，怠速周期可以被其他線程使用，所以%CPU的算法也會將其算在內，而實際上并沒有利用。那樣是不對的，這篇文章中我強調的是解釋問題并提出對策，并且，這個指標也有技術上的問題。

結論

CPU利用率已成為一個極具誤導性的指標：它算進了等待主存的周期，而這類周期在現(xiàn)代的CPU負載中占據不少。如果使用額外指標，你就能搞清楚%CPU到底意味著什么，包括每CPU周期執(zhí)行指令數（IPC）。IPC < 1.0可能意味著你的應用是內存密集型，而IPC > 1.0則可能是指令密集型。我在之前的一篇文章，顯示%CPU的性能監(jiān)控產品也應該顯示PMC測量指標，并給予充分解釋，這樣才不會誤導用戶。比如，它們可以一起顯示%CPU和IPC，或者指令周期與怠速周期。有了這些指標，開發(fā)或管理人員才能在應用和操作系統(tǒng)中選擇正確的調優(yōu)方式。

感謝你能夠認真閱讀完這篇文章，希望小編分享的“CPU利用率如何計算”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業(yè)資訊頻道，更多相關知識等著你來學習!