[20200312]不要设置net.ipv4.tcp_tw_recycle=1.txt

[20200312]不要设置net.ipv4.tcp_tw_recycle=1.txt --//昨天认真看了2篇blog： https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux --//中文翻译： http://www.cnxct.com/coping-with-the-tcp-time_wait-state-on-busy-linux-servers-in-chinese-and-dont-enable-tcp_tw_recycle/ --//里面提到不要设置net.ipv4.tcp_tw_recycle=1。TIME_WAIT状态问题不是太严重，可以完全不理会它。 --//我仔细阅读，说真的许多一些细节还不是很理解。我开始接触主要是不理解生产系统rac环境为什么这么多state=TIME_WAIT. --//现在看来自己纯粹是画蛇添足，浪费时间,不过自己感觉还是学到许多东西. --//现在我大概知道原因,做一些总结： 1.实际上对于正常数据库应用，正常退出应用程序，实际上state=TIME_WAIT发生在客户端，这也是我开始的困惑。服务端不应该这个多   state=TIME_WAIT。我的问题实际上由此展开^_^. https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux TCP state diagram Only the end closing the connection first will reach the TIME-WAIT state. The other end will follow a path which usually permits to quickly get rid of the connection. --//只有先关闭连接的结束才会达到TIME-WAIT状态.. 另一端将沿着通常允许快速摆脱连接。 2.我们使用dblink短连接很多，这时服务端实际上变成客户端，导致state=TIME_WAIT多。 3.exadata 出厂设置 net.ipv4.tcp_timestamps = 0，即使我设置net.ipv4.tcp_tw_recycle=1也无效，毫无作用，这也是我在测试中遇   到的第二个困惑。我想oracle这样做可能有它的道理, 不会使用特殊的方式规避其它dba设置net.ipv4.tcp_tw_recycle=1的问题。 --//exadate 的 /etc/sysctl.conf设置,不知道前面# 12650500 ,oracle内部表示什么? # 12650500 net.ipv4.tcp_timestamps = 0 --//再次提醒建议不要设置net.ipv4.tcp_tw_recycle=1 解决大量state=TIME_WAIT问题。 4.还有1个原因导致服务端state=TIME_WAIT增多,就是客户端连接RAC数据库使用scan ip,会跳转到vip ip，这样一旦大量用户以这种方式   登录，就是在服务端产生大量的state=TIME_WAIT连接。 5.还有前台客户端基本都是XP机器。我的测试MS关于tcp_timestamps缺省设置是关闭的，至少在windows 7，windows 2003服务器版下,XP   我不知道。   这样即使服务端设置  net.ipv4.tcp_timestamps = 1 和 net.ipv4.tcp_tw_recycle=1 依旧在服务端生产大量的state=TIME_WAIT. 不过linux机器缺省设置都是net.ipv4.tcp_timestamps = 1。 --//再次提醒建议不要设置net.ipv4.tcp_tw_recycle=1 解决大量state=TIME_WAIT问题。   --//注：我在这里测试时又犯了一个错误，以为跨网段的机器不能快速回收TIME_WAIT，实际上是我的测试机器windows7的 --//tcp_timestamps缺省设置是关闭的. 6.有一个可行的方法减少大量state=TIME_WAIT连接,就是在一些中间件服务器可以不要使用scan ip连接数据库，采用老的vip ip就可以   减少这样的情况。改动涉及中间件服务器，影响不大,这是比较可行成本最低的改进方法,仅仅对rac环境有效. --//话又反活来讲,如果不是rac环境,可能就看不到大量的state=TIME_WAIT状态. 7.如果网络链接通过公网或者NAT转换，肯定不能设置net.ipv4.tcp_tw_recycle=1. 由于我们一些应用通过公网，当我设置   net.ipv4.tcp_tw_recycle=1   net.ipv4.tcp_timestamps=1 --//确实有少量的客户端(实际上也就2台)无法连接服务器的情况，甚至内网的机器也出现一台，我不知道为什么。最终还原原来设置   net.ipv4.tcp_tw_recycle=0   net.ipv4.tcp_timestamps=0 8.内存 CPU 资源消耗很少。参考链接的测试：https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux 9.state=TIME_WAIT对应用影响很小，4元素组成一个连接，oracle 建议内核参数设置net.ipv4.ip_local_port_range = 1024 65000   支持端口数量达到64000，这样如果不达到每秒60000/60 = 1000 个/连接，基本影响可以忽略。   我感觉不能达到这个数量，至少我自己没见过。我们数据库高峰也就是200个/每秒连接。 10.TIME_WAIT状态的消失时间在linux下写死的,在net/tcp.h头文件里面的,许多链接提示修改net.ipv4.tcp_fin_timeout是错误的: --//除非修改头文件内容,重新编译内核!! #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT                   * state, about 60 seconds */ #define TCP_FIN_TIMEOUT TCP_TIMEWAIT_LEN                                  /* BSD style FIN_WAIT2 deadlock breaker.                   * It used to be 3min, new value is 60sec,                   * to combine FIN-WAIT-2 timeout with                   * TIME-WAIT timer.                   */ 11.windows下可以修改TIME_WAIT状态的消失时间: --//在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters上添加一个DWORD类型的值TcpTimedWaitDelay，值 --//就是秒数，最小30秒,不能低于该值.注要重启机器才能生效: --//timewait.reg REGEDIT4 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters] "TcpTimedWaitDelay"=dword:0000001e 12.windows下设置tcp_timestamps: --//按照https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc938205(v=technet.10)?redirectedfrom=MSDN Tcp1323Opts --//注:1323 应该是关联RFC 1323文档. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters Data type  Range            Default value ------------------------------------------ REG_DWORD  0 | 1 | 2 | 3    3 Value  Meaning 0 (00) Timestamps and window scaling are disabled. 1 (01) Window scaling is enabled. 2 (10) Timestamps are enabled. 3 (11) Timestamps and window scaling are enabled. --//按照介绍MS缺省应该是打开tcp_timestamps的。不过我发现在windows 7,windows 2003下不是这样。修改为2或者3.我仅仅测试修改3 --//的情况. REGEDIT4 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters] "Tcp1323Opts"=hex:03 13.最后简单讲一下测试方法,使用tnsping server_ip count > /dev/null,这样比较简单快捷,这时state=TIME_WAIT出现在服务端,使用    netstat -ntop 或者ss -nto 观察. # seq 10000 | xargs -IQ bash -c "ss -tano state time-wait | ts.awk ; sleep 1" or # seq 10000 | xargs -IQ bash -c "netstat -nto | grep TIME-WAIT | ts.awk ; sleep 1" $ cat $(which ts.awk) # /bin/bash gawk '{ print strftime("[%Y-%m-%d %H:%M:%S]"), $0 }' 在服务端net.ipv4.tcp_tw_recycle=1,net.ipv4.tcp_timestamps=1,客户端net.ipv4.tcp_timestamps=1的情况下服务端出现TIME_WAIT很快消失. 在服务端net.ipv4.tcp_tw_recycle=1,net.ipv4.tcp_timestamps=1,客户端net.ipv4.tcp_timestamps=0的情况下服务端出现TIME_WAIT等60秒消失. 在服务端net.ipv4.tcp_tw_recycle=1,net.ipv4.tcp_timestamps=0,                                       服务端出现TIME_WAIT等60秒消失. 在服务端net.ipv4.tcp_tw_recycle=0,net.ipv4.tcp_timestamps=N(N=1,0)                                 服务端出现TIME_WAIT等60秒消失. --//大家可以自行测试.测试结果就不贴上来了,有点繁琐. --//从这里也看出如果大量的客户端是windows，没有打开tcp_timestamp,在服务端设置 --//net.ipv4.tcp_tw_recycle=1,net.ipv4.tcp_timestamps=1也一样毫无用处. 14.演示一个服务端产生大量TIME_WAIT的例子: --//还是另外写一篇,不然写的又太长了. --//最后再次提醒建议不要设置net.ipv4.tcp_tw_recycle=1来解决大量state=TIME_WAIT问题,重要的问题说三遍，国内大量的链接这样 --//做可能会导致一些网络故障非常难查，除非应用都是非常纯的内网环境里面。