做性能測試的必備知識系列，可以看下面鏈接的文章哦
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 等工具，輔助分析負載的來源
通俗總結
平均負載過高是出現性能瓶頸的表現，分析瓶頸產生的源頭和原因，需要通過各類工具