1. 程式人生 > 程式設計 >探索Linux-平均負載(一)

探索Linux-平均負載(一)

本篇是Linux效能實戰筆記

平均負載

我們使用uptime命令來檢視平均負載。

一般來說,會由三種場景導致平均負載的升高。一種是存在CPU密集型的程式,一種是存在IO密集型的程式,還有一種是存在大量的程式導致CPU頻繁切換。

環境搭建

機器準備

Linux機器準備,我這裡準備了一臺CentOs的機器。機器是1核心2GB記憶體的。

壓測工具準備

安裝stresssysstatCentOS下可以使用如下命令安裝stress

sudo yum install stress sysstat
複製程式碼
  • mpstat 是一個常用的多核 CPU 效能分析工具,用來實時檢視每個 CPU 的效能指標,以及所有 CPU 的平均指標。
  • pidstat 是一個常用的程式效能分析工具,用來實時檢視程式的 CPU、記憶體、I/O 以及上下文切換等效能指標。

模擬開始

檢視初始狀態

使用uptime命令檢視系統初始的負載情況。

uptime
複製程式碼

可以得到如下結果。

[jack@VM_31_196_centos ~]$ uptime
 16:44:06 up 126 days,21:39,1 user,load average: 0.01,0.05,0.05
複製程式碼

1分鐘,5分鐘,15分鐘的平均負載都在5%以內。

CPU密集

在第一個終端,使用stress,模擬一個CPU使用率100%的場景

stress --cpu 1 --timeout 600
複製程式碼

這裡使用stress命令來對一個CPU造成100%壓力,持續時間為600秒。

在第二個終端中,使用uptime來檢視系統的負載情況。

watch -d uptime
 16:54:40 up 126 days,21:49,3 users,load average: 2.76,2.07,1.05
複製程式碼

使用watch命令表示每隔2秒輸出一個uptime的結果。可以看到當前1分鐘的CPU的使用率已經達到了276%。不過我估計這個值也不是非常準確。還是下面的mpstat來的更加準確一些。

在第三個終端使用mpstat來檢視CPU使用的具體情況。

[jack@VM_31_196_centos ~]$ mpstat -P ALL 5
Linux 3.10.0-693.el7.x86_64 (VM_31_196_centos)  09/22/2019      _x86_64_        (1 CPU)

04:49:27 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
04:49:32 PM  all  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
04:49:32 PM    0  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
複製程式碼

mpstat -P ALL 5-P ALL表示監控所有的CPU,5表示每隔5秒輸出一組資料。

從終端三中可以看到序號為0的CPU的使用率是100%,但是iowait確實0。說明平均負載的升高是由於CPU的使用率導致的。

那麼如何找到使得平均負載升高的程式呢?可以使用pidstat來找到這個程式。

[jack@VM_31_196_centos ~]$ pidstat -u 5 1
Linux 3.10.0-693.el7.x86_64 (VM_31_196_centos)  09/22/2019      _x86_64_        (1 CPU)

05:01:24 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command
05:01:29 PM    27      5834    0.20    0.00    0.00    0.20     0  mysqld
05:01:29 PM  1000      8814   99.00    0.00    0.00   99.00     0  stress
05:01:29 PM  1000      8829    0.20    0.00    0.00    0.20     0  watch
05:01:29 PM     0     27330    0.20    0.00    0.00    0.20     0  java
05:01:29 PM     0     28977    0.20    0.00    0.00    0.20     0  barad_agent
複製程式碼

可以看到stress佔用了99%的CPU資源。

IO密集

首先還是使用stress來模擬IO密集的情況。

stress -i 1 --timeout 600
複製程式碼

上面表示不停的進行sync,並且持續600秒的時間。

在第二個終端上面執行uptime

watch -d uptime
複製程式碼

可以看到平均負載也不斷升高到了1.56。

使用mpstat來檢視各個CPU的情況。

[jack@VM_31_196_centos ~]$ mpstat -P ALL 5
Linux 3.10.0-693.el7.x86_64 (VM_31_196_centos)  09/22/2019      _x86_64_        (1 CPU)

