做效能測試的必備知識系列，可以看下面連結的文章哦
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 |
|
| -i N、--io N |
|
| -m N、--vm N |
|
|
--vm-bytes B |
指定 malloc() 時記憶體的位元組數，預設256MB |
| --vm-hang N | 指定執行 free() 前等待的秒數 |
| -d N、 --hdd N |
|
| --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 等工具，輔助分析負載的來源
通俗總結
平均負載過高是出現效能瓶頸的表現，分析瓶頸產生的源頭和原因，需要通過各類工具