Linux系統下CPU使用(load average)梳理

 

在平時的運維工做中，當一臺服務器的性能出現問題時，一般會去看當前的CPU使用狀況，尤爲是看下CPU的負載狀況(load average)。對通常的系統來講，根據cpu數量去判斷。好比有2顆cup的機器。若是平均負載始終在1.2如下，那麼基本不會出現cpu不夠用的狀況。也就是Load平均要小於Cpu的數量。

對於cpu負載的理解，首先須要搞清楚下面幾個問題：
 
1）系統load高不必定是性能有問題。
由於Load高也許是由於在進行cpu密集型的計算
 
2）系統Load高不必定是CPU能力問題或數量不夠。
由於Load高只是表明須要運行的隊列累計過多了。但隊列中的任務實際多是耗Cpu的，也多是耗i/0或者其餘因素的。
 
3）系統長期Load高，解決辦法不是一味地首先增長CPU
由於Load只是表象，不是實質。增長CPU個別狀況下會臨時看到Load降低，但治標不治本。
 
4）在Load average 高的狀況下須要鑑別系統瓶頸究竟是CPU不足，仍是io不夠快形成或是內存不足形成的。
 
===============================================================================================================
要想得到服務器的CPU負載狀況，有下面幾種命令：
1）w命令
[root@localhost ~]# w
 12:12:41 up 167 days, 20:46,  2 users,  load average: 0.00, 0.01, 0.05
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/0    192.168.1.5      10:01    1.00s  0.11s  0.00s w
root     pts/2    192.168.1.5      10:19    1:47m  0.04s  0.04s -bash
  
2）uptime命令（通常首先會根據最後那個15分鐘的load負載爲準）
[root@localhost ~]# uptime
 12:12:55 up 167 days, 20:46,  2 users,  load average: 0.00, 0.01, 0.05
  
3）top命令
[root@localhost ~]# top
top - 12:13:22 up 167 days, 20:47,  2 users,  load average: 0.00, 0.01, 0.05
Tasks: 272 total,   1 running, 271 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.1 sy,  0.0 ni, 99.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 65759080 total, 58842616 free,   547908 used,  6368556 buff/cache
KiB Swap:  2097148 total,  2097148 free,        0 used. 64264884 avail Mem
................
 
對上面第三行的解釋：
us（user cpu time）：用戶態使用的cpu時間比。該值較高時，說明用戶進程消耗的 CPU 時間比較多，好比，若是該值長期超過 50%，則須要對程序算法或代碼等進行優化。
sy（system cpu time）：系統態使用的cpu時間比。
ni（user nice cpu time）：用作nice加權的進程分配的用戶態cpu時間比
id（idle cpu time）：空閒的cpu時間比。若是該值持續爲0，同時sy是us的兩倍，則一般說明系統則面臨着 CPU 資源的短缺。
wa（io wait cpu time）：cpu等待磁盤寫入完成時間。該值較高時，說明IO等待比較嚴重，這可能磁盤大量做隨機訪問形成的，也多是磁盤性能出現了瓶頸。
hi（hardware irq）：硬中斷消耗時間
si（software irq）：軟中斷消耗時間
st（steal time）：虛擬機偷取時間
 
以上解釋的這些參數的值加起來是100%。
 
4）vmstat
[root@localhost ~]# vmstat
procs -----------memory---------------------swap-------io---------system--------cpu-----
r  b      swpd   free    buff   cache    si   so    bi    bo     in   cs     us sy id wa st
3  0      0      1639792 724280 4854236  0    0     4     34     4    0      19 45 35  0  0
 
解釋說明：
-----------------------------
procs部分的解釋
r 列表示運行和等待cpu時間片的進程數，若是長期大於1，說明cpu不足，須要增長cpu。
b 列表示在等待資源的進程數，好比正在等待I/O、或者內存交換等。
-----------------------------
cpu部分的解釋
us 列顯示了用戶方式下所花費 CPU 時間的百分比。us的值比較高時，說明用戶進程消耗的cpu時間多，可是若是長期大於50%，須要考慮優化用戶的程序。
sy 列顯示了內核進程所花費的cpu時間的百分比。這裏us + sy的參考值爲80%，若是us+sy 大於 80%說明可能存在CPU不足。
wa 列顯示了IO等待所佔用的CPU時間的百分比。這裏wa的參考值爲30%，若是wa超過30%，說明IO等待嚴重，這多是磁盤大量隨機訪問形成的，也可能磁盤或者
   磁盤訪問控制器的帶寬瓶頸形成的(主要是塊操做)。
