stress施壓命令分析
一、stress --cpu 1 --timeout 600 分析現象？負載為啥這么高？top命令查看用戶進程消耗的cpu過高（stress進程消耗的）
分析現象，可以看出負載很高，用戶態的cpu的使用率是100%，stress進程使用的cpu也接近100%。
問題：負載為什么接近於1？？
# vmstat 1 查看監控信息
負載=r+b，這是一個瞬時值。
下圖可以看出r+b為1，所以這里的負載為1。
這里負載不為2的原因，這里只有一核cpu在干活，也只有一個進程在消耗cpu，所以這里負載是1，不會是2。
二、stress -i 1 --timeout 600 分析現象？top看負載升高，內核cpu過高？ iostat -x 3 stress消耗cpu多，iowait 等待 pidstat -d
正常情況下，這里的iowait也是有數據的，不是0，應該會漲，可能是操作系統版本的原因，或者用stress-ng版本這個加強版
下載地址：https://kernel.ubuntu.com/~cking/tarballs/stress-ng/
安裝步驟和stress一樣的，需要編譯安裝。
高版本的stress-ng編譯需要高版本的gcc，我這里以前是4.4.7版本的
gcc下載地址：http://www.gnu.org/prep/ftp.html
分析步驟：
top可以看到有iowait ，所以這里可能是io等待導致的。
1、 iostat -x 3
通過iostat 看磁盤的繁忙程度，這里的數據應該是達到20%以上，可以看出磁盤繁忙，還有進程讀和寫，我這里的操作系統版本太低，所以數據很小。
這里寫操作也比較多，懷疑應該每秒寫600多,所以磁盤繁忙是大量的寫導致的，所以下面使用pidstat再分析。
2、pidstat -d 3 查看進程讀、進程寫、和進程延遲
這里iodelay，這里每次都有java（tomcat）和stress。
這里的寫操作比較多，
三、stress -c 8 --timeout 600
現象：用戶cpu已經打滿了，負載上升很快，並且很快就到8了，每個進程所占的cpu資源是12%多，就是這8個stress把cpu打滿了。
vmstat 1
負載=r+b =8
pidstat 3
這里的%wait是等待cpu臨幸它所消耗的一個百分比，百分比越高，等待排隊的時間越長，和iowait不同。
這里8個進程在搶占cpu，中斷和上下文切換會高些。
vmstat 3 查看中斷和上下文切換
這里cs應該達到幾十萬以上，我這里數據不對，
案例：有次壓測用的是4核的一個cpu，用20個線程去壓，cpu就打滿了，到100%
一個tomcat寫的java進程，20個並發的是tps大概是90多，30個並發tps是80多，80個並發的時候tps就是70多。
cpu都是打滿的，隨着並發數的時候，響應時間不斷增加，tps不斷減小。
什么原因？？？
響應時間增加懷疑cpu上下文切換導致的線程等待時間比較長，
tomcat打印tomcat整理處理時間，再打印一個接口的一個處理時間，接口處理時間從100ms增加到200ms，但是tomcat的處理時間從1s增加到8s。
隨着並發數的增加，tomcat線程池的排隊時間從1s增加到8s多，時間耗在哪里了呢，時間耗在了線程的上下文切換上了。
四、sysbench --threads=10 --max-time=300 threads run
現象：負載很高，大部分還在內核態cpu，看看誰在用內核態cpu？iowait沒有，中斷沒有，也不是虛擬化？？那是誰把內核cpu打滿了？？
最有可能是上下文切換，進程之間上下文切換導致的內核態cpu比較高。
# vmstat 1
可以看到圖中cs上下文切換真他媽好高，達到百萬級別了。
#pidstat -w 看上下文切換，但是這里啥也看不出來。為啥看不出來呢？？？
因為？？？
pidstat默認看的是進程之間的上下文切換，上下文切換的最小單位是線程。
查看線程之間的上下文切換加一個-t參數
pidstat -wt 1
cswch自願上下文切換：進程無法獲取資源導致的上下文切換，比如；I/O，內存資源等系統資源不足，就會發生自願上下文切換。
nvcswch非自願上下文切換：進程由於時間片已到，被系統強制調度，進而發生的上下文切換 ，比如大量進程搶占cpu。
python腳本運行分析
五、app.py
python3 app.py 運行python腳本，看現象
現象：負載上來，這里%iowait特別高，應該是80%多，cpu內核使用也挺高的，top 定位到磁盤有問題。
#vmstat 1
首先查看這里負載為啥升高？負載=r+b
可以看到這里只有一個進程運行也就是r，但是b（中斷不可恢復）會有多個，可見負載高是由io導致的。
# iostat -x 3
查看下面的磁盤繁忙程度很高，並且寫的排隊時間到174多毫秒，寫的速度為每秒20多萬KB，可見是由大量的寫操作導致的磁盤比較繁忙。
#pidstat -d 3 查看到底是哪個進程導致的iowait，也就是哪個進程在進行大量的寫操作。
可以看到是python3這個進程在進行大量地寫操作，達到十萬級別以上。
分析流程屢一下：
1、top首先看負載高（負載=r+b），vmstat 查看這里是有中斷不可恢復的進程的比較多（io操作一般是中斷不可恢復的進程，可能是io問題）；
2、然后看cpu使用情況，看到cpu這里iowait比較高，可見是由磁盤導致的；
3、然后iostat -x 看磁盤，磁盤這里確實比較繁忙，並且有很瘋狂的寫操作，磁盤每次操作消耗時間比較長，大部分時間耗排隊時間比較長；
4、然后分析到底是哪個進程在進行寫操作，這里使用pidstat -d 3 查看是python3進程在進行大量的寫操作，消耗io比較高，這里是定位到了進程的層面；
5、對於應用程序要定位到方法層面，為啥導致了寫操作比較多，到底在寫什么東西呢？？
這里可以看到python3的pid 為32488，這里內核調用也挺高的，用strace來跟蹤系統內核進程的調用情況。
strace -p 32488
這里是在往logtest.txt寫文件，進入到相應目錄查看有沒有這個文件。
使用lsof查看文件句柄，看都是誰打開的，是python3打開的，目前已經定位到了在寫什么了。
6、定位到方法，再去看代碼，每次寫得很大，大概10M。
六、iolatency.py
負載不高，cpu使用率也不高，iowait也不高，ni 中斷都沒問題，啥現象都沒有，但就是使用的時候，或者使用某個具體功能，訪問某個具體的頁面的時候響應賊慢。
啟動的時候，大家可以看到啟動了一個ip：80
所以這里可以訪問一下，192.168.1.17 （http默認80端口，可以不加）大家可以看到這里訪問很快
但是如果大家訪問 192.168.1.17/popularity/word 就可以看到這里訪問賊慢,還沒有返回結果。
過了好大一會，才返回如下結果：
這里進行壓測該接口 http://192.168.1.17/popularity/word 我們top下觀察現象：
這里負載升高、iowait也升高達80%多。
1、負載上去的原因：vmstat 1 b列有許多中斷不可恢復的進程。io 里的bo數據很大，是在進行大量的寫操作，定位到io問題。
2、iostat -x 3 查看隊列、和寫的速度都很大，定位到是大量的寫操作導致磁盤繁忙和和排隊，下面查看是哪個進程在大量地寫。
3、pidstat -d 3 確定是python進程在寫操作。
4、strace -p <pid>看這個進程在寫啥，或者加個過濾條件：strace -p <pid> grep | write，跟蹤不到在寫啥？？？？
5、filetop （bcc-tools里的一個包，github上下載，源碼安裝）