性能測試必備知識（4）- 使用 stress 和 sysstat 分析平均負載太高的場景

作性能測試的必備知識系列，能夠看下面連接的文章哦

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 等工具，輔助分析負載的來源

 

通俗總結

平均負載太高是出現性能瓶頸的表現，分析瓶頸產生的源頭和緣由，須要經過各種工具