性能测试中Address already in use和Cannot assign requested address问题

前言

关于性能测试中Faileed to connect to server “28.x.x.x:xxxx“: [10048]Address already in use问题调试

在最近一次测试中，测试交易A响应时间在40ms左右，交易TPS稳定在5000左右；测试中200并发时交易报错“Address already in use”，报错比例在1~2%左右

问题排查

服务端排查设置

交易报错无法连接到端口，第一反应就是端口不够用，但是部分压力机在以前是做过大TPS测试场景的，所以没有怀疑压力机问题，首先排查了服务器的连接设置

       

net.ipv4.tcp_keepalive_time = 7200

默认值是2小时,当keepalive打开的情况下，TCP发送keepalive消息的频率。
net.ipv4.tcp_keepalive_probes = 9

默认值是9,TCP发送keepalive探测以确定该连接已经断开的次数。
net.ipv4.tcp_keepalive_intvl = 75

默认值为75,探测消息发送的频率，乘以tcp_keepalive_probes就得到对于从开始探测以来没有响应的连接杀除的时间。默认值为75秒，也就是没有活动的连接将在大约11分钟以后将被丢弃。

对比其他高tps服务器，发现当前设置连接参数并不合理，进行了参考修改：

在调整后，交易报错比例有小幅度下载，但是仍有1%左右的报错。

压力机问题排查

在测试中，开发组同事提议不要勾选loadrunner设置“simulate a new user on each iteration”，平时是建议勾选的，但是既然提出来了，就试一下，因为这个勾选后确实后增加TCP连接数，确实会，这很重要，这也直接误导了我下一步的测试问题判断

补充：

比较官方的解释为：指 VuGen 将各个迭代之间的所有 HTTP 上下文重置为 init 部分结束时相应的状态。使用该设置，Vuser 可以更准确地模拟开始浏览会话的新用户。它将删除所有 Cookie，关闭所有 TCP 连接（包括 Keep-Alive 连接），清除模拟浏览器的缓存，重置 HTML 帧层次结构（帧编号将从 1 开始）并清除用户名和密码。默认情况下启用该选项。

如预期一样，在不勾选时，交易不在报错，“Address already in use”，由于变更了设置交易不再报错，开发组要求，按照当前模式测试，不再排查该问题，又解释了一圈不勾选的影响，这个问题就暂时搁置了

下面这段为转载，有利于理解该设置很有帮助，太多同样的文章，已经不知道原作者是谁了，再此感谢：

昨天该员工在用LR对一个J2EE应用进行测试时，脚本录制修改和Play back都已经成功，但在controller里为脚本设置了100个VU，设置每个VU的迭代次数为20次，正确运行时应该在系统中生成2000条记录，但从controller里面看到，运行时这100个VU都只运行了一次，最终生成的只有100条记录。该员工百思不得其解，然后就向我求助。

开始我以为该问题是由脚本错误引起的，但经过对脚本的调试，验证确实没有问题，而且，在VUG中回放该脚本，回放多次就能生成多条记录，看来脚本的correlation等应该没有问题。仔细检查Web Server的日志，发现该日志中有多个访问“timeout.jsp”的访问记录，询问开发人员得知，在session超时时会访问这个页面。

HTTP协议本身是无状态的，因此为了保留住sessionid，一般的做法是用hidden field、cookie或是在URL上附加sessionid来解决这个问题，查看LR记录的页面访问数据，可以看到，该应用是用cookie解决这个问题的：

接下来的问题就清楚了，猜想是在两次迭代之间LR清除了cookie，查看RuntimeSetting的设置，果然“simulate a new user on iteration”选项被选中。

取消该选项的选中，重新运行Controller中的Senario，结果正常。

但是，正如前面所说，这次实验，也直接误导了我的排查方向，既然不勾选时报错，勾选就不报错，结合交易高并发，高TPS的特点，进一步怀疑是服务器没有及时释放端口导致端口被用尽，才会出现“Address already in use”；

峰回路转

在问题被搁置两天后，同事也遇到同样的问题，我就把上面的思路跟他一说，他同样也是报错，所以建议其修改windows压力机的端口设置，结果成功解决了报错，我也意识到我的压力机有一部分是借的，并不是全部修改了设置，于是，在修改设置后复测，果然也不再报错，

在regedit，修改“计算机\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters”

修改MaxUserPort:65534

TcpTimeWaitDelay:30

window默认最大5000个连接数，等待240秒，

对于响应时间段，TPS高的交易，很容易使端口被用完导致报错。

Cannot assign requested address

在后来jmeter测试高并发时，用linux压力机时又出现：NoRouteToHostException: Cannot assign requested address问题

参照NoRouteToHostException: Cannot assign requested address 出现原因及解决方案_记录点滴-CSDN博客博主的设置，成功解决

1、内核参数优化（需要root权限）

（1）查看时间戳支持的支持

cat /proc/sys/net/ipv4/tcp_timestamps

如果是0则修改为1

sysctl -w net.ipv4.tcp_timestamps=1 开启对于TCP时间戳的支持,若该项设置为0，则下面一项（2）设置不起作用

（2）查看是否开启快速回收

cat /proc/sys/net/ipv4/tcp_tw_recycle

如果为0则修改为1

sysctl -w net.ipv4.tcp_tw_recycle=1 表示开启TCP连接中TIME-WAIT sockets的快速回收

改完还不能解决问题，需要修改tcp_max_tw_buckets

sudo sh -c “echo ‘5000’> /proc/sys/net/ipv4/tcp_max_tw_buckets”

=================================

2、修改端口范围

查询端口占用个数

netstat -an|wc -l

16034

查询本地可用端口范围：

cat /proc/sys/net/ipv4/ip_local_port_range

32768 61000

修改端口范围

echo 1024 65000 > /proc/sys/net/ipv4/ip_local_port_range

总结

这里在修改windows设置问题上，在刚开始确实是自己排查时忽略了借来的压力机问题，并没有挨个排查windows设置；在后续排查中总是在中能贴合自己推断的结果，期间也忽略了一些问题，比如同事提醒[10048]报错一般是loadrunner端的报错，也并没引起自己的重视。总是用结果去解释现象，而没有用现象去验证结果，人总是喜欢往有利于自己的方向思考问题~~~！！！