探索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列?
評論區解惑
-
iowait無法升高的問題,是因為案例中stress使用的是 sync() 系統呼叫,它的作用是重新整理緩衝區記憶體到磁碟中。對於新安裝的虛擬機器器,緩衝區可能比較小,無法產生大的IO壓力,這樣大部分就都是系統呼叫的消耗了。所以,你會看到只有系統CPU使用率升高。解決方法是使用stress的下一代stress-ng,它支援更豐富的選項,比如 stress-ng -i 1 --hdd 1 --timeout 600(--hdd表示讀寫臨時檔案)。
-
pidstat輸出中沒有%wait的問題,是因為CentOS預設的sysstat稍微有點老,原始碼或者RPM升級到11.5.5版本以後就可以看到了。而Ubuntu的包一般都比較新,沒有這個問題。
-
mpstat無法觀測的問題,案例中是等待5秒後輸出1次結果就停止了,更好的做法是持續監控一段時間,比如持續觀測20次:mpstat -P ALL 5 20
小結
- 平均負載可以代表當前系統總體的負載情況
- 平均負載升高的原因可能是存在佔用CPU的程式,也可能是IO密集型的程式還可能是大量程式在系統中,使得CPU存在大量的上下文切換導致系統負載升高
- 可以使用mpstat,pidstat來排查問題
關於寫作
"百天"寫作計劃下半部。
每週更新一篇碎碎念。
每週三、週六更新一篇儘量全面,詳細的文章。
可能時長突破了百天,但是又有什麼關係呢?提高寫作水平,形成寫作的習慣才是最終的目的。
如果這篇文章給你帶來了一些幫助,可以動動手指點個贊,順便關注一波就更好了。
如果上面都沒有,那麼寫下讀完之後最想說的話?有效的反饋和你的鼓勵是對我最大的幫助。
另外打算把部落格給重新撿起來了。歡迎大家來訪問吃西瓜。
我是shane。今天是2019年9月22日。"百天"寫作計劃下半部,53/100。