05:04:10 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
05:04:15 PM  all    1.21    0.00   63.31   35.48    0.00    0.00    0.00    0.00    0.00    0.00
05:04:15 PM    0    1.21    0.00   63.31   35.48    0.00    0.00    0.00    0.00    0.00    0.00
複製程式碼

可以看到序號為0的CPU的sys為63,而iowait是35,可以認為是iowait過高導致,平均負載上升。

還是使用pidstat命令來檢視是哪一個程式導致CPU的平均負載過高?

[jack@VM_31_196_centos ~]$ pidstat -u 5 1
Linux 3.10.0-693.el7.x86_64 (VM_31_196_centos)  09/22/2019      _x86_64_        (1 CPU)
05:04:35 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command
05:04:40 PM     0       258    0.00    0.20    0.00    0.20     0  jbd2/vda1-8
05:04:40 PM     0       366    0.00    0.40    0.00    0.40     0  kworker/0:1H
05:04:40 PM     0      1642    0.00    0.20    0.00    0.20     0  kworker/u2:2
05:04:40 PM  1000      8829    0.20    0.20    0.00    0.40     0  watch
05:04:40 PM  1000      9300    0.00   65.12    0.00   65.12     0  stress
05:04:40 PM     0     11852    0.20    0.00    0.00    0.20     0  YDService
05:04:40 PM     0     27330    0.00    0.20    0.00    0.20     0  java
05:04:40 PM     0     28978    0.00    0.20    0.00    0.20     0  barad_agent
複製程式碼

可以看到還是stress程式導致的。

大量程式的場景

使用stress模擬4個程式,因為當前機器只有一個CPU,所以肯定是大大查過當前CPU所能處理的繼承的數量的。

使用pidstat來檢視哪個程式佔用了大量的CPU資源。

[jack@VM_31_196_centos ~]$ pidstat -u 5 1
Linux 3.10.0-693.el7.x86_64 (VM_31_196_centos)  09/22/2019      _x86_64_        (1 CPU)
05:17:48 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command
05:17:53 PM     0      7255    0.20    0.00    0.00    0.20     0  dockerd
05:17:53 PM  1000      8829    0.20    0.00    0.00    0.20     0  watch
05:17:53 PM  1000     11248   24.90    0.00    0.00   24.90     0  stress
05:17:53 PM  1000     11249   24.50    0.00    0.00   24.50     0  stress
05:17:53 PM  1000     11250   24.50    0.00    0.00   24.50     0  stress
05:17:53 PM  1000     11251   24.70    0.00    0.00   24.70     0  stress
05:17:53 PM     0     11852    0.00    0.20    0.00    0.20     0  YDService
05:17:53 PM     0     27330    0.20    0.00    0.00    0.20     0  java
05:17:53 PM     0     28978    0.20    0.00    0.00    0.20     0  barad_agent
複製程式碼

可以看到4個stress程式佔用了所有的CPU資源。不過不知道為什麼沒有像專欄中存在wait列?

評論區解惑

  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

小結

  1. 平均負載可以代表當前系統總體的負載情況
  2. 平均負載升高的原因可能是存在佔用CPU的程式,也可能是IO密集型的程式還可能是大量程式在系統中,使得CPU存在大量的上下文切換導致系統負載升高
  3. 可以使用mpstat,pidstat來排查問題

關於寫作

"百天"寫作計劃下半部。

每週更新一篇碎碎念。

每週三、週六更新一篇儘量全面,詳細的文章。

可能時長突破了百天,但是又有什麼關係呢?提高寫作水平,形成寫作的習慣才是最終的目的。

如果這篇文章給你帶來了一些幫助,可以動動手指點個贊,順便關注一波就更好了。

如果上面都沒有,那麼寫下讀完之後最想說的話?有效的反饋和你的鼓勵是對我最大的幫助。

另外打算把部落格給重新撿起來了。歡迎大家來訪問吃西瓜

我是shane。今天是2019年9月22日。"百天"寫作計劃下半部,53/100。