如何正確理解 CPU 使用率和平均負載的關係?看完你就知道了

CPU(Central Processing Unit)是計算機系統的運算和控制核心,是信息處理、程序運行的最終執行單元,相當於系統的“大腦”。當 CPU 過於繁忙,就像“人腦”併發處理過多的事情,會降低做事的效率,嚴重時甚至會導致崩潰“宕機”。因此,理解 CPU 的工作原理,合理控制負載,是保障系統穩定持續運行的重要手段。

 

CPU 的物理核與邏輯核


一臺機器可能包含多塊 CPU 芯片,多個 CPU 之間通過系統總線通信。

一塊 CPU 芯片可能包含多個物理核,每個物理核都是一個實打實的運算核心(包括運算器、存儲器等)。

超線程(Hyper-Threading)技術可以讓一個物理核在單位時間內同時處理兩個線程,變成兩個邏輯核。但它不會擁有傳統單核 2 倍的處理能力,也不可能提供完整的並行處理能力。

舉個例子,假設一個 CPU 芯片就是一個班級;它有 2 個物理核,也就是 2 個同學,老師讓他們分別擔任班長和體育委員;過了一段時間,校長要求每個班級還要有學習委員和生活委員,理論上還需要 2 位同學,但是這個班級只有 2 個人,最後老師只能讓班長和體育委員兼任。

 

這樣一來,對於不瞭解的人來說,這個班級有班長、體育委員、學習委員和生活委員 4 個職位,應該有 4 個人,每個職位就是一個邏輯核;但是,實際上這個班級只有 2 位同學,也就是隻有 2 個物理核,雖然他們可以做 4 份工作,但是不能把他們當做 4 個人。

 

 

 

如何查詢 CPU 信息?


在 Linux 系統下,可以從 /proc/cpuinfo 文件中讀取 CPU 信息,如下圖所示:

查看 CPU 個數:

cat /proc/cpuinfo | grep 'physical id' | sort | uniq | wc -l

查看 CPU 物理核數:

cat /proc/cpuinfo | grep 'cpu cores' | sort | uniq

查看 CPU 邏輯核數:

cat /proc/cpuinfo | grep 'siblings' | sort | uniq

 

什麼是 CPU 使用率?


CPU 使用率就是 CPU 非空閒態運行的時間佔比,它反映了 CPU 的繁忙程度。比如,單核 CPU 1s 內非空閒態運行時間爲 0.8s,那麼它的 CPU 使用率就是 80%;雙核 CPU 1s 內非空閒態運行時間分別爲 0.4s 和 0.6s,那麼,總體 CPU 使用率就是 (0.4s + 0.6s) / (1s * 2) = 50%,其中 2 表示 CPU 核數,多核 CPU 同理。

在 Linux 系統下,使用 top 命令查看 CPU 使用情況,可以得到如下信息:

Cpu(s): 0.2%us, 0.1%sy, 0.0%ni, 77.5%id, 2.1%wa, 0.0%hi, 0.0%si, 20.0%st
  • us(user):表示 CPU 在用戶態運行的時間百分比,通常用戶態 CPU 高表示有應用程序比較繁忙。典型的用戶態程序包括:數據庫、Web 服務器等。

  • sy(sys):表示 CPU 在內核態運行的時間百分比(不包括中斷),通常內核態 CPU 越低越好,否則表示系統存在某些瓶頸。

  • ni(nice):表示用 nice 修正進程優先級的用戶態進程執行的 CPU 時間。nice 是一個進程優先級的修正值,如果進程通過它修改了優先級,則會單獨統計 CPU 開銷。

  • id(idle):表示 CPU 處於空閒態的時間佔比,此時,CPU 會執行一個特定的虛擬進程,名爲 System Idle Process。

  • wa(iowait):表示 CPU 在等待 I/O 操作完成所花費的時間,通常該指標越低越好,否則表示 I/O 存在瓶頸,可以用 iostat 等命令做進一步分析。

  • hi(hardirq):表示 CPU 處理硬中斷所花費的時間。硬中斷是由外設硬件(如鍵盤控制器、硬件傳感器等)發出的,需要有中斷控制器參與,特點是快速執行。

  • si(softirq):表示 CPU 處理軟中斷所花費的時間。軟中斷是由軟件程序(如網絡收發、定時調度等)發出的中斷信號,特點是延遲執行。

  • st(steal):表示 CPU 被其他虛擬機佔用的時間,僅出現在多虛擬機場景。如果該指標過高,可以檢查下宿主機或其他虛擬機是否異常。

由於 CPU 有多種非空閒態,因此,CPU 使用率計算公式可以總結爲:CPU 使用率 = (1 - 空閒態運行時間/總運行時間) * 100%。

根據經驗法則, 建議生產系統的 CPU 總使用率不要超過 70%。

 

 

什麼是平均負載?


