记一次性能压测的问题排查过程
记一次性能压测的问题排查过程
ericquan8 发表于5个月前
记一次性能压测的问题排查过程
  • 发表于 5个月前
  • 阅读 24
  • 收藏 0
  • 点赞 0
  • 评论 0

腾讯云 技术升级10大核心产品年终让利>>>   

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

俗话说,工欲善其事,必先利其器。拿到机器,先检查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的兄弟了。

共有 人打赏支持
粉丝 7
博文 15
码字总数 14681
评论 (0)
×
ericquan8
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: