探索Linux-平均負載(一)

本篇是Linux性能實戰筆記

平均負載

咱們使用uptime命令來查看平均負載。

通常來講，會由三種場景緻使平均負載的升高。一種是存在CPU密集型的進程，一種是存在IO密集型的進程，還有一種是存在大量的進程致使CPU頻繁切換。

環境搭建

機器準備

Linux機器準備，我這裏準備了一臺CentOs的機器。機器是1核心2GB內存的。

壓測工具準備

安裝stress和sysstat 在CentOS下可使用以下命令安裝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來排查問題

關於寫做

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

每週更新一篇碎碎念。

每週3、週六更新一篇儘可能全面，詳細的文章。

可能時長突破了百天，可是又有什麼關係呢？提升寫做水平，造成寫做的習慣纔是最終的目的。

若是這篇文章給你帶來了一些幫助，能夠動動手指點個贊，順便關注一波就更好了。

若是上面都沒有，那麼寫下讀完以後最想說的話？有效的反饋和你的鼓勵是對我最大的幫助。

另外打算把博客給從新撿起來了。歡迎你們來訪問吃西瓜。

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