平均負載(Load Average)是指單位時間內,系統處於 可運行狀態(Running / Runnable) 和 不可中斷態 的平均進程數,也就是 平均活躍進程數。

 

可運行態進程包括正在使用 CPU 或者等待 CPU 的進程;不可中斷態進程是指處於內核態關鍵流程中的進程,並且該流程不可被打斷。比如當進程向磁盤寫數據時,如果被打斷,就可能出現磁盤數據與進程數據不一致。不可中斷態,本質上是系統對進程和硬件設備的一種保護機制。

 

在 Linux 系統下,使用 top 命令查看平均負載,可以得到如下信息:

load average: 1.09, 1.12, 1.52

這 3 個數字分別表示 1分鐘、5分鐘、15分鐘內系統的平均負載。該值越小,表示系統工作量越少,負荷越低;反之負荷越高。

 

 

平均負載爲多少更合理?


理想情況下,每個 CPU 應該滿負荷工作,並且沒有等待進程,此時,平均負載 = CPU 邏輯核數。

但是,在實際生產系統中,不建議系統滿負荷運行。通用的經驗法則是:平均負載 = 0.7 * CPU 邏輯核數。

  • 當平均負載持續大於 0.7 * CPU 邏輯核數,就需要開始調查原因,防止系統惡化;

  • 當平均負載持續大於 1.0 * CPU 邏輯核數,必須尋找解決辦法,降低平均負載;

  • 當平均負載持續大於 5.0 * CPU 邏輯核數,表明系統已出現嚴重問題,長時間未響應,或者接近死機。

除了關注平均負載值本身,我們也應關注平均負載的變化趨勢,這包含兩層含義。一是 load1、load5、load15 之間的變化趨勢;二是歷史的變化趨勢。

  • 當 load1、load5、load15 三個值非常接近,表明短期內系統負載比較平穩。此時,應該將其與昨天或上週同時段的歷史負載進行比對,觀察是否有顯著上升。

  • 當 load1 遠小於 load5 或 load15 時,表明系統最近 1 分鐘的負載在降低,而過去 5 分鐘或 15 分鐘的平均負載卻很高。

  • 當 load1 遠大於 load5 或 load15 時,表明系統負載在急劇升高,如果不是臨時性抖動,而是持續升高,特別是當 load5 都已超過 0.7 * CPU 邏輯核數 時,應調查原因,降低系統負載。

 

CPU 使用率與平均負載的關係


CPU 使用率是單位時間內 CPU 繁忙程度的統計。而平均負載不僅包括正在使用 CPU 的進程,還包括等待 CPU 或 I/O 的進程。因此,兩者不能等同,有兩種常見的場景如下所述:

  • CPU 密集型應用,大量進程在等待或使用 CPU,此時 CPU 使用率與平均負載呈正相關狀態。

  • I/O 密集型應用,大量進程在等待 I/O,此時平均負載會升高,但 CPU 使用率不一定很高。

爲了更深入的理解 CPU 使用率與平均負載的關係,我們舉一個例子:假設現在有一個電話亭,有 4 個人在等待打電話,電話亭同一時刻只能容納 1 個人打電話,只有拿起電話筒纔算是真正使用。

 

那麼 CPU 使用率就是拿起電話筒的時間佔比,它只取決於在電話亭裏的人的行爲,與平均負載沒有非常直接的關係。而平均負載是指在電話亭裏的人加上排隊的總人數,如下圖所示:

 

 

性能優化實戰


無論是 CPU 使用率,還是平均負載,都只是反映系統健康狀態的度量指標,而不是問題的根因。因此,它們的價值主要體現在兩個方面:一是綜合反映當前系統的健康程度,結合監控告警產品,實現快速響應;二是初步定位問題方向,縮小排查範圍,降低故障恢復時間。比如當 CPU iowait 高時,應優先排查磁盤 I/O;當 CPU steal 高時,就優先排查宿主機狀態。

 

CPU 涵蓋的問題場景有很多,限於篇幅限制,下面以最常見的用戶態 CPU 使用率高爲例,介紹下 Java 應用的排查思路。

 

 

如何排查用戶態 CPU 使用率高?


用戶態 CPU 使用率反映了應用程序的繁忙程度,通常與我們自己寫的代碼息息相關。因此,當你在做應用發佈、配置變更或性能優化時,如果想定位消耗 CPU 最多的 Java 代碼,可以遵循如下思路:

1、通過 top 命令找到 CPU 消耗最多的進程號;

2、通過 top -Hp 進程號 命令找到 CPU 消耗最多的線程號(列名仍然爲 PID);

3、通過printf "%x\n" 線程號 命令輸出該線程號對應的 16 進制數字;

4、通過 jstack 進程號 | grep 16進制線程號  -A 10 命令找到 CPU 消耗最多的線程方法堆棧。

上述方法是目前業界最常用的診斷流程,如果是非 Java 應用,可以將 jstack 替換爲 perf。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章