最近一直在搞性能压测，断断续续的搞了一个月了，中间遇到各种问题，这里将这些问题分享下，以后大家踩坑时可以参考~

俗话说，工欲善其事，必先利其器。拿到机器，先检查CPU、内存、网卡、磁盘四大件。咋知道这第一关就踩雷了，dstat -tamps一下，看见网卡的出口流量总是为0：

出口流量为0，怀疑是读数有问题，如果只能进不能出，那根本无法远程到这台机器上。wget证实一下 下载文件成功，证明只是网卡出口数据包显示有问题，而网卡一直正常发送数据包。最后找运维的兄弟看看，说是网卡驱动问题，立即升级驱动重启机器解决问题。效率高得不得不给个赞！！

环境OK了，开始干活。把jmeter跑起来，使劲的调整着压测线程数，同时看着业务机的状态，实际发现无论怎么调整jmeter的压测线程数，应用的tps也无法上去，而且应用机器的水位都属于正常范围，没有任何压力；再检查ulimit，正常；再看看业务日志，有少量的业务错误日志（下游依赖的数据mock返回失败造成），属于正常范围。接着开始怀疑是tomcat的工作线程数太小，打开server.xml，逐次加大maxConnections、maxThreads的值，峰值tps也没有任何提升；同时检查此时应用的jstack+gc，没有发现异常。开始陷入困境：TPS上不去，机器压力低，业务处理也算正常范围，开始怀疑不是tomcat的问题了。既然机器压力不高，怀疑请求是不是没到机器？先用netstat检查了业务端口的连接数

发现ESTABLISH状态的连接才是100。而且连续打了几遍，都在100附近徘徊。发现问题了，我启动jmeter的启动脚本明明是设置了线程数为200的；按理说在应用机器压力不大的情况下，连接数起码也接近200吧。去问提供压测脚本的兄弟，然后豁然开朗了，调整压测线程数的方式没生效，压测代码不支持从启动脚本中配置压测线程数，得改配置文件才生效~~o(>_<)o ~~

好，恢复心情，以正确的姿势调整好压测线程数继续测。线程数一直往上涨，当加到400时，新问题又出现。tps突然降低至0，半分钟后又恢复正常，后面就一直0、正常、0、正常的间隔着。但跌0的时候，应用机器的水位数据跟没压测时是一样的。首先怀疑业务线程卡住了，jstack一把看，正常。翻看业务日志，都是mock返回的数据跟预期的不一样导致的错误，认为正常了；再看依赖库osp错误日志，看到有超时9000ms的日志；找负责mock的兄弟一起排查，他怀疑是osp-client跟proxy设置的线程数不够，建议调整osp-client跟proxy的线程数看看。当时就立马调大看了也没效果。其实现在仔细想想，是跟这个没关系的，就算osp-client的线程数不够，那起码也是部分请求因为等待工作线程响应慢而已，不应该TPS全掉0的；从错误日志看很大几率是mock端返回数据超时导致了。为了再证实这个事实，满足下好奇心，祭出大杀器。tcpdump一把，等到TPS掉0时结束，将数据拉回本地用Wireshark看

明显看到这两个数据包之间，时间间隔了24秒，能解析通了。再确认下是不是mock机器没返回数据包，加个筛选条件tcp.stream eq 75（有问题的数据流）： 144是mock的机器，79是业务机。发现144->79的数据包，全部都是ACK类型的，只是向79发送ACK包，而没有返回任何的业务数据，这下水落石出了，剩下的辛苦mock的兄弟了。