Linux性能調優 | 01 平均負載的理解和分析

01 uptime命令

一般咱們發現系統變慢時，咱們都會執行top或者uptime命令，來查看當前系統的負載狀況，好比像下面，我執行了uptime，系統返回的告終果。

[root@lincoding ~]# uptime
 08:31:49 up 27 min,  1 user,  load average: 0.07, 0.04, 0.00

前幾列的信息，相信你們都很熟悉，它們分別是當前時間、系統運行時間和正在登錄的用戶個數，最後一個就是系統平均負載的狀況。

08:31:49                        // 當前時間
up 27 min                       // 系統運行時間
1 user                          // 正在登陸用戶數
load average: 0.07, 0.04, 0.00  // 平均負載的狀況

Load Average的三個數字，依次則是過去1分鐘、5分鐘、15分鐘的平均負載。能夠經過觀察這三個數字的大小，能夠簡單判斷系統的負載是降低的趨勢仍是上升的趨勢。

• 若是 load average: 1.00, 5.00, 10.00 三個數字依次增大，則說明在過去的 1 分鐘系統的負載比過去 15 分鐘系統的負載小，代表系統的負載是降低的趨勢。
• 若是 load average: 10.00, 5.00, 1.00 三個數字依次下降，則說明在過去的 1 分鐘系統的負載比過去 15 分鐘系統的負載大，代表系統的負載是上升的趨勢。
• 若是 load average: 0.07, 0.04, 0.0 三個數字基本相同，或者相差不大， 代表系統的負載是平穩的。

因此分析系統的負載狀況，必需要看三個不一樣時間間隔的平均值。

---

02 平均負載概念

平均負載不少人容易理解成單位時間內的 CPU 使用率，這是不正確的。平均負載確實與 CPU 使用率有關係，但不是直接的關係。

簡單來講，平均負載是指單位時間內，系統處於可運行狀態和不可中斷狀態的平均進程數，也就是平均活躍進程數，它和 CPU 使用率並無直接關係。

• 可運行狀態，是指正在使用 CPU 或者正在等待 CPU 的進程，也就是在 ps 命令看到的 R 狀態的進程。
• 不可中斷狀態，是指正處於內核關鍵流程中的進程，而且這些流程是不能夠打斷的，好比最多見的等待硬件設備的 I/O 響應，也就是在 ps 命令看到的 D 狀態的進程。

所以，平均負載其實就是平均活躍進程數，能夠更直觀的理解成單位時間內的活躍進程數。

既然平均的是活躍進程數，那麼最理想的，就是每一個CPU上恰好運行着一個進程，這樣每一個CPU就獲得了充分利用。
好比當平均負載爲2時，意味着：

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

---

03 平均負載爲多少時合理

在評判你當前的系統平均負載是否合理的時，首先你要知道系統有幾個 CPU，能夠經過 lscpu 命令或者從文件 /proc/cpuinfo 中讀取

# lscpu 命令查看 CPU 個數
[root@lincoding ~]# lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4 # 這裏數字表示 CPU 個數        
....

# 從文件 /proc/cpuinfo 中查看 CPU 個數
[root@lincoding ~]# grep 'model name' /proc/cpuinfo | wc -l
4

有了 CPU 個數，咱們就能夠判斷出，當平均負載比 CPU 個數還大的時候，系統已經出現了過載。

這裏我再舉個例子，假設咱們在一個單 CPU 系統上看到平均負載爲 1.73，0.60，7.98

• 在過去 1 分鐘內，系統有 73% 的超載
• 在過 15 分鐘內，有 698%的超載，從總體趨勢來看，系統的負載在下降。

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

---

04 平均負載與 CPU 使用率

咱們常常容易把平均負載和 CPU 使用率混淆，因此在這裏，我也作一個區分。

再次說明下，平均負載是指單位時間內，處於可運行狀態和不可中斷狀態的進程數。因此，它不只包括了正在使用 CPU 的進程，還包括等待 CPU 和等待 I/O 的進程。

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

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

---

05 平均負載升高分析命令

咱們如今很清楚的知道致使平均負載高的狀況，不僅是看 CPU 的使用率，也要觀察系統 I/O 等待時間高不高。

當發現平均負載升高時，可使用 mpstat 命令查看 CPU 的性能。

# -P ALL 表示監控全部CPU，後面數字1表示間隔1秒後輸出一組數據
$ mpstat -P ALL 1
Linux 2.6.32-431.el6.x86_64 (lzc)   11/05/2019  _x86_64_    (2 CPU)

07:51:45 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
07:51:50 PM  all   42.90    0.00   49.39    0.41    0.00    4.56    0.00    0.00    2.74
07:51:50 PM    0   44.38    0.00   48.67    0.41    0.00    2.86    0.00    0.00    3.68
07:51:50 PM    1   41.57    0.00   49.80    0.40    0.00    6.43    0.00    0.00    1.81

從上面發現

• CPU 的用戶層（%usr）使用率高達45%左右；
• CPU 的系統層（%sys）使用率高達50%左右；
• CPU 的 I/0 - 等待（%iowait）佔用率爲0.41%；
• CPU 的空閒率（%idle）只有2~3%。

能夠推斷出是因爲 CPU 使用率致使平均負載升高的狀況。

假設只有 CPU 的I/0 等待（%iowait）佔用率高，CPU 用戶層和系統層使用率很輕鬆，那麼致使平均負載升高的緣由就是 iowait 的升高。

判斷了是由於 CPU 使用率升高仍是 iowait 升高致使平均負載升高後，咱們還須要定位是哪一個進程致使的。能夠用 pidstat 來查詢：

# 間隔1秒後輸出一組數據，-u表示CPU指標
$ pidstat -u 1
08:07:55 PM       PID    %usr %system  %guest    %CPU   CPU  Command
08:07:56 PM         4    0.00    1.00    0.00    1.00     0  ksoftirqd/0
08:07:56 PM         9    0.00    1.00    0.00    1.00     1  ksoftirqd/1
08:07:56 PM        11    0.00   16.00    0.00   16.00     0  events/0
08:07:56 PM        12    0.00   20.00    0.00   20.00     1  events/1
08:07:56 PM       616    7.00    6.00    0.00   13.00     1  pppoe
08:07:56 PM      2745    6.00    6.00    0.00   12.00     1  pppoe

能夠發現是 events/0 和 events/1 內核進程 CPU 使用率很是高，因此可能這兩個進程致使平均負載升高。

---

06 小結

平均負載提供了一個快速查看系統總體性能的手段，反映了總體的負載狀況。但只看平均負載自己，咱們並不能直接發現，究竟是哪裏出現了瓶頸。因此，在理解平均負載時，也要注意：

• 平均負載高有多是 CPU 密集型進程致使的；
• 平均負載高並不必定表明 CPU 使用率高，還有多是 I/O 更繁忙了；
• 當發現負載高的時候，你可使用 mpstat、pidstat 等工具，輔助分析負載的來源。