场景:30个并发,单台jmeter压测;客户端-Windows系统,服务端-linux系统;
问题:TPS上升后下降,且下降为高峰TPS的四分之一左右;
原因:压测机tcp连接端口占用过多超2万7千多,且大部分TCP连接都是time_wait状态,顾tcp连接端口不足;
解决方案:采用分布式压测,增加端口号;
分析思路:
第一步:分析客户端和服务端的性能,看是否有性能瓶颈(CPU,内存,磁盘,网络)
第二步:再分析客户端和服务端的端口是否用尽
第三步:最后分析客户端和服务端的Java堆栈日志,分析原因
本次测试的经验分享:
1、通过jemter-permon监控分析服务端的硬件性能,看是否有性能瓶颈(CPU,内存,磁盘,网络),结果:未发现硬件性能瓶颈;通过任务管理器查看客户端(Windows服务器),也未发现硬件性能瓶颈。
2、通过jstack分析服务端的Java堆栈信息,因为一直没有获取到对应服务Java的pid,所以也没有一直分析(后期分析有结果再和大家分享);通过jstack分析客户端的Java堆栈信息,发现如下错误:
“java.lang.Thread.State: RUNNABLE
at java.net.DualStackPlainSocketImpl.connect0(Native Method)
at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
- locked <0x0000000776a7fff8> (a java.net.DualStackPlainSocketImpl)
at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)”
初步定位可能跟端口号用尽有关;
3、通过netstat -ano|findstr 443|find /C “TCP”(window系统)分析客户端tcp端口的使用个数,通过netstat -ano|findstr 443|findstr TCP分析客户端tcp端口的使用情况。
结果:发现TCP端口使用2万7千多,且大部分都是time_wait状态。
4、以此判断tcp连接端口不足,采用分布式来压测,TCP曲线图基本正常。
5、为啥30个并发就把TCP端口占用这么多,需要进一步详细分析下。
问题监控现象图:
问题解决恢复监控图:
说明
欢迎对于测试志同道合的人加入,大家一起沟通交流!
QQ群:775460627
个人微信:wxid_ptea4d8gx4tx12;
版权归原作者 玻璃杯1992 所有, 如有侵权,请联系我们删除。