关于 No buffer space available (maximum connections reached?): connect 的处理

一、问题：

 

hudson一个应用打包部署一直不成功，检查报错

检查项目的JOB配置，开始以为是SVN的问题，但是重启SVN后问题一直存在

 

 

 二、分析：

      TCP协议中，关闭TCP连接的是Server端（当然，关闭都可以由任意一方发起），当Server端发起关闭连接请求时，向Client端发送一个FIN报文，Client端收到FIN报文时，很可能还有数据需要发送，所以并不会立即关闭SOCKET，所以先回复一个ACK报文，告诉Server端，“你发的FIN报文我收到了”。当Client端的所有报文都发送完毕之后，Client端向Server端发送一个FIN报文，此时Client端进入关闭状态，不在发送数据。 

       Server端收到FIN报文后，就知道可以关闭连接了，但是网络是不可靠的，Client端并不知道Server端要关闭，所以Server端发送ACK后进入TIME_WAIT状态，如果Client端没有收到ACK则Server段可以重新发送。Client端收到ACK后，就知道可以断开连接了。Server端等待了2MSL（Max Segment Lifetime，最大报文生存时间）后依然没有收到回复，则证明Client端已正常断开，此时，Server端也可以断开连接了。2MSL的TIME_WAIT等待时间就是由此而来

 

三、解决：

1.查了资料发现是进程虽然结束了，但是有很多TIME_WAIT状态的连接未释放

 

 

2 查看hudson所在的windows服务器上

①IME_WAIT的自动关闭时间（默认4分钟）

②windows下的大端口服务（虽然系统总共可使用的Ports有65536个，但从本机连到外部网路(Outbound Connections)的连线埠最多只会使用到5000个而已【此为系统默认值】）

操作如下：

 

3.重启

 

四、结论

由于大量的TIME_WAIT连接未被释放，导致占用的端口资源一直未被回收，出现了缓冲区空间不足的问题，应用也总是自动断线。

 

附：LINUX更改socket连接数与TIMEOUT时间

修改系统socket最大连接数

在文件/etc/security/limits.conf最后加入下面两行：

* soft nofile 32768

* hard nofile 32768

 

缩小2MSL的时长、允许重用处于TIME_WAIT状态的TCP连接、快速回收处于 TIME_WAIT状态的TCP连接

修改/etc/sysctl.conf，添加如下几行：

 

#改系統默认的TIMEOUT时间
net.ipv4.tcp_fin_timeout=2

#启重用，允许将TIME_WAIT sockets重新用于新的TCP连接 默认为0表示关闭
net.ipv4.tcp_tw_reuse=1

#开启TCP连接中TIME_WAIT sockets的快速回收 默认为0 表示关闭
net.ipv4.tcp_tw_recycle=1

 

 

转载于:https://www.cnblogs.com/tudachui/p/9889649.html