id 列顯示了cpu處在空閒狀態的時間百分比
-----------------------------
system部分的解釋
in 列表示在某一時間間隔中觀測到的每秒設備中斷數。
cs列表示每秒產生的上下文切換次數，如當 cs 比磁盤 I/O 和網絡信息包速率高得多，都應進行進一步調查。
-----------------------------
memory部分的解釋
swpd 切換到內存交換區的內存數量(k表示)。若是swpd的值不爲0，或者比較大，好比超過了100m，只要si、so的值長期爲0，系統性能仍是正常
free 當前的空閒頁面列表中內存數量(k表示)
buff 做爲buffer cache的內存數量，通常對塊設備的讀寫才須要緩衝。
cache: 做爲page cache的內存數量，通常做爲文件系統的cache，若是cache較大，說明用到cache的文件較多，若是此時IO中bi比較小，說明文件系統效率比較好。
-----------------------------
swap部分的解釋
si 由內存進入內存交換區數量。
so由內存交換區進入內存數量。
-----------------------------
IO部分的解釋
bi 從塊設備讀入數據的總量（讀磁盤）（每秒kb）。
bo 塊設備寫入數據的總量（寫磁盤）（每秒kb）
 
 
5）也可使用dstat命令查看cpu信息
[root@localhost ~]# dstat
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
 19  45  35   0   0   0|  30k  265k|   0     0 |   0     0 |9025    12k
  9  18  73   0   0   0|   0   144k|2578k   65k|   0     0 |3956  4343
 
6）可使用iostat查看IO負載
[root@localhost ~]# iostat 1 1
Linux 2.6.32-696.16.1.el6.x86_64 (nc-ftp01.kevin.cn)    2017年12月29日     _x86_64_    (4 CPU)
 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          19.32    0.00   45.44    0.06    0.26   34.93
 
Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
xvda             14.17        29.94       265.17   63120486  558975100

解釋說明：
avg-cpu: 整體cpu使用狀況統計信息，對於多核cpu，這裏爲全部cpu的平均值
%user: 在用戶級別運行所使用的CPU的百分比.
%nice: nice操做所使用的CPU的百分比.
%sys: 在系統級別(kernel)運行所使用CPU的百分比.
%iowait: CPU等待硬件I/O時,所佔用CPU百分比.
%idle: CPU空閒時間的百分比.

Device段:各磁盤設備的IO統計信息
tps: 每秒鐘發送到的I/O請求數.
Blk_read /s: 每秒讀取的block數.
Blk_wrtn/s: 每秒寫入的block數.
Blk_read:   讀入的block總數.
Blk_wrtn:  寫入的block總數.

[root@localhost ~]# iostat -x -k -d 1
Linux 2.6.32-696.el6.x86_64 (centos6-vm02)  01/04/2018  _x86_64_    (4 CPU)

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
scd0              0.00     0.00    0.00    0.00     0.00     0.00     8.00     0.00    0.36    0.36    0.00   0.36   0.00
vda               0.01     0.13    0.04    0.13     0.60     0.89    18.12     0.00    2.78    0.19    3.53   2.55   0.04
dm-0              0.00     0.00    0.04    0.22     0.58     0.88    11.25     0.00    3.27    0.25    3.82   1.61   0.04
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     8.00     0.00    0.13    0.13    0.00   0.04   0.00
dm-2              0.00     0.00    0.00    0.00     0.00     0.00     7.91     0.00    0.19    0.10    5.00   0.16   0.00

解釋說明：
rrqm/s: 每秒對該設備的讀請求被合併次數，文件系統會對讀取同塊(block)的請求進行合併
wrqm/s: 每秒對該設備的寫請求被合併次數
r/s: 每秒完成的讀次數
w/s: 每秒完成的寫次數
rkB/s: 每秒讀數據量(kB爲單位)
wkB/s: 每秒寫數據量(kB爲單位)
avgrq-sz:平均每次IO操做的數據量(扇區數爲單位)
avgqu-sz: 平均等待處理的IO請求隊列長度
await: 平均每次IO請求等待時間(包括等待時間和處理時間，毫秒爲單位)
svctm: 平均每次IO請求的處理時間(毫秒爲單位)
%util: 採用週期內用於IO操做的時間比率，即IO隊列非空的時間比率

