什麼是Linux平均負載

時間 2019-12-14

標籤什麼 linux 平均負載欄目 Linux 简体版

原文原文鏈接

每當發現系統變慢時，能夠執行top或者uptime命令，來了解系統的負載狀況。ios

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

前幾列分別是當前時間，系統運行時間，以及正在登陸用戶數。ubuntu

02:34:03 // 當前時間centos

up 2 days, 20:14 // 系統運行時間bash

1 user // 正在登陸用戶數工具

而最後三個數字依次則是過去1分鐘，5分鐘，15分鐘的平均負載（load average）平均負載簡單來講，是指單位時間內，系統處於可運行狀態和不可中斷狀態的平均進程數，也就是平均活躍進程數，它和cpu使用率並無直接關係。所謂可運行狀態的進程，是指正在使用CPU或者正在等待CPU的進程，也就是咱們經常使用ps命令看到的，處於R狀態（Running或Runnable）的進程。不可中斷狀態的進程則是正處於內核態關鍵流程中的進程，而且這些流程是不可打斷的，好比最多見的是等待硬件設備的i/o響應，也就是咱們ps看到的D狀態（Uninterruptible sleep，也稱爲disk sleep）的進程性能

好比，當一個進程向磁盤讀寫數據時，爲了保證數據的一致性，在獲得磁盤迴復前，它是不能被其餘進程或者中斷打斷的，這個時候的進程就處於不可中斷狀態。若是此時的進程被打斷了，就容易出現磁盤數據與進程數據不一致的問題因此，不可中斷狀態其實是系統對進程和硬件設備的一種保護機制。能夠簡單理解爲，平均負載其實就是平均活躍進程數。平均活躍進程數，直觀上的理解就是單位時間內的活躍進程數，但它其實是活躍進程數的指數衰減平均值。這個「指數衰減平均」的詳細含義不用計較，這只是系統的一種更快速的計算方式，你把它直接當成活躍進程數的平均值也沒問題。測試

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

。在只有2個CPU的系統上，意味着全部的CPU都恰好被徹底佔用。ui

。在4個CPU的系統上，意味着CPU有50%的空閒。spa

。而在只有1個CPU的系統上，則意味着有一半的進程競爭不到CPU

平均負載多少爲合理？平均負載最理想的狀況是等於CPU個數。因此在評判平均負載時，首先要知道系統有幾個CPU，這能夠經過top命令或者從文件/proc/cpuinfo中讀取，例如：

$ grep 'model name' /proc/cpuinfo | wc -l
2
複製代碼

有了CPU個數，咱們就能夠判斷出，當平均負載比CPU個數還大的時候，系統已經出現了過載。不過平均負載有三個數值，應該參考哪個？實際上，都要看。三個不一樣時間間隔的平均值其實給咱們提供了分析系統負載趨勢的數據來源，讓咱們能更全面，更立體地理解目前的負載情況。

。若是1分鐘，5分鐘，15分鐘的三個值基本相同，或者相差不大，那就說明系統負載很平穩。

。但若是1分鐘的值遠小於15的值，就說明系統最近1分鐘的負載在減小，而過去15分鐘內卻有很大的負載。

。反過來，若是1分鐘的值遠大於15分鐘的值，就說明最近1分鐘的負載在增長，這種增長有可能只是臨時性的，也有可能還會持續增長下去，因此就須要持續觀察。一旦1分鐘的平均負載接近或超過了CPU的個數，就意味着系統正在發生過載的問題，這是就得分析調查是哪裏致使的問題，並要想辦法優化了。

舉例說，假設咱們在一個單CPU系統上看到平均負載爲1.7， 0.60， 7.89 那麼說明在過去1分鐘內，系統有73%的超載，而在15分鐘內，有689%的超載，從總體趨勢來看，系統的負載在下降。

在實際生產環境中，當平均負載高於CPU數量70%的時候，就應分析排查負載高的問題了。一旦負載太高，就可能致使進程響應慢，進而影響服務的正常功能。但70%這個數字並非絕對的，最推薦的方法仍是把系統的平均負載監控起來，而後根據更多的歷史數據，判斷負載的變化趨勢。當發現負載有明顯升高趨勢時，好比說負載翻倍了，再去作分析和調查。

#平均負載與CPU使用率

現實工做中，咱們常常容易把平均負載和CPU使用率混淆。

平均負載是指單位時間內，處於可運行狀態和不可中斷狀態的進程數。因此，它不只包扣了正在使用CPU的進程，還包扣等待CPU和等待i/o的進程。而CPU使用率，是單位時間內CPU繁忙狀況的統計，跟平均負載並不必定徹底對應。好比：

。CPU密集型進程，使用大量CPU會致使平均負載升高，此時這二者是一致的

。i/o密集型進程，等待i/o也會致使平均負載升高，但CPU使用率不必定很高。

。大量等待CPU的進程調度也會致使平均負載升高，此時的CPU使用率也會比較高。

平均負載案例分析以三個示例分別來看這三種狀況，並用iostat ，mpstat ，pidstat等工具，找出平均負載升高的根源

下面的案例都是基於Ubuntu 18.04

預先安裝stress 和sysstat包，如apt install stress sysstat

Stress是一個Linux系統壓力測試工具，而sysstat包含了經常使用的Linux性能工具，用來監控和分析系統的性能。

。mpstat是一個經常使用的多核cpu性能分析工具，用來實時查看每一個CPU的性能指標，以及全部CPU的平均指標

。pidstat是一個經常使用的進程性能分析工具，用來實時查看進程的CPU，內存，i/o以及上下文切換等性能指標

上面說起的全部命令默認以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%

可使用pidstat來查詢是那個進程致使了CPU使用率爲100%：

# 間隔 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的升高。咱們能夠用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過載。

總結：

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

。平均負載有多是CPU密集型進程致使的

。平均負載高並不必定表明CPU使用率高，還有多是i/o更繁忙了

。當發現負載高的時候，可使用mpstat，pidstat等工具，輔助分析負載的來源。

注意：

1.iowait沒法升高的問題，是由於案例中stress使用的是sync（）系統調用，它的做用是刷新緩衝區內存到磁盤中。對於新安裝的虛擬機，緩衝區可能比較小，沒法產生大的io壓力，這樣大部分就都是系統調用的消耗了。因此，會看到只有系統cpu使用率升高。解決方法是使用stress的下一代stress-ng，它支持更豐富的選項，好比stress-ng -i 1 --hdd 1 –timeout 600 (--hdd表示讀寫臨時文件)

2.pidstat輸出中沒有%wait的問題，是由於centos默認的sysstat稍微有點老，源碼或者RPM升級到11.5.5版本之後就能夠看到了。而Ubuntu的包通常都比較新，沒有這個問題。

3.mpstat沒法觀測的問題，案例中是等待5秒後輸出1次結果就中止了，更好的作法是持續監控一段時間，好比持續觀測20次： mpstat –P ALL 5 20