1.什么是平均負載?(load average)
平均負載是指單位時間內平均活躍進程數，包括可運行狀態的進程數，以及不可中斷狀態的進程(如等待IO,等待硬件設備響應)
2.如何查看平均負載？
使用top,uptime查看，分別顯示過去1分鍾，5分鍾，15分鍾的平均負載
3.平均負載的性能指標？
(1).平均負載等於邏輯CPU個數，說明每個CPU都被充分利用
(2).當平均負載超過CPU個數70%，說明負載比較高
(3).如果1分鍾，5分鍾，15分鍾的負載相差不大，或者基本相同，說明系統負載很平穩
(4).如果1分鍾負載遠大於15分鍾，說明系統負載在逐漸升高
(5).如果1分鍾負載遠小於15分鍾，說明系統負載在逐漸降低
4.平均負載高的場景？
(1).CPU密集型進程，導致平均負載和CPU使用率比較高
(2).IO密集型進程，等待IO會導致平均負載升高，但是CPU使用率不一定高
(3).等待CPU的進程調度也會導致平均負載升高，此時CPU使用率也高
(4).使用mpstat,pidstat可以分析負載來源
5.案例演示：
(1).案例准備：
1.Linux環境，ubantu 18.04，機器配置：2cpu,8GB內存，預先安裝stress和sysstat，如 apt install stress sysstat
stress是linux系統的壓力測試工具，這里我們用作異常進程模擬平均負載升高的場景
而sysstat包含了常用的linux性能工具，用來監控和分析系統的性能。我們的案例會用到這個包的兩個命令mpstat和pidstat
mpstat是一個常用的多核CPU性能分析工具，用來實時查看每個CPU的性能指標，以及所有CPU的平均指標。
pidstat是一個常用的進程性能分析工具，用來實時查看進程的CPU,內存,IO以及上下文切換等性能指標。
此外，每個場景都需要你開三個終端，登錄到同一台linux機器中
如果上面的要求都完成了，可以先用uptime 命令，看一下測試前的平均負載情況：
uptime
load average: 0.11, 0.15, 0.09
1.場景1：CPU密集型進程
首先，我們在第一個終端運行stress命令，模擬一個cpu使用率100%的場景：
stress --cpu 1 --timeout 600
接着，在第二個終端運行uptime查看平均負載的變化情況：
# -d 參數表示高亮顯示變化的區域
$ watch -d uptime
load average: 1.00, 0.75, 0.39
最后，在第三個終端運行mpstat查看cpu使用率的變化情況：
# -P ALL 表示監控所有 CPU，后面數字 5 表示間隔 5 秒后輸出一組數據
$ mpstat -P ALL 5
Linux 4.15.0 (ubuntu) 09/22/18 _x86_64_ (2 CPU)
13:30:06 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
13:30:11 all 50.05 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 49.95
13:30:11 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
13:30:11 1 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
在終端2中可以看到1分鍾的平均負載會慢慢增加到1，而從終端三中還可以看到，正好有一個CPU的使用率為100%，但它的iowait
只有0。這說明，平均負載的升高正是由於CPU使用率為100%。
那么，到底是哪個進程導致了CPU使用率為100%呢？可以用pidstat 來查詢：
# 間隔 5 秒后輸出一組數據
$ pidstat -u 5 1
13:37:07 UID PID %usr %system %guest %wait %CPU CPU Command
13:37:12 0 2962 100.00 0.00 0.00 0.00 100.00 1 stress
從這里可以看出，stress進程的CPU使用率為100%。
2.場景二：I/O密集型進程：
首先還是運行stress命令，但這次模擬IO壓力，即不停的執行sync：
stress -i 1 --timeout 600
還是在第二個終端運行uptime查看平均負載的變化情況：
watch -d uptime
load average: 1.06, 0.58, 0.37
然后，在第三個終端運行mpstat查看CPU使用率的變化情況：
# 顯示所有 CPU 的指標，並在間隔 5 秒輸出一組數據
$ mpstat -P ALL 5 1
Linux 4.15.0 (ubuntu) 09/22/18 _x86_64_ (2 CPU)
13:41:28 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
13:41:33 all 0.21 0.00 12.07 32.67 0.00 0.21 0.00 0.00 0.00 54.84
13:41:33 0 0.43 0.00 23.87 67.53 0.00 0.43 0.00 0.00 0.00 7.74
13:41:33 1 0.00 0.00 0.81 0.20 0.00 0.00 0.00 0.00 0.00 98.99
從這里可以看出，1分鍾的平均負載會慢慢增加到1.06，其中一個cpu的系統CPU使用率升高到了23.87，而iowait高達67.53%。這說明，平均負載的升高
正是由於iowait的升高。
那么，到底是哪個進程導致了iowait的升高呢？我們還是用pidstat來查詢：
# 間隔 5 秒后輸出一組數據，-u 表示 CPU 指標
$ pidstat -u 5 1
Linux 4.15.0 (ubuntu) 09/22/18 _x86_64_ (2 CPU)
13:42:08 UID PID %usr %system %guest %wait %CPU CPU Command
13:42:13 0 104 0.00 3.39 0.00 0.00 3.39 1 kworker/1:1H
13:42:13 0 109 0.00 0.40 0.00 0.00 0.40 0 kworker/0:1H
13:42:13 0 2997 2.00 35.53 0.00 3.99 37.52 1 stress
13:42:13 0 3057 0.00 0.40 0.00 0.00 0.40 0 pidstat
可以發現，還是stress進程導致的。
3.場景三：大量進程的場景：
當系統中運行進程超出CPU運算能力時，就會出現等待CPU的進程。
比如，我們還是使用stress,但這次是模擬的8個進程：
stress -c 8 --timeout 600
由於系統只有2個CPU,明顯比8個進程少得多，因而，系統的CPU處於嚴重過載狀態，平均負載高達7.97:
uptime
..., load average: 7.97, 5.93, 3.02
接着再運行pidstat來看一下進程的情況：
# 間隔 5 秒后輸出一組數據
$ pidstat -u 5 1
14:23:25 UID PID %usr %system %guest %wait %CPU CPU Command
14:23:30 0 3190 25.00 0.00 0.00 74.80 25.00 0 stress
14:23:30 0 3191 25.00 0.00 0.00 75.20 25.00 0 stress
14:23:30 0 3192 25.00 0.00 0.00 74.80 25.00 1 stress
14:23:30 0 3193 25.00 0.00 0.00 75.00 25.00 1 stress
14:23:30 0 3194 24.80 0.00 0.00 74.60 24.80 0 stress
14:23:30 0 3195 24.80 0.00 0.00 75.00 24.80 0 stress
14:23:30 0 3196 24.80 0.00 0.00 74.60 24.80 1 stress
14:23:30 0 3197 24.80 0.00 0.00 74.80 24.80 1 stress
14:23:30 0 3200 0.00 0.20 0.00 0.20 0.20 0 pidstat
可以看出，8個進程在爭搶2個CPU，每個進程等待CPU的時間(也就是代碼塊中的%wait列)高達75%。
這些超出CPU計算能力的進程，最終導致CPU過載。