若是 %util 接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁盤可能存在瓶頸。
idle小於70% IO壓力就較大了,通常讀取速度有較多的wait。
同時能夠結合vmstat 查看查看b參數(等待資源的進程數)和wa參數(IO等待所佔用的CPU時間的百分比,高過30%時IO壓力高)

簡單說下CPU負載和CPU利用率的區別

0）load average：系統平均負載是CPU的Load，它所包含的信息不是CPU的使用率情況，而是在一段時間內CPU正在處理以及等待CPU處理的進程數之和的統計信息，
   也就是CPU使用隊列的長度的統計信息，這個數字越小越好。

1）CPU使用率：顯示的是程序在運行期間實時佔用的CPU百分比。

2）CPU負載：顯示的是一段時間內正在使用和等待使用CPU的平均任務數。CPU使用率高，並不意味着負載就必定大。
舉例來講：若是我有一個程序它須要一直使用CPU的運算功能，那麼此時CPU的使用率可能達到100%，可是CPU的工做負載則是趨近於"1"，由於CPU僅負責一個工做啊。
若是同時執行這樣的程序兩個呢？CPU的使用率仍是100%，可是工做負載則變成2了。因此也就是說，當CPU的工做負載越大，表明CPU必需要在不一樣的工做之間進行頻繁
的工做切換。

 
3）CPU利用率高，並不意味着負載就必定大。
舉例來講：
若是有一個程序它須要一直使用CPU的運算功能，那麼此時CPU的使用率可能達到100%，可是CPU的工做負載則是趨近於"1"，由於CPU僅負責一個工做！
若是同時執行這樣的程序兩個呢？CPU的使用率仍是100%，可是工做負載則變成2了。因此也就是說，當CPU的工做負載越大，表明CPU必需要在不一樣的工做之間
進行頻繁的工做切換。
  
------------------------下面經過一個電話亭打電話的比喻來講明這二者之間的區別------------------------
某公用電話亭，有一我的在打電話，四我的在等待，每人限定使用電話一分鐘，如有人一分鐘以內沒有打完電話，只能掛掉電話去排隊，等待下一輪。
電話在這裏就至關於CPU，而正在或等待打電話的人就至關於任務數。
  
在電話亭使用過程當中，確定會有人打完電話走掉，有人沒有打完電話而選擇從新排隊，更會有新增的人在這兒排隊，這我的數的變化就至關於任務數的增減。
爲了統計平均負載狀況，咱們5分鐘統計一次人數，並在第一、五、15分鐘的時候對統計狀況取平均值，從而造成第一、五、15分鐘的平均負載。
  
有的人拿起電話就打，一直打完1分鐘，而有的人可能前三十秒在找電話號碼，或者在猶豫要不要打，後三十秒才真正在打電話。若是把電話看做CPU，人數看
做任務，咱們就說前一我的（任務）的CPU利用率高，後一我的（任務）的CPU利用率低。固然， CPU並不會在前三十秒工做，後三十秒歇着，只是說，有的程
序涉及到大量的計算，因此CPU利用率就高，而有的程序牽涉到計算的部分不多，CPU利用率天然就低。但不管CPU的利用率是高是低，跟後面有多少任務在排隊
沒有必然關係。

=========正確理解%iowait和CPU使用率=========

1）%steal
通常是在虛擬機中才能看到數值，好比CPU overcommitment很嚴重的VPS，而%guest和%nice通常都很低,因此也能夠
根據/proc/stat或者top可得，user + nice + system + idle + iowait + irq + softirq + steal = 100

