序言
平均負載表示了對CPU 資源的需求，通過彙總正在運作的線程數（使用率）和正在排隊等待運作的線程數（飽和度）計算得出。計算平均負載的一個新方法是把使用率加上線程排程器延時得出，而不是去取樣隊列長度，進而提高精度。
這個值的意義為，平均負載大于CPU 數量表示CPU 不足以服務線程，有些線程在等待。如果平均負載小于CPU 數量，這（很可能）代表還有一些餘量，線程可以在它們想要的時候在CPU 上運作。
Uptime
在了解平均負載前我們先來了解下uptime指令，當我們Android系統運作慢的時候，uptime會是我們首先運作的指令：
whyred:/ # uptime
18:12:13 up 4 days, 22:14, 0 users, load average: 6.36, 6.36, 5.62
- 18:12:13 - 目前時間
- up 4 days, 22:14 - 系統運作時間
- 0 users - 正在登入使用者數
而最後三個數字呢，依次則是過去 1 分鐘、5 分鐘、15 分鐘的平均負載（Load Average）。
Linux平均負載
Linux 平均負載Linux 目前把在不可中斷狀态執行磁盤I/O 的任務也計入了平均負載。這意味着平均負載再也不能單用來表示CPU 餘量或者飽和度，因為不能單從這個值推斷出CPU 或者磁盤負載。由于負載可能會在CPU 和磁盤之間不斷變化，比較這三個平均負載數值也變得困難了。另外一種包含其他資源負載的方法是為每一種類型的資源分别使用不同的平均負載。
在Linux 上最好通過一些其他的名額了解CPU 負載，例如vmstat(1)和mpstat(1)提供的一些資料。
平均負載是指機關時間内，系統處于可運作狀态和不可中斷狀态的平均程序數，也就是平均活躍程序數，它和 CPU 使用率并沒有直接關系。- 可運作狀态的程序 ：是指正在使用 CPU 或者正在等待 CPU 的程序，也就是我們常用 ps 指令看到的，處于 R 狀态（Running 或 Runnable）的程序。
- 不可中斷狀态的程序 ：是正處于核心态關鍵流程中的程序，并且這些流程是不可打斷的，比如最常見的是等待硬體裝置的 I/O 響應，也就是我們在 ps 指令中看到的 D 狀态（Uninterruptible Sleep，也稱為 Disk Sleep）的程序。
比如，當一個程序向磁盤讀寫資料時，為了保證資料的一緻性，在得到磁盤回複前，它是不能被其他程序或者中斷打斷的，這個時候的程序就處于不可中斷狀态。如果此時的程序被打斷了，就容易出現磁盤資料與程序資料不一緻的問題。是以，不可中斷狀态實際上是系統對程序和硬體裝置的一種保護機制。
平均負載其實就是平均活躍程序數。平均活躍程序數，直覺上的了解就是機關時間内的活躍程序數，但它實際上是活躍程序數的指數衰減平均值。這個“指數衰減平均”的詳細含義你不用計較，這隻是系統的一種更快速的計算方式，你把它直接當成活躍程序數的平均值也沒問題。既然平均的是活躍程序數，那麼最理想的，就是每個 CPU 上都剛好運作着一個程序，這樣每個 CPU 都得到了充分利用。
比如當平均負載為 2 時，意味着什麼呢？
- 在隻有 2 個 CPU 的系統上，意味着所有的 CPU 都剛好被完全占用。
- 在 4 個 CPU 的系統上，意味着 CPU 有 50% 的空閑。
- 而在隻有 1 個 CPU 的系統中，則意味着有一半的程序競争不到 CPU。
平均負載為多少時合理？
我們知道，平均負載最理想的情況是等于 CPU 個數。是以在評判平均負載時，首先你要知道系統有幾個 CPU，這可以通過 top 指令或者從檔案 /proc/cpuinfo 中讀取，比如：
whyred:/ # grep 'processor' /proc/cpuinfo | wc -l
8
有了 CPU 個數，我們就可以判斷出，當平均負載比 CPU 個數還大的時候，系統已經出現了過載。不過，我們在例子中可以看到，平均負載有三個數值，到底該參考哪一個呢？
實際上，都要看。三個不同時間間隔的平均值，其實給我們提供了，分析系統負載趨勢的資料來源，讓我們能更全面、更立體地了解目前的負載狀況。
- 如果 1 分鐘、5 分鐘、15 分鐘的三個值基本相同，或者相差不大，那就說明系統負載很平穩。
- 如果 1 分鐘的值遠小于 15 分鐘的值，就說明系統最近 1 分鐘的負載在減少，而過去 15 分鐘内卻有很大的負載。
- 如果 1 分鐘的值遠大于 15 分鐘的值，就說明最近 1 分鐘的負載在增加，這種增加有可能隻是臨時性的，也有可能還會持續增加下去，是以就需要持續觀察。一旦 1 分鐘的平均負載接近或超過了 CPU 的個數，就意味着系統正在發生過載的問題，這時就得分析調查是哪裡導緻的問題，并要想辦法優化了。
平均負載與 CPU 使用率
表弟：漫話性能：CPU使用率zhuanlan.zhihu.com
現實工作中，我們經常容易把平均負載和 CPU 使用率混淆，是以在這裡，我也做一個區分。可能你會疑惑，既然平均負載代表的是活躍程序數，那平均負載高了，不就意味着 CPU 使用率高嗎？我們還是要回到平均負載的含義上來，平均負載是指機關時間内，處于可運作狀态和不可中斷狀态的程序數。是以，它不僅包括了正在使用 CPU 的程序，還包括等待 CPU 和等待 I/O 的程序。而 CPU 使用率，是機關時間内 CPU 繁忙情況的統計，跟平均負載并不一定完全對應。比如：
CPU 密集型程序
CPU 密集型程序，使用大量 CPU 會導緻平均負載升高，此時這兩者是一緻的；首先，我們在第一個終端運作 stress 指令，模拟一個 CPU 使用率 100% 的場景：
- stress
stress --cpu 1 --timeout 600
- watch
接着，在第二個終端運作 uptime 檢視平均負載的變化情況：
watch -d uptime
最後，在第三個終端運作 mpstat 檢視 CPU 使用率的變化情況：
- mpstat
mpstat -P ALL 5
從終端二中可以看到，1 分鐘的平均負載會慢慢增加到 1.00，而從終端三中還可以看到，正好有一個 CPU 的使用率為 100%，但它的 iowait 隻有 0。這說明，平均負載的升高正是由于 CPU 使用率為 100% 。
- pidstat
那麼，到底是哪個程序導緻了 CPU 使用率為 100% 呢？你可以使用 pidstat 來查詢：
pidstat -u 5 1
從這裡可以明顯看到，stress 程序的 CPU 使用率為 100%。
I/O 密集型程序
I/O 密集型程序，等待 I/O 也會導緻平均負載升高，但 CPU 使用率不一定很高；
- stress
首先還是運作 stress 指令，但這次模拟 I/O 壓力，即不停地執行 sync：
stress -i 1 --timeout 600
- watch
- mpstat
1 分鐘的平均負載會慢慢增加到 1.27，其中一個 CPU 的系統 CPU 使用率升高到了 22.95，而 iowait 高達 29.26。這說明，平均負載的升高是由于 iowait 的升高。那麼到底是哪個程序，導緻 iowait 這麼高呢？我們還是用 pidstat 來查詢：
大量程序的場景
大量等待 CPU 的程序排程也會導緻平均負載升高，此時的 CPU 使用率也會比較高。
- stress
當系統中運作程序超出 CPU 運作能力時，就會出現等待 CPU 的程序。比如，我們還是使用 stress，但這次模拟的是 8 個程序：
stress -c 8 --timeout 600
- watch
- mpstat
從mpstat的輸出看，8個核心都跑滿了。
- pidstat
小結
分析完這三個案例，我們再來複習一下平均負載的了解。平均負載提供了一個快速檢視系統整體性能的手段，反映了整體的負載情況。但隻看平均負載本身，我們并不能直接發現，到底是哪裡出現了瓶頸。是以，在了解平均負載時，也要注意：
- 平均負載高有可能是 CPU 密集型程序導緻的；
- 平均負載高并不一定代表 CPU 使用率高，還有可能是 I/O 更繁忙了；
- 當發現負載高的時候，你可以使用 mpstat、pidstat 等工具，輔助分析負載的來源。