日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務時間:8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
一文理解 Linux 平均負載,附排查工具

什么是平均負載

平均負載可以對于我們來說及熟悉又陌生,但我們問平均負載是什么,但大部分人都回答說平均負載不就是單位時間內(nèi)CPU使用率嗎?其實并不是這樣的,如果可以的話,可以 man uptime 來了解一下平均負載的詳細信息。

成都創(chuàng)新互聯(lián)主營新林網(wǎng)站建設(shè)的網(wǎng)絡公司,主營網(wǎng)站建設(shè)方案,重慶APP開發(fā),新林h5重慶小程序開發(fā)搭建,新林網(wǎng)站營銷推廣歡迎新林等地區(qū)企業(yè)咨詢

簡單的說平均負載是指單位時間內(nèi),系統(tǒng)處于可運行狀態(tài)和不可中斷狀態(tài)的平均進程數(shù),也就是說平均活躍進程數(shù),它和CPU使用率并沒有直接關(guān)系。這里解釋一下可運行狀態(tài)和不可中斷這兩個詞。

可運行狀態(tài):

指正在使用CPU或者正在等待CPU的進程,我們使用ps命令查看處于R狀態(tài)的進程

不可中斷狀態(tài):

進程則是正處于內(nèi)核態(tài)關(guān)鍵流程中的進程,并且這些流程是不可中斷的。例如:常見的等待硬件設(shè)備I/O的響應,也就是我們在ps命令查看處于D狀態(tài)的進程

比如,當一個進程向磁盤讀寫數(shù)據(jù)時,為了保證數(shù)據(jù)的一致性,在得到磁盤回復前,它是不能被其他進程中斷或者打斷的,這個時候的進程處于不可中斷狀態(tài),如果此時的進程被打斷了,就容易出現(xiàn)磁盤數(shù)據(jù)和進程數(shù)據(jù)不一致的問題。

所以,不可中斷狀態(tài)實際上是系統(tǒng)進程和硬件設(shè)備的一種保護機制。

因此,你可以簡單理解為,平均負載就是平均活躍進程數(shù)。平均活躍進程數(shù),直觀上的理解就是單位時間內(nèi)的活躍進程數(shù),但它實際上是活躍進程數(shù)的指數(shù)衰減平均值。既然是平均活躍進程數(shù),那么理想狀態(tài),就是每個CPU上都剛好運行著一個進程,這樣每個CPU都會得到充分的利用。例如平均負載為2時,意味著什么呢?

在只有2個CPU的系統(tǒng)上,意味著所有的CPU剛好被完全占用

在4個CPU的系統(tǒng)上,意味著CPU有50%的空閑

而在只有1個CPU的系統(tǒng)上,則意味著有一半的進程競爭不到CPU

平均負載和CPU使用率

現(xiàn)實工作中,我們經(jīng)常容易把平均負載和CPU使用率混淆,所以在這里,我也做一個分區(qū)。

可能你會疑惑,既然平均負載代表的是活躍進程數(shù),那平均負載高了,不就意味著CPU使用率高嗎?

我們還是要回到平均負載的含義上來,平均負載是指單位時間內(nèi),處于可運行狀態(tài)和不可中斷狀態(tài)的進程數(shù),所以,它不僅包括了正常使用CPU的進程,還包括了等待CPU和等待I/O的進程。

而CPU使用率,是單位時間內(nèi)CPU的繁忙情況的統(tǒng)計,跟平均負載并不一定完全對應,例如:

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

I/O密集型進程,等待I/O也會導致平均負載升高,但CPU使用率不一定很高

大量等待CPU的進程調(diào)度也會導致平均負載升高,此時的CPU使用率會很高

平均負載案例

這里我們需要安裝幾個工具sysstat、stress、stress-ng

這里Centos的sysstat版本會老一點,最好升級到最新版本。手動rpm安裝或者源碼安裝

場景一、CPU密集型

1、運行一個stress命令,模擬一個CPU使用率100%場景

 
 
 
  1. $ stress --cpu 1 --timeout 600 

2、開啟第二個終端,uptime查看平均負載的變化情況

 
 
 
  1. $ watch -d uptime 
  2.  
  3. 09:40:35 up 80 days, 18:41, 2 users, load average: 1.62, 1.10, 0.87 

