Resin服务器出现大量的ESTABLISHED和TIME_WAIT连接造成响应缓慢

Resin服务的端口为8080,执行 lsof -i:8080 命令出现大量的ESTABLISHED连接:

然后执行netstat -n | awk ‘/^tcp/ {++y[$NF]} END {for(w in y) print w, y[w]}’ 命令发现存在大量状态为TIME_WAIT的连接:

简单来说,
ESTABLISHED表示正在进行网络连接的数量,
TIME_WAIT表示表示等待系统主动关闭网络连接的数量,
CLOSE_WAIT表示被动等待程序关闭的网络连接数量,因此TIME_WAIT跟服务器的配置有关,而CLOSE_WAIT跟程序进行网络连接有关了,通常是程序没有主动关闭网络连接所致。

上图中显然TIME_WAIT的数量太多了,需要对服务器进行配置。对 /etc/sysctl.conf 文件做如下设置(包含每个配置项的说明):

//*对于一个新建连接,内核要发送多少个 SYN 连接请求才决定放弃,不应该大于255,默认值是5,对应于180秒左右时间   
net.ipv4.tcp_syn_retries=2 
#net.ipv4.tcp_synack_retries=2 
//表示当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时,改为300秒 
net.ipv4.tcp_keepalive_time=1200 
net.ipv4.tcp_orphan_retries=3 
//表示如果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2状态的时间 
net.ipv4.tcp_fin_timeout=30   
//表示SYN队列的长度,默认为1024,加大队列长度为8192,可以容纳更多等待连接的网络连接数。 
net.ipv4.tcp_max_syn_backlog = 4096 
//表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭 
net.ipv4.tcp_syncookies = 1 

//表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭 
net.ipv4.tcp_tw_reuse = 1 
//表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭
net.ipv4.tcp_tw_recycle = 1 

//减少超时前的探测次数   
net.ipv4.tcp_keepalive_probes=5   
//优化网络设备接收队列   
net.core.netdev_max_backlog=3000

修改保存之后执行 /sbin/sysctl -p让参数生效即可。这里需要说明几点:
(1) net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle的开启都是为了回收处于TIME_WAIT状态的资源,net.ipv4.tcp_fin_timeout这个时间可以减少在异常情况下服务器从FIN-WAIT-2转到TIME_WAIT的时间,net.ipv4.tcp_keepalive_*一系列参数,是用来设置服务器检测连接存活的相关配置。

(2) 如果客户端访问是NAT网络,不要开启net.ipv4.tcp_tw_recycle或者在服务端关闭time stamp (echo 0 /proc/sys/net/ipv4/tcp_timestamps),参考这篇文章:不要在linux上启用net.ipv4.tcp_tw_recycle参数【经验总结】tcp_tw_recycle参数引发的故障
(3) Windows服务器的解决方法请参考这篇文字:在 Windows 上遇到非常多 TIME_WAIT 連線時應如何處理

另外如果出现大量的CLOSE_WAIT说明程序在进行网络连接的时候没有主动关闭连接,比如使用HttpClient调用网络连接的时候,当出现错误的时候没有调用abort()方法,或者网络连接结束之后没有调用close方法等等,具体在源代码中进行排查即可。

展开阅读全文

echo测试服务器和客户端,大量连接失败,关闭时又会出现僵尸established连接

03-25
写了个测试客户端和服务器服务器使用IOCP,客户端使用select。客户端开始时指定开启512个socket连接服务器连接失败则重新连接连接成功,则发送数据到服务器服务器收到数据就回复同样的字符给客户端。 但是出现以下情况: 1.客户端开启512个连接,只有一部分连接的上。错误的提示是10060,连接超时,服务器accept的错误是64(网络明不再可用)。 感觉是不是,服务器连接上了,没来及处理,导致客户端删除,服务器处理时,又晚了。有没方法解决?一开始猜测是不是select后,在exceptfdset中可以不用理他,继续投递,测试后感觉又不是这个样子。因为,我这样测试:把select等待时间弄成0,0即刻返回,但是accept也有既不是成功也不是except中,说明不出错是会去等待的,不是非成功就失败的。但这种TimeOut是正常的吗?可以把这个TimeOut时间调长点吗? 2.客户端关闭后,他的一部分socket关不掉,服务器上netstat查看发现有部分established连接依旧在。 是不是客户端某些连接关闭时发送的FIN丢失或未发送?我认为如果对这种对端实际关闭的established连接,进行send,投递后,会返回错误,因为我认为send后会得到回馈,就如syn-ack一样。但是测试后发现,send居然还是可以成功,搜索网络后,得到的结论是,send,仅仅是发送到系统缓存,成功只是说明发送到缓冲区了,对端收得到否,得不到回馈。不知这个结论是不是正确的?这种僵尸established连接是不是有可能在对端不正常关闭(拔网线等极端状态)时存在?目前我使用开启keep-alive选项解决。这种僵尸established连接,程序会稍后recv得到通知而断开。 最后,经过分析和实验,我感觉,以上的问题是网络不可阻的问题,最后我只是在程序中为每个连接开启了keep alive的选项。

Git 实用技巧

11-24
这几年越来越多的开发团队使用了Git,掌握Git的使用已经越来越重要,已经是一个开发者必备的一项技能;但很多人在刚开始学习Git的时候会遇到很多疑问,比如之前使用过SVN的开发者想不通Git提交代码为什么需要先commit然后再去push,而不是一条命令一次性搞定; 更多的开发者对Git已经入门,不过在遇到一些代码冲突、需要恢复Git代码时候就不知所措,这个时候哪些对 Git掌握得比较好的少数人,就像团队中的神一样,在队友遇到 Git 相关的问题的时候用各种流利的操作来帮助队友于水火。 我去年刚加入新团队,发现一些同事对Git的常规操作没太大问题,但对Git的理解还是比较生疏,比如说分支和分支之间的关联关系、合并代码时候的冲突解决、提交代码前未拉取新代码导致冲突问题的处理等,我在协助处理这些问题的时候也记录各种问题的解决办法,希望整理后通过教程帮助到更多对Git操作进阶的开发者。 本期教程学习方法分为“掌握基础——稳步进阶——熟悉协作”三个层次。从掌握基础的 Git的推送和拉取开始,以案例进行演示,分析每一个步骤的操作方式和原理,从理解Git 工具的操作到学会代码存储结构、演示不同场景下Git遇到问题的不同处理方案。循序渐进让同学们掌握Git工具在团队协作中的整体协作流程。 在教程中会通过大量案例进行分析,案例会模拟在工作中遇到的问题,从最基础的代码提交和拉取、代码冲突解决、代码仓库的数据维护、Git服务端搭建等。为了让同学们容易理解,对Git简单易懂,文章中详细记录了详细的操作步骤,提供大量演示截图和解析。在教程的最后部分,会从提升团队整体效率的角度对Git工具进行讲解,包括规范操作、Gitlab的搭建、钩子事件的应用等。 为了让同学们可以利用碎片化时间来灵活学习,在教程文章中大程度降低了上下文的依赖,让大家可以在工作之余进行学习与实战,并同时掌握里面涉及的Git不常见操作的相关知识,理解Git工具在工作遇到的问题解决思路和方法,相信一定会对大家的前端技能进阶大有帮助。
©️2020 CSDN 皮肤主题: 大白 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值