效能測試必備知識(4)- 使用 stress 和 sysstat 分析平均負載過高的場景

小菠蘿測試筆記發表於2020-07-17

做效能測試的必備知識系列,可以看下面連結的文章哦

https://www.cnblogs.com/poloyy/category/1806772.html

 

stress 介紹

Linux 系統壓力測試工具,這裡通過異常程式模擬平均負載升高的場景

 

來看看 stress 命令列引數的講解

 

欄位含義
-?、--help 幫助文件
--version、-v 版本號
-q 退出
-n 顯示已完成指令的情況
-t N、--timeout N 執行 N 秒後停止
--backoff N 等待 N 微秒後開始執行
-c N、--cpu N
  • 產生 N 個程式
  • 每個程式反覆的計算隨機數的平方根
  • 模擬 CPU 計算密集型場景
-i N、--io N
  • 產生 N 個程式
  • 每個程式反覆呼叫 sync()
  • 模擬 I/O 密集型場景
-m N、--vm N
  • 產生 N 個程式
  • 每個程式不斷呼叫記憶體分配 malloc()記憶體釋放 free() 函式

--vm-bytes B

指定 malloc() 時記憶體的位元組數,預設256MB
--vm-hang N 指定執行 free() 前等待的秒數
-d N、 --hdd N
  • 產生 N 個程式
  • 每個程式執行 write() unlink() 的程式
--hdd-bytes B 

每個 hdd worker 寫入 B 位元組(預設為1GB)

 

Numbers may be suffixed with s,m,h,d,y (time) or B,K,M,G (size)

時間單位可以為秒 s,分m,小時h,天d,年y,檔案大小單位可以為 K,M,G

 

sysstat 介紹

  • 包含了常用的 Linux 效能工具,用來監控和分析系統的效能
  • 接下來會用到 mpstat 和 pidstat 兩個命令
  • 後面用單獨一篇詳細講解裡面包含的所有命令

 

mpstat

  • 常用的多核 CPU 效能分析工具
  • 實時檢視每個 CPU 的效能指標以及所有 CPU 的平均指標

 

pidstat

  • 常用的程式效能分析工具
  • 實時檢視程式的 CPU、記憶體、I/O 以及上下文切換等效能指標

 

安裝兩個工具

提供百度雲盤連結

連結:https://pan.baidu.com/s/1YENSYaGw7Ar1Z8hf8CXGqA

提取碼:2tpc

放到 Linux 下的某個目錄

 

解壓

tar -zxvf sysstat-12.1.5.tar.gz

tar -zxvf stress-1.0.4.tar.gz

 

分別進入解壓後的兩個資料夾執行以下命令

./configure

make&&make install

 

平均負載和 CPU 使用率的實際栗子

前言

  • 前面一篇文章也講到了平均負載和 CPU 使用率的三個場景,接下來我們分別對這三個場景舉例子
  • 需要開啟三個終端訪問同一個 Linux 機器哦
  • 我的 Linux 是虛擬機器,2個cpu,2核

 

CPU 密集型程式

第一個終端

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

stress -c 1 -t 600

 

第二個終端

執行 uptime 檢視系統平均負載情況,-d 參數列示高亮顯示變化的區域

watch -d uptime

可以看到,1 分鐘的平均負載會慢慢增加到 1.00

 

第三個終端

執行 mpstat 檢視 CPU 使用率的變化情況

mpstat -P ALL 5

可以看出

  • 僅有一個 CPU 的使用率接近 100%,但它的 iowait 只有 0
  • 這說明,平均負載的升高正是由於 CPU 使用率為 100%

 

接下來,就要排查是哪個程式導致 CPU 的使用率這麼高的

 

使用 pidstat 命令

間隔 5 秒後輸出一組資料

pidstat -u 5 1

從這裡可以明顯看到,stress 程式的 CPU 使用接近 100%

 

I/O 密集型程式

第一個終端

執行 stress 命令,但這次模擬 I/O 壓力,即不停地執行 sync()

 

第二個終端

執行 uptime 檢視系統平均負載情況,-d 參數列示高亮顯示變化的區域

watch -d uptime

可以看到,1 分鐘的平均負載也會慢慢增加到 1.00

 

第三個終端

執行 mpstat 檢視 CPU 使用率的變化情況

mpstat -P ALL 5 1

 

靈魂拷問

其實 iowait 並沒有上去,反而還是系統態(%sys)升高了,這是怎麼回事?難道是工具的問題?

 

回答

  • iowait 無法升高是因為案例中 stress -i 使用的是 sync() 系統呼叫,它的作用是重新整理緩衝區記憶體到磁碟中
  • 對於新安裝的虛擬機器,緩衝區可能比較小,無法產生大的io壓力
  • 這樣大部分都是系統呼叫的消耗
  • 所以,只看到系統 CPU 使用率升高

 

解決辦法

使用 stress 的另一個引數 -d ,含義上面已經說了哦

stress --hdd 1 -t 600 --hdd-bytes 4G

 

再通過 mpstat 看看指標

mpstat -P ALL 5

可以看到

  • iowait 是明顯升高了,雖然我們的 CPU 使用率也較高
  • 當做了幾次嘗試之後,包括啟動了 2個、4個程式,發現 CPU 使用率仍然保持在 30%+,而 iowait 則不斷升高,最高可達到40%+,而且平均負載也在不斷升高
  • 所以可以看出平均負載的升高,很大原因是因為 iowait 的不斷升高

 

接下來,就要排查是哪個程式導致 iowait 這麼高了

 

使用 pidstat 命令

間隔 5 秒後輸出一組資料,收集 10 次,檢視最後的平均值

pidstat -u 5 10

可以看到

kworker 寫入位元組的程式 和 stress 程式的 CPU 使用率都是偏高的

 

大量程式的場景

目的

當系統中執行程式超出 CPU 執行能力時,就會出現等待 CPU 的程式

 

第一個終端

這次模擬 8 個程式

stress -c 8 -t 600

 

第二個終端

執行 uptime 檢視系統平均負載情況,-d 參數列示高亮顯示變化的區域

watch -d uptime

我的系統只有 4 個 CPU,比 8 個程式少得多,CPU 處於嚴重的過載狀態,平均負載已經超過 8 了

 

第三個終端

可以直接通過 pidstat 來檢視程式的情況了,每隔 5s 收集一次,收集 5 次,看平均值

pidstat -u 5 5

可以看到

  • 8 個程式在競爭 4 個 CPU
  • 每隔程式等待 CPU 的時間(%wait)高達 50%
  • 這些超出 CPU 計算能力的程式,導致 CPU 過載 

 

對於平均負載的一個理解和總結

  • 平均負載提供了一個快速檢視系統整體效能的手段,反映了整的負載情況
  • 但只看平均負載本身,我們並不能直接發現到底是哪裡出現了瓶頸

 

平均負載過高的分析排查思路

  • 有可能是 CPU 即密集型程式導致的
  • 平均負載過高不代表 CPU 使用率高,也有可能是 I/O 更密集了
  • 當發現平均負載過高時,可以通過 mpstat、pidstat 等工具,輔助分析負載的來源

 

通俗總結

平均負載過高是出現效能瓶頸的表現,分析瓶頸產生的源頭和原因,需要通過各類工具

相關文章