[if !supportLists]1、 [endif]并发十几秒后大量报Too many open files错误
分析思路：
压测过程中统计java进程打开的文件句柄数lsof –p pid|wc -l
统计java进程打开的TCP连接数lsof –p pid|grep TCPv6|wc –l
发现打开的文件句柄数超过4096，TCP连接数将近4000
此时怀疑是http(底层使用okhttp)端口未复用
压测过程中通过tcpdump抓取服务之间的通信，再通过Wireshark进行分析
分析发现整个抓包过程中所有的本地端口都只使用一次-----------------进一步印证http端口使用问题
配合开发确认问题
验证Open Feign(微服务架构下服务之间的调用提供了解决方案)的okhttp是否有端口未复用问题-----------发现端口可以正常复用
验证RestTemplate(RestTemplate是Spring提供的用于访问Rest服务的客户端)的okhttp是否有端口未复用问题------发现端口未复用
架构师查看代码发现开发使用RestTemplate的方式不正确，导致每个请求都创建一个新的okhttp连接池，导致TCP连接很快达到4000
优化后TPS将近1400
2、批量查询，随着请求参数中userid的增加，TPS下降很严重，增加到6个userid时，运行20秒之后TPS下降到个位数
分析思路
TPS下降到个位数时通过jstack抓取线程堆栈
分析线程堆栈发现大量工作线程在等待sharding-jdbc(当当网的一个开源分库分表框架，现在是apache shardingsphere下的一个组件)里面同一个资源
抓取线程堆栈的同时查看数据库的慢查询日志和服务日志
发现同一条sql服务日志里面打印的执行开始时间和慢查询日志里接收到的时间相差4秒------怀疑是sharding-jdbc存在问题
通过结合线程堆栈分析sharding-jdbc源码
发现sharding-jdbc中加了同步锁，sql不允许并发执行，所以出现随着请求中userid增加，响应时间成倍增加，而我们的业务需要在同个线程里面部分sql并发执行
优化后同一请求中包含10个userid时TPS可以达到380
3、并发1分多钟后大量报Cannot assign requested address错误，TPS从2500下降到100
分析思路
检查tcp连接各种状态的连接数
netstat -n|awk '/^tcp/ {++S[$NF]} END{for(a in S) print a, S[a]}'
ss –ant|grep ‘TIME-WAIT’|grep ‘ip:port’|wc -l
发现TIME-WAIT的连接超过28000个，linux系统的默认可用端口数为32768-61000，已使用端口数超过可用端口数所以报了以上错误，通过以下命令查询可用端口数：
sysctl -a | grepipv4.ip_local_port_range
为什么会出现大量TIME-WAIT的连接，是不是底层框架处理tcp连接时没有及时回收连接，导致短时间内有大量请求时出现端口不够
最终架构师通过分析代码发现底层类库对连接池的处理有问题
优化完之后TPS达到2400
4、并发时TPS波动比较大，且没有规律
分析思路
抓取线程堆栈，结合线程堆栈和代码分析发现一个请求需要操作9次redis，redis服务端为单线程处理，单个请求多次操作redis就会出现第一次redis请求很快，后面每次请求都需要等待redis，此时TPS波动就会比较大
5、并发时TPS波动范围超过1000，且有规律
分析思路
并发过程抓取线程堆栈进行分析
分析发现全部工作线程都在等待获取数据库连接的锁
结合druid源码进行分析
发现druid在释放连接和获取连接时都会加锁，druid默认使用的又是公平锁，在使用公平锁时会出现这种情况
优化druid连接池属性，启用非公平锁，优化后TPS达到2500
6、TPS比较低(300左右)，16核数据库CPU全部使用完
分析思路
分析sql执行计划
发现sql中的5个where条件走的是联合索引(由查询条件的5个字段创建)，每个字段的过滤性都比较低，虽然使用到了索引但是索引的效率很低还是要扫描超过60W行的数据
优化索引，调整索引字段顺序、增加虚拟列，优化后扫描行数下降到3000行，TPS达到1800，CPU使用率65%
7、并发几分钟之后TPS下降到0
分析思路
监控GC使用情况
jstat –gcutil pid 1000
发现在频繁FGC，出现内存泄漏
执行jmap命令将堆信息dump下来
使用Mat分析dump文件，可分析出存在泄漏的具体方法
8、TPS低、应用程序CPU使用率达到饱和
分析思路
压测过程中使用jprofiler进行监控分析，可分析出消耗CPU高的方法
C语言程序可以使用perf、pstack、strace
9、TPS低、资源使用率低
分析思路
先分析负载机，看负载机是否出现了瓶颈(可能是一些特殊处理导致负载机出现瓶颈)
分析网络，排除网络延时以及带宽问题
压测过程中抓取线程堆栈进行分析，分析工作线程在干什么
