瓶颈浅析

性能测试瓶颈分析，
引入趋势分析和证据链，
首先根据压力端TPS、Art、报错率的曲线来确定系统是否存在问题，曲线可得出压力趋势，问题暴露的趋势
tps下降、抖动、跌零；
art剧烈增长、伴随着报错增长；
系统资源不足、或者使用不充分无法继续使用，都意味着瓶颈的出现；
另一方面。瓶颈调优是无止境的，先按照既定的需求去阶段性的优化。
第二方面，关于证据链
概述：要懂的利用监控命令；读懂计数器的含义；以点带面地形成证据链，运用计数器的监控值。
方法：
1.明确系统架构（业务逻辑架构对应业务流量的路径；系统架构对应网络流量路径）
2.列出路径中的组件，压力端，web层，应用层，db
3.罗列对应的组件，nginx-- gateway – AppServer --DBServer --mq – kafka – redis等
4.针对各个模块去尽可能地收集全局的监控计数器，来形成证据链
操作系统OS级的资源，CPU、Memory、IO disk、System、process、network
cpu：us wa hi si cpu队列
us% 用户使用高，java应用，top查看高的线程，top -Hp pid定位该进程下的线程，使用jstack pid>1.log 打出栈日志，使用pritf“”转换16进制线程号，thread dump中找到对应线程的nid值，即找到该线程；主要要多打几次dump日志，对比查看，3-5次
注意deadlock，block阻塞等待超时，wait on monitor entry（对象锁，等待monitor，全局只有一个monitor），长时间的runable等
分析stack状态详细的jstack分析方法论
分析瓶颈从系统架构说起，从架构出发
发起端：压力机资源，压力机网络
web服务器：若有web服务，web服务器资源，软件资源：Idle/busy servers空闲忙碌的server数量（占一个坑先）。作用1.充当软交换，分发交易2.加载静态资源js、css等
应用服务端：服务器硬件资源cpu、mem、disk、网络，软件资源：threadpoolSize，HeapSize/usedMemory，当前jvm堆大小
GC情况，DBpoolSize数据库连接池
DB：sql执行效率、bufferpool数据库缓存、sort排序、lock锁资源使用（数据库的先占坑）
1.压力机资源、网络判断
当出现tps过低，被测系统资源使用率不高，可以初步考虑压力机，使用netstat -an查看压力机的交易端口，若连接数远小于并发用户，则说明请求被阻塞在发起端；当持续刷新发现一个端口占用时间过长，短连接超过1s，压力机处理比较慢，某些交易需要在发起端有复杂运算，比如说加解密；在压力状态下 ping发起端，时延一般小于1ms，否则说明网络有延迟
2.web软件资源
Idle/busy servers空闲忙碌的server数量，kbytes sent/sec每秒发送字节
3.app Server资源
3.1cpu：可使用vmstat，sar查看，cpu%偏高，使用vmstat查看第一列r列，为cpu运行队列长度，当大于1倍cpu核数时，cpu可能存在瓶颈
cpu总核数=物理cpu数每颗物理cpu的核数
cpu逻辑核数=物理cpu数每颗物理cpu的核数*超线程数
cat /proc/cpuinfo 查看物理CPU数，physical id，cpu核数，cpu core，逻辑cpu数：processor
具体vmstat参考：https://www.cnblogs.com/emanlee/archive/2011/08/01/2124208.html
3.2若r列正常查看磁盘读写队列是否正常
iostat 可查看系统开机至今的cpu和io平均资源 -c -d可只查看cpu、disk资源，默认以字节形式输出，使用-k 以kb单位输出，-x查看详细io资源
iostat -d -k -x 2每两秒查看io资源

linux # iostat -x -k -d 1
Linux 2.6.16.60-0.21-smp (linux)     06/13/12

……
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00  9915.00    1.00   90.00     4.00 34360.00   755.25    11.79  120.57   6.33  57.60

r/s、w/s每秒读写数， rkB/s wkB/s 每秒读写量 await 每次io等待时间，包括io处理时间+io等待时间；svctm io处理时间/ms
avgqu-sz io等待队列
await多大需要考虑磁盘性能瓶颈先占个坑）
上图可看出磁盘主写，每秒写90次，每秒平均写入34M，io平均等待时间120ms，io处理时间6ms，平均io队列11.7个请求
3.3若磁盘正常，查看网络资源（先占坑）
ping丢包率，网络时延，发送接收队列
3.4之后考虑内存是否异常，
free 查看可用mem注意buf cache为可用内存，注意swap空间使用，若有使用，关注vmstat 中sawp、si、so写入写出sawp大于零表示物理内存不足，siso说明从磁盘中每秒读入虚拟内存的数据频次，说明物理内存不足，或程序有内存泄漏
linux内存概念包括物理内存+虚拟内存swap。当物理内存不够时，会从磁盘申请swap空间充当内存空间使用，如图

测试过程中，曾出现压测结果与之前有较大出入，进一步了解是数据库慢了，查看sawp空间被占用，mysql自身io读写已经很频繁 了，若再交换磁盘到内存空间，io压力大
涉及到缓存，物理内存以及虚拟内存交换空间
首先mem读写速度远大于disk，10*5倍，所以内存资源宝贵，现在16G内存，disk可能有1T
缓存为空间换时间，本身为磁盘数据，缓存在内存中，使某些数据读写更快
交换空间为，时间换空间，将本身内存中数据存入磁盘中，读这些数据需要重新从磁盘读写，导致内容展示变慢，但是内存使用似乎变得合理了
4.server软件资源
treadpoolsize，db连接池大小（占坑先）
目前了解，应用线程数与压测并发数或者系统用户数接近，线程数可以略小于用户数（目前项目组核心应用连接数60性能较优，正常单机并发72用户左右，交换平台c程序，设置40进程时，当并发大于50，性能受限为啥设置进程数，未设置线程数，交换认为进程虽稍浪费硬件资源，但是比线程方式稳定，崩一个线程可能一个进程都会受影响。可能与java程序稍不同）
应用线程池大小与db jdbc连接池关系，约等于1:2关系，当线程池大于连接数，数据库不能及时处理，导致瓶颈；线程小于连接数，应用cpu使用不足，导致tps异常（现在也有文章称，db链接数或线程数未必越大越好，先占个坑）
5.数据库（占坑）
sort，排序；lock，锁资源；缓存命中
补充mysql机制（占坑）
6.jvm GC
yonugGC每秒3-5次，最好不要出现FullGC，整体垃圾回收需要暂停所有线程，若频繁fullgc则有异常
jstack 进程号 查看该进程下所有java线程（占坑）