视频1 视频21 视频41 视频61 视频文章1 视频文章21 视频文章41 视频文章61 推荐1 推荐3 推荐5 推荐7 推荐9 推荐11 推荐13 推荐15 推荐17 推荐19 推荐21 推荐23 推荐25 推荐27 推荐29 推荐31 推荐33 推荐35 推荐37 推荐39 推荐41 推荐43 推荐45 推荐47 推荐49 关键词1 关键词101 关键词201 关键词301 关键词401 关键词501 关键词601 关键词701 关键词801 关键词901 关键词1001 关键词1101 关键词1201 关键词1301 关键词1401 关键词1501 关键词1601 关键词1701 关键词1801 关键词1901 视频扩展1 视频扩展6 视频扩展11 视频扩展16 文章1 文章201 文章401 文章601 文章801 文章1001 资讯1 资讯501 资讯1001 资讯1501 标签1 标签501 标签1001 关键词1 关键词501 关键词1001 关键词1501 专题2001
解决MySQL建立连接问题,快速回收复用TCP的TIME_WAIT
2020-11-09 19:11:13 责编:小采
文档
 最近同事遇到一个问题,使用python开发的工具在执行的时候无法和MySQL建立连接,其最直接的现象就是满篇的TIME_WAIT,最后通过调整tcp_timestamps参数问题得以解决,再次记录一下这次解决的经验总结。

ps:不过先汗颜一个,对基础的tcp知识太不敏感了,需要回炉重新学习啊。

一、看下TIME_WAIT产生的原因

大家都知道建立连接是著名的三次握手机制。

那么如何关闭连接呢? 其实也是著名的四次握手机制。

TIME_WAIT就产生在四次握手的的主动关闭方,而server端会进入close状态。

那么TIME_WAIT什么时候会消失呢?LINUX会在2MSL时间内消失。(MSL是最大分段生存期,默认为2分钟)

二、无法建立连接的原因

由于同事的脚本的用途是进行采集数据后的写入操作,为了加快速度故使用python的map功能并发写入数据库,当在脚本执行的服务器上报错后,发现满篇都是TIME_WAIT的现象。

经过我们内部讨论,初步认为是由于TIME_WAT没有快速回收导致Linux的可用端口被沾满导致无发建立连接,和MySQL的设置没有关系。

查看目前Linux可用端口范围:

[me]sysctl -a|grep ip_local_port_range net.ipv4.ip_local_port_range = 3276861000

查看当前占用的端口直接用netstat就可以了:

netstat -nat|grep -i time_wait|wc -l

三、如何解决?

对于TCP链接的优化大家都知道的三个参数:tcp_tw_reuse、tcp_tw_recycle、tcp_timestamp

1、我们先看看这3个参数的定义和作用。

tcp_tw_reuse:用来使用time-wait状态的sockets重用

Allow to reuse TIME-WAIT sockets for new connections when it is
safe from protocol viewpoint. Default value is 0.It should not be changed without advice/request of technical experts.

tcp_tw_recycle:用来加速对time-wait

Enable fast recycling TIME-WAIT sockets. Default value is 0.It should not be changed without advice/request of technical experts.

tcp_timestamp:在TCP的包头添加时间戳

Enable timestamps as defined in RFC1323

2、调整记录

我们先查看服务器的状态,发现reuse和recycle的参数都是1,但是time_wait并没有被很快的回收,也没有被快速的重用。

[root ~]# cat /proc/sys/net/ipv4/tcp_tw_reuse 1[root ~]# cat /proc/sys/net/ipv4/tcp_tw_recycle 1

后来发现是由于tcp_timestamp这个参数设置为0的原因

[root ~] cat /proc/sys/net/ipv4/tcp_timestamps 0

将这个参数置为1之后,time_wati的状态立刻下降了很多,脚本也可以正常执行了。看来tcp_timestamp非常关键。

3、探寻原因

但是,究竟是tcp_tw_reuse起作用了? 还是tcp_tw_recycle起作用了?我们还是不知道,只能从现象得知问题解决了。

我们将tcp_tw_recycle的值设定为0之后,再次测试,再次出现了大量的time_wait现象。

为了证明tcp_tw_recycle真正起作用了,我们再次将tcp_tw_reuse参数设置为1,这时候也再次出现了大量的time_wait的现象。

看来,最终我们的结论是同时开启tcp_tw_recycle,tcp_tw_reuse和tcp_timestamp才能真正做到快速回收和服用time-wait状态的socket。

从stackoverflow上看到的一个答案比较靠谱。点这里

但是同时也发现,网上有很多信息显示,如果同时开启tcp_tw_recycle和tcp_timestamp会出现问题。主要是由于TCP的一种行为

RFC 1323  TCP Extensions for High Performance  Jacobson, Braden, & Borman
An additional mechanism could be added to the TCP, a per-hostcache of the last timestamp received from any connection.This value could then be used in the PAWS mechanism to rejectold duplicate segments from earlier incarnations of theconnection, if the timestamp clock can be guaranteed to haveticked at least once since the old connection was open.Thiswould require that the TIME-WAIT delay plus the RTT togethermust be at least one tick of the sender's timestamp clock.Such an extension is not part of the proposal of this RFC.

三、结论

1、开启tcp_timestamp是开启tcp_tw_recycle,tcp_tw_reuse和tcp_timestamp的前提条件。

2、但是在nat模式下,不用将tcp_tw_recycle和tcp_timestamp同时开启,这会造成tcp超时引发故障。

附录:

https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

http://lxr.free-electrons.com/source/net/ipv4/tcp_minisocks.c#L92

http://www.ietf.org/rfc/rfc1323.txt

下载本文
显示全文
专题