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上下载，源码安装）
来源：oschina
链接：https://my.oschina.net/u/4399009/blog/3444180