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


  CPU(Central Processing Unit)是計算機系統的運算和控制核心,是信息處理、程序運行的最終執行單元,相當於系統的“大腦”。

  當 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 的進程,還包括等待 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 使用率反映了應用程序的繁忙程度,通常與我們自己寫的代碼息息相關。因此,當你在做應用發布、配置變更或性能優化時,如果想定位消耗 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,推薦閱讀 《Perf — Linux下的系統性能調優工具》。

 

  然而,上述方法有兩個顯著缺陷,一是操作流程復雜,而且往往一次 jstack 還不足以定位根因,需要執行多次;二是只能用於診斷在線問題,如果問題已經發生,無法復現的話,往往只能不了了之。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM