系統變慢第一件事就是執行top或者uptime命令，來了解系統的負載情況，比如下面

[[email protected] ~]# uptime

 15:11:14 up 63 days,  5:03,  2 users,  load average: 0.00, 0.02, 0.05

15:11:14    //當前時間

up 63 days,  5:03  //系統執行時間

2 users //正在登陸使用者數

load average: 0.00, 0.02, 0.05 ，依次是過去1分鐘、5分鐘、15分鐘的平均負載。

--平均負載

，單位時間內，系統處於可執行狀態和不可中斷狀態的平均程序數，也就是平均活躍程序數，它和cpu使用率並沒有直接關係。

所謂可執行狀態的程序，是指正在使用cpu或者等待cpu的程序，也就是ps命令經常看見的，處於R狀態(running或runnable)的程序。

不可中斷的程序則是正處於核心態關鍵流程中的程序，並且這些流程是不可打斷，比如最常見的是等待硬體裝置的IO響應，也就是在ps命令看到的D狀態(uninterruptible Sleep，也稱為Disk Sleep)的程序。

  比如，當一個程序向磁碟寫資料時，為了保證資料的一致性，在得到磁盤迴復前，它是不能被其他程序或者中斷打斷的，這時候的程序就處於不箇中斷狀態。如果此時的程序被打斷了，就容易出現磁碟資料與程序資料不一致的問題。

  所以，不可中斷狀態實際上是系統對程序和硬體裝置的一種保護機制。

可以簡單理解為，平均負載其實就是平均活躍程序數。直觀上的理解就是單位時間內活躍的程序數，但它實際上是活躍程序數的指數衰減平均值。可以直接當成活躍程序的平均值也沒問題。

既然是平均活躍程序數，最理想就是每個cpu上都剛好執行一個程序，這樣每個cpu都得到充分利用。當負載為2：

--在只有2個cpu的系統上，意味著所有的cpu都剛好被完全佔用

--在4個cpu的系統，意味著cpu有50%的空閒

--在只有1個cpu的系統上，有一半的程序競爭不到cpu

平均負載為多少時合適

在uptime出現的3

平均負載最理想的情況是等於cpu數，所以在判斷平均負載時，首先知道cpu

[[email protected] ~]# grep 'model name' /proc/cpuinfo  | wc -l

1

# 總核數 = 物理CPU個數 X 每顆物理CPU的核數

# 總邏輯CPU數 = 物理CPU個數 X 每顆物理CPU的核數 X 超執行緒數

# 檢視物理CPU個數

cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l

# 檢視每個物理CPU中core的個數(即核數)

cat /proc/cpuinfo| grep "cpu cores"| uniq

# 檢視邏輯CPU的個數

cat /proc/cpuinfo| grep "processor"| wc -l

檢視CPU資訊（型號）

cat /proc/cpuinfo | grep name | cut -f2 -d: | uniq -c

uptime的3個平均負載值，都需要看，分析系統負載趨勢的資料來源

--如果1分鐘、5分鐘、15分鐘的3個值基本相同或者相差不大，說明系統負載很平穩

--但如1分鐘的值遠小於15分鐘的值，說明最近1分鐘的負載在減少，過去15分鐘的有很大的負載

--反過來，如果1分鐘的值遠大於15分鐘，說明最近1分鐘的負載在增加，這種增加有可能是臨時性的，也可能會持續，可以持續觀察。一旦一分鐘的平均負載接近或超過cpu的個數，就意味著正在發生過載的問題，這時候就得分析。

舉個例子，假設我們在一個單cpu的系統上看到平均負載為1.73,0.60,7.98,那麼說明在過去一分鐘內，系統有73%的超載，而在15分鐘內，有698%(7.98-1)的超載,從整體趨勢上看，系統的負載在降低。

在實際生產環境中，平均負載多高時，需要我們重點關注呢

當平均負載高於cpu數量70%的時候，需要分析排查負載高的問題。一旦負載過高就可能導致程序響應變慢，進而影響服務的正常功能。

