性能测试机中存在大量的TIME_WAIT状态的连接,影响并发压力的发起

现在一个测试项目,发现性能测试机中有很多TIME_WAIT状态的TCP连接,在网上查了一下,这种状态也叫TCP半连接状态。

测试环境:3台winserver测试机,其中包括一台压力控制机,即controller机器

服务器环境:websphere+DB2

问题表现:controller机器使用其中任何一台windows测试机并发5个vuser或者更多,都会在8分钟或者10分钟左右出现大量的失败交易

分析:通过在cmd中查看netstat -ano > d:/port.txt(把netstat打印的信息输出到当前D盘根目录下)查看TCP连接,有大量的TIME_WAIT状态的TCP连接,大约有6W多个time_wait状态的TCP连接,咱们windows系统最大端口数量才只有65536个端口,性能测试机每次通过TCP访问server都会占用一个本地端口,导致time_wait状态(半连接状态)过多,并且不释放,导致新的TCP连接去寻找新的端口。如果widows提供的65536个端口全部用完,time_wait状态大量存在,就不会再有新建立的连接,则会出现timeout,导致大量的并发用户数宕掉。这严重影响了并发的发起,该问题已经提交到运维部,请他们来协助

解决办法:

1、修改注册表中的tcpip的属性值:TIMEWAIT回收时间

在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters,添加名为TcpTimedWaitDelay的DWORD键,设置为十进制0,以缩短TIME_WAIT的等待时间。

测试结果:TIME_WAIT状态的连接依然大量存在,每台机器可以承担少量的并发不会出现错误;当并发增大时则会出现大量的错误。

时间: 2024-10-07 21:21:49

性能测试机中存在大量的TIME_WAIT状态的连接,影响并发压力的发起的相关文章

TIME_WAIT状态的连接过多导致系统端口资源耗尽问题(2)

继上次解决完mysql连接过多,导致的TIME_WAIT进程过多问题之后,最近这个现象再一次出现,并且依然和之前一样严重.只不过这次出现问题的mysql 服务跟上次不一样,上一次主要是mysql master server,而这一次是mysql slave server.所以这意味着,我们上次解决了部分问题,但没有彻底解决,还存在一部分问题.所以这次彻底的把这个问题好好梳理一下. 再次确认一下TIME_WAIT进程的所属服务: sudo netstat -anp | grep TIME_WAIT

TCP/IP中TIME_WAIT状态详解

TIME_WAIT状态原理: 通信双方建立连接后,主动关闭连接的一方就会进入TIME_WAIT状态. 客户端主动关闭连接时,会发送最后一个ACK确认,然后就会进入TIME_WAIT状态,再停留2MSL,就会进入CLOSED状态. 接下来我们看一张图,来说明这一过程: 上图是TCP"四次挥手"的过程,相信你们都会很了解,下面我们来说说为什么要存在TIME_WAIT状态 TIME_WAIT状态存在的理由如下: (1)可靠地实现TCP全双工连接的终止 TCP协议在关闭连接的四次挥手中,最终的

TCP/IP中的TIME_WAIT状态

毫无疑问,TCP中有关网络编程最不容易理解的是它的TIME_WAIT状态,TIME_WAIT状态存在于主动关闭socket连接的一方. TIME_WAIT状态存在的理由: TCP/IP协议就是这样设计的,是不可避免的.主要有两个原因: 1)可靠地实现TCP全双工连接的终止 TCP协议在关闭连接的四次握手过程中,最终的ACK是由主动关闭连接的一端(后面统称A端)发出的,如果这个ACK丢失,对方(后面统称B端)将重发出最终的FIN,因此A端必须维护状态信息(TIME_WAIT)允许它重发最终的ACK

LINUX下解决netstat查看TIME_WAIT状态过多问题(转)

原文连接:www.itokit.com/2012/0516/73950.html # netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c 16 CLOSING     130 ESTABLISHED     298 FIN_WAIT1      13 FIN_WAIT2       9 LAST_ACK       7 LISTEN     103 SYN_RECV    5204 TIME_WAIT 状态:描述 CLOSED:无连接是活动的或正在进行

TIME_WAIT状态原理(转)

---------------------------- 转自:http://elf8848.iteye.com/blog/1739571 通信双方建立TCP连接后,主动关闭连接的一方就会进入TIME_WAIT状态. 客户端主动关闭连接时,会发送最后一个ack后,然后会进入TIME_WAIT状态,再停留2个MSL时间(后有MSL的解释),进入CLOSED状态. 下图是以客户端主动关闭连接为例,说明这一过程的. TIME_WAIT状态存在的理由 --------------------------

第三篇:关于TIME_WAIT状态

前言 为何TCP ”四次分手“ 的过程中会有一个TIME_WAIT状态?这个状态有什么意义呢?这是网络中的一个经典问题,本文将给出精简的回答. 什么是TIME_WAIT状态 这是TCP通信协议中出现的一个状态,端点会在这个状态停留2MSL( 最长分节生命期 ),参见下图: 左下方的那个状态即是. TIME_WAIT状态存在意义之一 假设上图中,最后的那个ack分节传递失败了,那么服务器端会要求客户端再传递一次这个分节.如果没有此状态( 客户端直接退出 ),那就无法重传这段丢失了的分节( 所有对客

TCP四次挥手时TIME_WAIT状态以及端口号的分类

TIME_WAIT(时间等待计时器)状态是什么? 简单来说,TIME_WAIT状态是四次挥手中服务器向客户端发送FIN终止连接后进入的状态. 四次挥手的过程: 可以看到TIME_WAIT状态存在于客户端收到服务器FIN并返回ACK时的状态. 当处于TIME_WAIT状态时,我们无法创建新的连接,因为端口被占用. 2. 为什么会有TIME_WAIT状态? 原因如下两点: <1> 可靠的终止TCP连接 若处于TIME_WAIT的客户端发送给服务器确认报文段丢失的话,服务器将在此重新发送FIN报文

TCP/IP TIME_WAIT状态原理

TIME_WAIT状态原理 ---------------------------- 通信双方建立TCP连接后,主动关闭连接的一方就会进入TIME_WAIT状态. 客户端主动关闭连接时,会发送最后一个ack后,然后会进入TIME_WAIT状态,再停留2个MSL时间(后有MSL的解释),进入CLOSED状态. 下图是以客户端主动关闭连接为例,说明这一过程的. TIME_WAIT状态存在的理由 ---------------------------- TCP/IP协议就是这样设计的,是不可避免的.主

TCP相关(控制位、3次握手、4次挥手、端口号分类TIME_WAIT状态...)

TCP报文格式 一.6个控制位中 URG和PSH的区别: (1)紧急URG(URGent), 当URG=1时, 表明紧急指针字段有效.它告诉操作系统此报文中有紧急数据,应尽快传输(相当于高优先级数据),而不要按照原来的排队顺序来传送.例如,已经发送了很长的一个程序要在远地的主机上运行,但后来发现了一些问题,需要取消该程序的运行.因为用户从键盘发送中断指令(Control+c),如果不使用紧急数据,那么两个字符将存储在接收TCP的缓存末尾.只有在所有的数据被处理完毕后,这两个字符才会被交付到接收方