3、開啟第三個終端,mpstat 查看CPU使用率的變化情況

 
 
 
  1. $ mpstat -P ALL 5 20 
  2.  
  3. 10:06:37 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 
  4.  
  5. 10:06:42 AM all 31.50 0.00 0.35 0.00 0.00 0.00 0.00 0.00 0.00 68.15 
  6.  
  7. 10:06:42 AM 0 1.20 0.00 0.80 0.00 0.00 0.00 0.00 0.00 0.00 98.00 
  8.  
  9. 10:06:42 AM 1 7.21 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 92.38 
  10.  
  11. 10:06:42 AM 2 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 
  12.  
  13. 10:06:42 AM 3 17.43 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 82.36 
  14. # -P ALL 表示監(jiān)控所有CPU,后面數(shù)字5 表示間隔5秒輸出一次數(shù)據(jù)

從第二個終端可以看到,1分鐘平均負載增加到1.62,從第三個終端我們可以看到有一個CPU使用率100%,但iowait為0,這說明平均負載的升高正式由CPU使用率為100%

那我們查看是那個進程導致了CPU使用率為100%呢?我們可以使用pidstat來查看:

 
 
 
  1. #每5秒輸出一次數(shù)據(jù) 
  2.  
  3. $ pidstat -u 5 1 
  4.  
  5. 10:08:41 AM UID PID %usr %system %guest %wait %CPU CPU Command 
  6.  
  7. 10:08:46 AM 0 1 0.20 0.00 0.00 0.00 0.20 0 systemd 
  8.  
  9. 10:08:46 AM 0 599 0.00 1.00 0.00 0.20 1.00 0 systemd-journal 
  10.  
  11. 10:08:46 AM 0 1043 0.60 0.00 0.00 0.00 0.60 0 rsyslogd 
  12.  
  13. 10:08:46 AM 0 6863 100.00 0.00 0.00 0.00 100.00 3 stress 
  14.  
  15. 10:08:46 AM 0 7303 0.20 0.20 0.00 0.00 0.40 2 pidstat 

從這里我們可以看到是stress這個進程導致的。

場景二、I/O密集型進程

1、我們使用stress-ng命令,但這次模擬I/O壓力,既不停執(zhí)行sync:

 
 
 
  1. #--hdd表示讀寫臨時文件 
  2.  
  3. #-i 生成幾個worker循環(huán)調(diào)用sync()產(chǎn)生io壓力 
  4.  
  5. $ stress-ng -i 4 --hdd 1 --timeout 600 

2、開啟第二個終端運行uptime查看平均負載情況

 
 
 
  1. $ watch -d uptime 
  2.  
  3. 10:30:57 up 98 days, 19:39, 3 users, load average: 1.71, 0.75, 0.69 

3、開啟第三個終端運行mpstat查看CPU使用率

 
 
 
  1. $ mpstat -P ALL 5 20 
  2.  
  3. 10:32:09 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 
  4.  
  5. 10:32:14 AM all 6.80 0.00 33.75 26.16 0.00 0.39 0.00 0.00 0.00 32.90 
  6.  
  7. 10:32:14 AM 0 4.03 0.00 69.57 19.91 0.00 0.00 0.00 0.00 0.00 6.49 
  8.  
  9. 10:32:14 AM 1 25.32 0.00 9.49 0.00 0.00 0.95 0.00 0.00 0.00 64.24 
  10.  
  11. 10:32:14 AM 2 0.24 0.00 10.87 63.04 0.00 0.48 0.00 0.00 0.00 25.36 
  12.  
  13. 10:32:14 AM 3 1.42 0.00 36.93 14.20 0.00 0.28 0.00 0.00 0.00 47.16 

從這里可以看到,1分鐘平均負載會慢慢增加到1.71,其中一個CPU的系統(tǒng)CPU使用率升到63.04。這說明,平均負載的升高是由于iowait升高。

