网络优化之net.ipv4.tcp_tw_recycle参数
一、概述
二、案例分享
【案例分析1】 最近发现几个监控用的脚本在连接监控数据库的时候偶尔会连不上,报错: Couldn't connect to host:3306/tcp: IO::Socket::INET: connect: Cannot assign requested address 查看了一下发现系统中存在大量处于TIME_WAIT状态的tcp端口 $netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' TIME_WAIT 50013 ESTABLISHED 27 SYN_RECV 1 由于要监控的主机太多,监控的agent可能在短时间内创建大量连接到监控数据库(MySQL)并释放造成的。在网上查阅了一些tcp参数的相关资料,最后通过修改了几个系统内核的tcp参数缓解了该问题: #vi /etc/sysctl.conf net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 #sysctl -p 其中: net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭; net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。 修改完成并生效后,系统中处于TIME_WAIT状态的tcp端口数量迅速下降到100左右: $netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' TIME_WAIT 82 ESTABLISHED 36 ————————————————
案例分析2】 网上的帖子,大多都写开启net.ipv4.tcp_tw_recycle这个开关,可以快速回收处于TIME_WAIT状态的socket(针对Server端而言)。 而实际上,这个开关,需要net.ipv4.tcp_timestamps(默认开启的)这个开关开启才有效果。 更不为提到却很重要的一个信息是:当tcp_tw_recycle开启时(tcp_timestamps同时开启,快速回收socket的效果达到),对于位于NAT设备后面的Client来说,是一场灾难——会导到NAT设备后面的Client连接Server不稳定(有的Client能连接server,有的Client不能连接server)。也就是说,tcp_tw_recycle这个功能,是为“内部网络”(网络环境自己可控——不存在NAT的情况)设计的,对于公网,不宜使用。 通常,“回收”TIME_WAIT状态的socket是因为“无法主动连接远端”,因为无可用的端口,而不应该是要回收内存(没有必要)。即,需求是“Client”的需求,Server会有“端口不够用”的问题吗?除非是前端机,需要大量的连接后端服务——即充当着Client的角色。 正确的解决这个总是办法应该是: net.ipv4.ip_local_port_range = 9000 6553 #默认值范围较小 net.ipv4.tcp_max_tw_buckets = 10000 #默认值较小,还可适当调小 net.ipv4.tcp_tw_reuse = 1 # net.ipv4.tcp_fin_timeout = 10 # ————————————————