但70%的數值並不是絕對的，最推薦的方法，還是把系統的平均負載監控起來，然後根據更多的歷史資料，判斷負載的變化趨勢。當發現負載有明顯變化時，再去做分析和調查。

--平均負載和cpu使用率

平均負載不僅包括正在使用cpu的程序，還包括等待cpu和等待IO的程序。

而cpu使用率，是單位時間內cpu繁忙情況的統計：

--cpu密集型程序，使用大量cpu會導致平均負載升高，但這2者一致。

--io密集型程序，等待io也會導致平均負載升高，但cpu使用率不一定很高。

--大量等待cpu的程序排程也會導致平均負載升高，但cpu使用率也會比較高。

平均負載案例分析

下面的情況，分別使用iostat、mpstat、pidstat等工具，找出平均負載升高的根源。

環境準備：

[[email protected] ~]# yum install stress sysstat

--stress是linux系統壓力測試工具，這裡用作異常程序模擬平均負載升高的場景。

--sysstat包含常用的linux的效能工具，用來監控和分析系統的效能(mpstat,pidstat)。

--mpstat是一個常用的多核cpu效能分析工具，用來實時檢視每個cpu的效能指標，以及所有cpu的平均指標。

--pidstat用來實時檢視程序的cpu，記憶體，io以及上下午切換等效能指標。

[[email protected] ~]# uptime

 16:30:25 up 63 days,  6:22,  4 users,  load average: 0.13, 0.10, 0.12

[[email protected] soft]# wget http://people.seas.harvard.edu/~apw/stress/stress-1.0.4.tar.gz

[[email protected] soft]# tar -zxvf stress-1.0.4.tar.gz

[[email protected] soft]# cd stress-1.0.4/

[[email protected] stress-1.0.4]# ./configure

[[email protected] stress-1.0.4]# make && make install

[[email protected] stress-1.0.4]# /usr/local/bin/stress --help

場景1：cpu密集型程序

在一個終端執行stress命令，模擬1個cpu使用100%的場景

[[email protected] ~]# /usr/local/bin/stress --cpu 1 --timeout 600

stress: info: [14110] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd

在第二個終端執行uptime檢視平均負載均衡的變化情況

--# -d引數表示高亮顯示變化的區域

[[email protected] ~]# watch -d uptime

在第三個終端執行mpstat檢視cpu使用率的變化情況

--P ALL 表示監控所有cpu，後面數字5表示時間間隔

[[email protected] ~]# mpstat -P ALL 5

05:31:19 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle

05:31:24 PM  all   99.60    0.00    0.40    0.00    0.00    0.00    0.00    0.00    0.00    0.00

05:31:24 PM    0   99.60    0.00    0.40    0.00    0.00    0.00    0.00    0.00    0.00    0.00

從第二個終端看到，1分鐘的平均負載均衡會慢慢增加到1，而終端3看到，有一個cpu使用率100%，但是它的iowait只有0，說明平均負載的升高正是由於cpu使用率100%

到底哪個程序導致cpu使用率100%呢

--#間隔5秒後輸出一組資料

[[email protected] ~]# pidstat -u 5 1

Linux 3.10.0-514.ky3.kb3.x86_64 (mysqlhq) 12/03/2018 _x86_64_ (1 CPU)

05:33:59 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command

05:34:04 PM    42      2276    0.22    0.00    0.00    0.22     0  gnome-shell

05:34:04 PM     0     14111   98.71    0.00    0.00   98.71     0  stress

05:34:04 PM  1000     14899    0.22    0.22    0.00    0.43     0  mysqld

可以明顯看到stress程序的cpu使用率100%

場景2：I/O密集型程序

首先模擬stress命令，這次模擬io壓力，不停的執行sync

[[email protected] ~]# /usr/local/bin/stress -i 1 --timeout 600

stress: info: [16898] dispatching hogs: 0 cpu, 1 io, 0 vm, 0 hdd

第二個終端還是檢視uptime，平均負載

[[email protected] ~]# watch -d uptime

第三個執行mpstat檢視cpu使用率

--#顯示所有cpu的指標，並間隔5秒輸出一組資料

[[email protected] ~]# mpstat -P ALL 5

