什么是平均負載

系統平均負載是可運行或不中斷的平均進程數。
處于可運行狀態的進程正在使用CPU或等待使用CPU。無限的過程
可中斷狀態正在等待某些I / O訪問，例如，等待磁盤。取三項平均值
時間間隔。負載平均沒有針對系統中的CPU數量標準化，因此負載平均為1
表示一直裝載單個CPU系統，而在4個CPU系統上則意味著75％的時間處于空閑狀態

如何查看系統的平均負載

uptime 命令

例如

uptime
 16:00:44 up 2 min,  0 users,  load average: 0.52, 0.58, 0.59

uptime 命令的平均負載值和cpu數量有密切的關系

平均負載案例分析

下?，我們以三個示例分別來看這三種情況，并? IOStat、mpstat、pidstat 等?具，找出平均負載升?的根源。

因為案例分析都是基于機器上的操作，所以不要只是聽聽、看看就夠了，最好還是跟著我實際操作?下。

你的準備

下?的案例都是基于 Ubuntu 18.04，當然，同樣適?于其他 linux 系統。我使?的案例環境如下所示。

機器配置：2 CPU，8GB 內存。預先安裝 stress 和 sysstat 包，如 apt install stress sysstat。

在這?，我先簡單介紹?下 stress 和 sysstat。

stress 是?個 Linux 系統壓?測試?具，這?我們?作異常進程模擬平均負載升?的場景。

? sysstat 包含了常?的 Linux 性能?具，?來監控和分析系統的性能。我們的案例會?到這個包的兩個命令 mpstat 和pidstat。

mpstat 是?個常?的多核 CPU 性能分析?具，?來實時查看每個 CPU 的性能指標，以及所有CPU的平均指標。

pidstat 是?個常?的進程性能分析?具，?來實時查看進程的 CPU、內存、I/O 以及上下?切換等性能指標。

此外，每個場景都需要你開三個終端，登錄到同?臺 Linux 機器中。

實驗之前，你先做好上?的準備。如果包的安裝有問題，可以先在google?下??解決，如果還是解決不了，再來留?區找

我，這事?應該不難。

另外要注意，下?的所有命令，我們都是默認以 root ?戶運?。所以，如果你是?普通?戶登陸的系統，一定要先運? sudo

su root 命令切換到 root ?戶。

如果上?的要求都已經完成了，你可以先? uptime 命令，看一下測試前的平均負載情況：

$ uptime

..., load average: 0.11, 0.15, 0.09

場景?：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從終端?中可以看到，1 分鐘的平均負載會慢慢增加到 1.00，?從終端三中還可以看到，正好有?個 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%。

場景?：I/O 密集型進程

?先還是運? stress 命令，但這次模擬 I/O 壓?，即不停地執? 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 進程導致的。

場景三：?量進程的場景

當系統中運?進程超出 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 過載。