2）Linux進程狀態
運行狀態（TASK_RUNNING）：
　　是運行態和就緒態的合併，表示進程正在運行或準備運行，Linux 中使用TASK_RUNNING 宏表示此狀態
可中斷睡眠狀態（淺度睡眠）（TASK_INTERRUPTIBLE）：
　　進程正在睡眠（被阻塞），等待資源到來是喚醒，也能夠經過其餘進程信號或時鐘中斷喚醒，進入運行隊列。Linux 使用TASK_INTERRUPTIBLE 宏表示此狀態。
不可中斷睡眠狀態（深度睡眠狀態）（TASK_UNINTERRUPTIBLE）：
　　其和淺度睡眠基本相似，但有一點就是不可被其餘進程信號或時鐘中斷喚醒。Linux 使用TASK_UNINTERRUPTIBLE 宏表示此狀態。
暫停狀態（TASK_STOPPED）：
　　進程暫停執行接受某種處理。如正在接受調試的進程處於這種狀態，Linux 使用TASK_STOPPED 宏表示此狀態。
僵死狀態（TASK_ZOMBIE）：
　　進程已經結束但未釋放PCB，Linux 使用TASK_ZOMBIE 宏表示此狀態。

3）%iowait 的正確認知
%iowait 表示在一個採樣週期內有百分之幾的時間屬於如下狀況：CPU空閒、而且有仍未完成的I/O請求。

對 %iowait 常見的誤解有兩個：
　　一是誤覺得 %iowait 表示CPU不能工做的時間，
　　二是誤覺得 %iowait 表示I/O有瓶頸。

首先 %iowait 升高並不能證實等待I/O的進程數量增多了，也不能證實等待I/O的總時間增長了。
例如：
在CPU繁忙期間發生的I/O，不管IO是多仍是少，%iowait都不會變；
當CPU繁忙程度降低時，有一部分IO落入CPU空閒時間段內，致使%iowait升高。
再好比：IO的併發度低，%iowait就高；IO的併發度高，%iowait可能就比較低。

可見%iowait是一個很是模糊的指標，若是看到 %iowait 升高，還需檢查I/O量有沒有明顯增長，
avserv/avwait/avque等指標有沒有明顯增大，應用有沒有感受變慢，若是都沒有，就沒什麼好擔憂的。

4）查看CPU使用率，推薦以下Linux命令：
# top
# sar -u 1 5
# vmstat -n 1 5
# mpstat -P ALL 1 5

查看Load的值，推薦以下Linux命令：
# top
# uptime
# sar -q 1 5

load average相關梳理（一分鐘，五分鐘，十五分鐘的平均CPU負載，最重要的指標是最後一個數字，即前15分鐘的平均CPU負載，這個數字越小越好。所謂CPU負載指的是一段時間內任務隊列的長度，通俗的講，就是一段時間內一共有多少任務在使用或等待使用CPU。（當前的"負載值除以cpu核數"就是cpu的利用率））

load average表示的是系統的平均負荷，即CPU的Load。
它所包含的信息不是CPU的使用率情況，而是在一段時間內CPU正在處理以及等待CPU處理的進程數之和的統計信息，也就是CPU使用隊列的長度的統計信息。
它包括3個數字，分別表示系統在一、五、15分鐘內進程隊列中的平均進程數量（即處理的進程狀況），
原則上來講這3個數字越小越好，數字越小表示服務器的工做量越小，系統負荷比較輕
 
當CPU徹底空閒的時候，平均負荷爲0（即load average的值爲0）；當CPU工做量飽和的時候，平均負荷爲1。
 
這裏須要注意的是：
load average這個輸出值，這三個值的大小通常不能大於系統邏輯CPU的個數
好比一臺服務器有4個邏輯CPU，若是load average的三個值長期大於4時，說明CPU很繁忙，負載很高，可能會影響系統性能；
可是偶爾大於4時，倒不用擔憂，通常不會影響系統性能。
相反，若是load average的輸出值小於CPU的個數，則表示CPU還有空閒，好比本例中的輸出，CPU是比較空閒的。
 
 
-------------load average舉例理解---------------
判斷系統負荷是否太重，必須理解load average的真正含義。假設當前個人一臺服務器只有一個CPU，全部的運算都必須由這個CPU來完成。
不妨把這個CPU想象成一座大橋，橋上只有一根車道，全部車輛都必須從這根車道上經過（很顯然，這座橋只能單向通行）。
1）系統負荷爲0，意味着大橋上一輛車也沒有。
2）系統負荷爲0.5，意味着大橋一半的路段有車。
3）系統負荷爲1.0，意味着大橋的全部路段都有車，也就是說大橋已經"滿"了。可是必須注意的是，直到此時大橋仍是能順暢通行的。
4）系統負荷爲1.7，意味着車輛太多了，大橋已經被佔滿了（100%），後面等着上橋的車輛爲橋面車輛的70%。
   以此類推，系統負荷2.0，意味着等待上橋的車輛與橋面的車輛同樣多；
   系統負荷3.0，意味着等待上橋的車輛是橋面車輛的2倍。
   總之，當系統負荷大於1，後面的車輛就必須等待了；系統負荷越大，過橋就必須等得越久。
 