05:49:16 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle

05:49:21 PM  all    0.60    0.00   99.40    0.00    0.00    0.00    0.00    0.00    0.00    0.00

05:49:21 PM    0    0.60    0.00   99.40    0.00    0.00    0.00    0.00    0.00    0.00    0.00

[[email protected] ~]# pidstat -u 5 1

Linux 3.10.0-514.ky3.kb3.x86_64 (mysqlhq) 12/03/2018 _x86_64_ (1 CPU)

05:50:17 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command

05:50:22 PM     0         9    0.00    0.20    0.00    0.20     0  rcu_sched

05:50:22 PM  1000     14899    0.00    0.40    0.00    0.40     0  mysqld

05:50:22 PM  1001     14982    0.00    0.20    0.00    0.20     0  zabbix_agentd

05:50:22 PM     0     15470    0.20    0.20    0.00    0.40     0  watch

05:50:22 PM     0     15754    0.00    0.20    0.00    0.20     0  kworker/u2:0

05:50:22 PM     0     16899    0.00   98.80    0.00   98.80     0  stress

05:50:22 PM     0     17149    0.00    0.20    0.00    0.20     0  kworker/u2:2

檢視程序，還是stress導致cpu使用100%

場景3：大量程序的場景

當系統中執行程序超出cpu執行能力時，就會出現等待cpu的程序

使用stress，模擬8個程序

[[email protected] ~]# /usr/local/bin/stress -c 8 --timeout 600

stress: info: [5709] dispatching hogs: 8 cpu, 0 io, 0 vm, 0 hdd

由於系統只有1個cpu，檢視uptime

[[email protected] ~]# uptime

 11:17:20 up 64 days,  1:09,  6 users,  load average: 8.97, 3.92, 1.58

檢視pidstat

[[email protected] ~]# pidstat -u 5 1

Linux 3.10.0-514.ky3.kb3.x86_64 (mysqlhq) 12/04/2018 _x86_64_ (1 CPU)

11:15:50 AM   UID       PID    %usr %system  %guest    %CPU   CPU  Command

11:15:55 AM  1000      4122    2.07    2.07    0.00    4.14     0  mysqld

11:15:55 AM     0      5710   12.42    0.00    0.00   12.42     0  stress

11:15:55 AM     0      5711   12.42    0.00    0.00   12.42     0  stress

11:15:55 AM     0      5712   12.42    0.00    0.00   12.42     0  stress

11:15:55 AM     0      5713   12.22    0.00    0.00   12.22     0  stress

11:15:55 AM     0      5714   12.42    0.00    0.00   12.42     0  stress

11:15:55 AM     0      5715   12.42    0.00    0.00   12.42     0  stress

11:15:55 AM     0      5716   12.63    0.00    0.00   12.63     0  stress

11:15:55 AM     0      5717   12.22    0.00    0.00   12.22     0  stress

11:15:55 AM     0      5834    0.00    0.21    0.00    0.21     0  pidstat

可以看出，8個程序爭搶1個cpu，每個程序等待cpu的時間，每個%wait列

由於我這裡測試的是麒麟系統，可能跟centos的結果有一些不一樣(沒有%wait)

[[email protected] ~]# cat /etc/issue

\nKylin 3.3

Kernel \r on an \m

\KRelease (Trial)

也肯能是版本sysstat比較老的問題

[[email protected] ~]# rpm -q sysstat

sysstat-10.1.5-13.el7.x86_64

[[email protected] ~]# rpm -e sysstat-10.1.5-13.el7.x86_64

[[email protected] soft]# tar zxvf sysstat-11.5.5.tar.gz

[[email protected] sysstat-11.5.5]# ./configure

小結：

上面的3個案例，來歸納一下平均負載

平均負載提供了一個快速檢視系統整體效能的手段，反映了整體的負載情況，但只看平均負載本身，並不能直接發行，到底是哪裡出現了瓶頸，所以，在理解平均負載時，也要注意：

--平均負載高可能是cpu密集型程序導致的

--平均負載高並不一定代表cpu使用率高，還有可能是I/O更繁忙了

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