那么我們到底是哪個進程導致的呢?我們使用pidstat來查看:

 
 
 
  1. $ pidstat -u 5 1 
  2.  
  3. Average: UID PID %usr %system %guest %wait %CPU CPU Command 
  4.  
  5. Average: 0 1 0.00 0.19 0.00 0.00 0.19 - systemd 
  6.  
  7. Average: 0 10 0.00 0.19 0.00 1.56 0.19 - rcu_sched 
  8.  
  9. Average: 0 599 0.58 1.75 0.00 0.39 2.33 - systemd-journal 
  10.  
  11. Average: 0 1043 0.19 0.19 0.00 0.00 0.39 - rsyslogd 
  12.  
  13. Average: 0 6934 0.00 1.56 0.00 1.17 1.56 - kworker/2:0-events_power_efficient 
  14.  
  15. Average: 0 7383 0.00 0.39 0.00 0.78 0.39 - kworker/1:0-events_power_efficient 
  16.  
  17. Average: 0 9411 0.00 0.19 0.00 0.58 0.19 - kworker/0:0-events 
  18.  
  19. Average: 0 9662 0.00 97.67 0.00 0.19 97.67 - kworker/u8:0+flush-253:0 
  20.  
  21. Average: 0 10793 0.00 0.97 0.00 1.56 0.97 - kworker/3:2-mm_percpu_wq 
  22.  
  23. Average: 0 11062 0.00 21.79 0.00 0.19 21.79 - stress-ng-hdd 
  24.  
  25. Average: 0 11063 0.00 1.95 0.00 1.36 1.95 - stress-ng-io 
  26.  
  27. Average: 0 11064 0.00 2.72 0.00 0.39 2.72 - stress-ng-io 
  28.  
  29. Average: 0 11065 0.00 1.36 0.00 1.75 1.36 - stress-ng-io 
  30.  
  31. Average: 0 11066 0.00 2.72 0.00 0.58 2.72 - stress-ng-io 

可以發(fā)現(xiàn)是stress-ng導致的

場景三、大量進程的場景

當系統(tǒng)中運行進程超出CPU運行能力時,就會出現(xiàn)等待CPU的進程。

比如:我們使用stress,但這次模擬8個進程:

 
 
 
  1. $ stress -c 8 --timeout 600 

我們的系統(tǒng)只有4顆CPU,這時候要運行8個進程,是明顯不夠的,系統(tǒng)的CPU后嚴重過載,這時候負載值達到了4點多:

 
 
 
  1. $ uptime 
  2.  
  3. 10:56:22 up 98 days, 20:05, 3 users, load average: 4.52, 2.82, 2.67 

接著我們運行pidstat來查看一下進程的情況:

 
 
 
  1. $ pidstat -u 5 1 
  2.  
  3. Linux 5.0.5-1.el7.elrepo.x86_64 (k8s-m1) 07/11/2019 _x86_64_ (4 CPU) 
  4.  
  5. 10:57:33 AM UID PID %usr %system %guest %wait %CPU CPU Command 
  6.  
  7. 10:57:38 AM 0 1 0.20 0.00 0.00 0.00 0.20 1 systemd 
  8.  
  9. 10:57:38 AM 0 599 0.00 0.99 0.00 0.20 0.99 2 systemd-journal 
  10.  
  11. 10:57:38 AM 0 1043 0.60 0.20 0.00 0.00 0.79 1 rsyslogd 
  12.  
  13. 10:57:38 AM 0 12927 51.59 0.00 0.00 48.21 51.59 0 stress 
  14.  
  15. 10:57:38 AM 0 12928 44.64 0.00 0.00 54.96 44.64 0 stress 
  16.  
  17. 10:57:38 AM 0 12929 45.44 0.00 0.00 54.56 45.44 2 stress 
  18.  
  19. 10:57:38 AM 0 12930 45.44 0.00 0.00 54.37 45.44 2 stress 
  20.  
  21. 10:57:38 AM 0 12931 51.59 0.00 0.00 48.21 51.59 3 stress 
  22.  
  23. 10:57:38 AM 0 12932 48.41 0.00 0.00 51.19 48.41 1 stress 
  24.  
  25. 10:57:38 AM 0 12933 45.24 0.00 0.00 54.37 45.24 3 stress 
  26.  
  27. 10:57:38 AM 0 12934 48.81 0.00 0.00 50.99 48.81 1 stress 
  28.  
  29. 10:57:38 AM 0 13083 0.00 0.40 0.00 0.20 0.40 0 pidstat 

可以看出,8個進程搶占4顆CPU,每個進程等到CPU時間(%wait)高達50%,這些都超出CPU計算能力的進程,最終導致CPU過載。

【編輯推薦】

  • 如何在Ubuntu Linux上釋放/boot分區(qū)的空間?
  • 27 個提升開發(fā)幸福度的 VsCode 插件
  • 為Linux的cp和mv命令添加進度條
  • Windows10系統(tǒng)下Hadoop和Hive開發(fā)環(huán)境搭建填坑指南
  • 高性能開發(fā)的“十大武器”,愛了愛了!

【責任編輯:張燕妮 TEL:(010)68476606】


分享名稱:一文理解 Linux 平均負載,附排查工具
分享路徑:http://www.5511xx.com/article/djdjsgp.html