一文讓你明白平均負載

1. 什麼是平均負載

首先，咱們先理解下什麼是平均負載。

平均負載是指單位時間內，系統處於可運行狀態和不可中斷狀態的平均進程數，也就是平均活躍進程數，它和 CPU 使用率並無直接關係。（爲何和 CPU 使用率沒直接關係，這個我後面說明）

那麼問題來了，可運行狀態和不可中斷狀態又是什麼東西呢？

所謂可運行狀態的進程，是指正在使用 CPU 或者正在等待 CPU 的進程，也就是咱們經常使用 ps 命令看到的，處於 R 狀態（Running 或 Runnable）的進程。

而不可中斷狀態的進程，則是正處於內核態關鍵流程中的進程，而且這些流程是不可打斷的，好比最多見的是等待硬件設備的 I/O 響應，也就是咱們在 ps 命令中看到的 D 狀態（Uninterruptible Sleep，也稱爲 Disk Sleep）的進程。

好比，當一個進程向磁盤讀寫數據時，爲了保證數據的一致性，在獲得磁盤迴復前，它是不能被其餘進程或者中斷打斷的，這個時候的進程就處於不可中斷狀態。若是此時的進程被打斷了，就容易出現磁盤數據與進程數據不一致的問題。

因此，不可中斷狀態其實是系統對進程和硬件設備的一種保護機制。

明白了什麼是平均負載後，那麼天然就是要知道怎麼用了。

2. 如何查看平均負載

當咱們使用 uptime 命令時，會出現如下結果（這是我本機的結果，每一個人的機器狀況不同）

$ uptime
02:34:03 up 2 days, 20:14,  1 user,  load average: 0.63, 0.83, 0.88
複製代碼

對應解釋：

02:34:03              // 當前時間
up 2 days, 20:14      // 系統運行時間
1 user                // 正在登陸用戶數

最後三個數字呢，依次則是過去 1 分鐘、5 分鐘、15 分鐘的平均負載（Load Average）。
複製代碼

明白了怎麼看平均負載後，那麼平均負載究竟是多少纔是合理的呢？

3. 平均負載的合理值

當平均負載高於 CPU 數量 70% 的時候。就應該分析排查負載高的問題了。一旦負載太高，就可能致使進程響應變慢，進而影響服務的正常功能。

但 70% 這個數字並非絕對的，最推薦的方法，仍是把系統的平均負載監控起來，而後根據更多的歷史數據，判斷負載的變化趨勢（可從 uptime 獲得的三個數字分析）。當發現負載有明顯升高趨勢時，好比說負載翻倍了，你再去作分析和調查。

平均負載在最理想的狀況下，就是每一個 CPU 上都恰好運行着一個進程，這樣每一個 CPU 都獲得了充分利用。

好比當平均負載爲 2 時，意味着什麼呢？

• 在只有 2 個 CPU 的系統上，意味着全部的 CPU 都恰好被徹底佔用。
• 在 4 個 CPU 的系統上，意味着 CPU 有 50% 的空閒。
• 而在只有 1 個 CPU 的系統中，則意味着有一半的進程競爭不到 CPU。

好了，關於平均負載的基本知識差很少就是這樣。如今，我來填下開頭的坑 —— 爲何和 CPU 使用率沒直接關係呢？

4. 平均負載與 CPU 使用率

在文章最開始的時候就有提到，平均負載是指單位時間內，處於可運行狀態和不可中斷狀態的平均進程數。因此，它不只包括了正在使用 CPU的進程，還包括等待 CPU和等待 IO的進程。

而 CPU 使用率，是單位時間內 CPU 繁忙狀況的統計，跟平均負載並不必定徹底對應。好比：

• CPU 密集型進程，使用大量 CPU 會致使平均負載升高，此時這二者是一致的。
• I/O 密集型進程，等待 I/O 也會致使平均負載升高，但 CPU 使用率不必定很高。
• 大量等待 CPU 的進程調度也會致使平均負載升高，此時的 CPU 使用率也會比較高

以上，就是文章的所有內容了，若是以爲有幫助的話，那就點個贊吧

本文整理自極客時間：《Linux性能優化實戰》

PS：本文原創發佈於微信公衆號「不僅Java」，後臺回覆如下關鍵字獲取經典必讀書籍： Java、MySQL、Redis、Linux、mq、數據結構、設計模式、編程思想、架構。

公衆號專一分享 Java 乾貨、讀書筆記、成長思考。