CPU的系統負荷，基本上等同於上面的類比。大橋的通行能力，就是CPU的最大工做量；橋樑上的車輛，就是一個個等待CPU處理的進程（process）。
若是CPU每分鐘最多處理100個進程，那麼：
系統負荷0.2，意味着CPU在這1分鐘裏只處理20個進程；
系統負荷1.0，意味着CPU在這1分鐘 里正好處理100個進程；
系統負荷1.7，意味着除了CPU正在處理的100個進程之外，還有70個進程正排隊等着CPU處理。
 
爲了服務器順暢運行，系統負荷最好不要超過1.0，這樣就沒有進程須要等待了，全部進程都能第一時間獲得處理。
很顯然，1.0是一個關鍵值，超過這個值，系統就不在最佳狀態了，就須要動手干預了。
 
 
--------1.0是系統負荷的理想值嗎？-----------
不必定，系統管理員每每會留一點餘地，當這個值達到0.7，就應當引發注意了。
以往經驗是這樣的：
當系統負荷持續大於0.7，必須開始調查了，問題出在哪裏，防止狀況惡化。
當系統負荷持續大於1.0，必須動手尋找解決辦法，把這個值降下來。
當系統負荷達到5.0，就代表系統有很嚴重的問題，長時間沒有響應，或者接近死機了。覺不能讓系統達到這個值。
 
 
上面，假設個人這臺服務器只有1個CPU。若是它裝了2個CPU，就意味着服務器的處理能力翻了一倍，可以同時處理的進程數量也翻了一倍。
仍是用大橋來類比，兩個CPU就意味着大橋有兩根車道了，通車能力翻倍了。
因此，2個CPU代表系統負荷能夠達到2.0，此時每一個CPU都達到100%的工做量。推廣開來，n個CPU的服務器，可接受的系統負荷最大爲n.0。
 
 
---------至於load average是多少纔算理想，這個有爭議，各有各的說法---------
我的比較贊同CPU負載小於等於"內核數乘以0.5-0.7"算是一種理想狀態。
好比4核CPU的服務器，理想負載是小於等於2，最好不要超過2.8，不然性能多少會受影響。
 
無論某個CPU的性能有多好，1秒鐘能處理多少任務，能夠認爲它可有可無，雖然事實並不是如此。
在評估CPU負載時，只以5分鐘爲單位作統計任務隊列長度。若是每隔5分鐘統計的時候，發現任務隊列長度都是1，那麼CPU負載就爲1。
 
假如如今某臺服務器只有一個單核的CPU，負載一直爲1，意味着沒有任務在排隊，還不錯。
可是這臺服務器是雙核CPU，等因而有4個內核，每一個內核的負載爲1的話，總負載爲4。這就是說，若是這臺服務器的CPU負載長期保持在4左右，還能夠接受。
可是每一個內核的負載爲1，並不能算是一種理想狀態！這意味着服務器的CPU一直很忙，不得悠閒。
 
 
-----------load average返回三個平均值應該參考哪一個值？------------
若是隻有1分鐘的系統負荷大於1.0，其餘兩個時間段都小於1.0，這代表只是暫時現象，問題不大。
若是15分鐘內，平均系統負荷大於1.0（調整CPU核心數以後），代表問題持續存在，不是暫時現象。
因此應該主要觀察"15分鐘系統負荷"，將它做爲服務器正常運行的指標。
 
----------如何來下降服務器的CPU負載？--------------
最簡單辦法的是更換性能更好的服務器，不要想着僅僅提升CPU的性能，那沒有用，CPU要發揮出它最好的性能還須要其它軟硬件的配合。
在服務器其它方面配置合理的狀況下，CPU數量和CPU核心數（即內核數）都會影響到CPU負載，由於任務最終是要分配到CPU核心去處理的。兩塊CPU要比一塊
CPU好，雙核要比單核好。所以，須要記住的是：除去CPU性能上的差別，CPU負載是基於內核數來計算的。有一個說法是"有多少內核，即有多少負載"。