nginx到tomcat有大量CLOSE_WAIT状态连接

nginx到tomcat有大量CLOSE_WAIT状态连接

  1. 原因总结:

    1. 资源未及时释放

      1. 数据库连接未及时释放,数据库连接池满后新的请求阻塞:https://blog.csdn.net/yu616568/article/details/44677985

      2. httpclient创建的socket连接未及时释放,连接池占用满:https://blog.csdn.net/zhang4852898/article/details/91607636

        如:当Server的后端用client类别连到Remote端,连线逾时遭到Remote端断线,此时被动关闭连线时,后端若没处理好关闭,就会造成CLOSE_WAIT

      3. 代码中存在线程锁但执行玩后未及时释放,新的请求阻塞:https://blog.csdn.net/q512224549/article/details/89483432

    2. nginx配置引用lua脚本获取资源延迟,客户端主动断开了连接:https://www.cnblogs.com/husbandmen/p/10116285.html

    3. 服务端接口代码不规范,服务端接口处理耗时较长,客户端主动断开了连接:https://www.cnblogs.com/grey-wolf/p/10936657.html

      1. 如jvm GC 时间过长、服务器load 太高、tomcat jvm 内存溢出
    4. 某一版Tomcat或JVM的bug造成無法關閉socket:https://www.cnblogs.com/saaav/p/6258831.html

    5. 几乎不存在的情况:程序存在死循环

  2. 原因3问题复现:https://www.cnblogs.com/grey-wolf/p/10936657.html

    1. 通过Linux服务器部署一个post的demo,以博客源码建立一个http的post请求进行了一个复现。

      1. 服务器通过netstat -anop|grep 服务器ip:8280,建立连接后为ESTABLISHED,客户端10s后断开连接后状态是CLOSE_WAIT,服务器线程休眠结束回传数据后连接消失
      2. 客户端通过netstat -ano|findstr 服务器ip:8280,建立连接后为ESTABLISHED,客户端10s后断开连接后状态是FIN_WAIT_2,服务器线程休眠结束回传数据后连接消失
      3. 判断服务器线程休眠结束能正常回传数据是通过wireshark抓包知晓
      • tomcat常用的三个状态是:

        • ESTABLISHED 正在通信
        • TIME_WAIT 主动关闭
        • CLOSE_WAIT 表示被动关闭
  3. 问题排查:wireshark抓包,分析dump日志等

    • tcp状态变迁图

      tcp_status_flow

      重点关注下面红色部分:

      tcp_important

      当一个tcp实体建立连接后,一直处于下面的established状态。

      上图红色框框起来的部分表示:

      收到客户端的FIN(上图红色的recv:FIN),服务端回应ACK。(上图红色的send:ACK)。然后服务端进入了CLOSE_WAIT状态。

      • 然后在这个阶段服务端因为上述各种原因阻塞,无法返回新的FIN,tcp连接阻塞,且没有及时断开清理这些没有响应的连接,请求不断增多,阻塞的连接数也越多,直到tomcat连接池用完使tomcat假死。
  4. 网上找到的解决方案:

    1. 修改程序代码,及时释放使用资源

    2. 修改Linux配置文件,使服务器及时回收超时连接。(无效)

      1. vim /etc/sysctl.conf在文件末端加上以下内容:

        net.ipv4.tcp_syncookies = 1	#表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭;
        net.ipv4.tcp_tw_reuse = 1	#表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;
        net.ipv4.tcp_tw_recycle = 1	#表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。
        net.ipv4.tcp_fin_timeout = 30	#修改系統默认的 TIMEOUT 时间
        
        • 结果:无效,该参数是对于断开请求发起方的配置,在复现场景中服务器为断开请求的接收方

          在复现场景中,当30s后客户端发出FIN请求断开后,服务端进入CLOSE_WAIT状态,再过了30s后,如果tcp_fin_timeout参数生效,服务端应处于LAST_ACK状态或无tcp连接,但一直到120s后接口休眠结束处理完请求发出FIN,但断开发起方即客户端已断开,故服务器才处于LAST_ACK状态,一段时间后TCP连接被回收,在休眠期间服务器一直为CLOSE_WAIT状态

        net.ipv4.tcp_keepalive_time = 30	#启用 keepalive 时,TCP 30发送一次 keepalive 消息。
        #probe2次(每次2秒)不成功,内核才彻底放弃,认为该连接已失效
        net.ipv4.tcp_keepalive_probes = 2
        net.ipv4.tcp_keepalive_intvl = 2
        
        • 结果:无效,jmeter中无论是否勾选了Keepalive都不不生效

          在复现场景中,当30s后客户端发出FIN请求断开后,服务端进入CLOSE_WAIT状态,再大概过了34s后,如果tcp_keepalive_time参数生效,服务端应处于LAST_ACK状态或无tcp连接,但一直到120s后接口休眠结束处理完请求发出FIN,但断开发起方即客户端已断开,故服务器才处于LAST_ACK状态,一段时间后TCP连接被回收,在休眠期间服务器一直为CLOSE_WAIT状态

      2. 执行 /sbin/sysctl -p 让参数生效

      3. 最终结果:无效,只有当接口处理请求完成后,系统才会回收这些TCP连接,如果接口存在异常则连接一直存在

        在复现场景中,未配置参数的情况下,当10s后客户端发出FIN请求断开后,服务端进入CLOSE_WAIT状态,再过了50s后,接口休眠结束处理完请求发出FIN,但断开发起方即客户端已断开,故服务器处于LAST_ACK状态,一段时间后TCP连接被回收

    3. 由应用层如tomcat发出fin标志(无论是代码结束正常发送还是超时后发送),使传输层的tcp连接断开,接收关闭请求方(异常的服务端)结束CLOSE_WAIT状态

      1. 思路:设置tomcat配置文件中的connectionTimeout和keepAlivetimeout属性
        1. 结果:无论设置两个时间变长还是变短都无效
    4. 暴力杀死进程法:

      1. https://github.com/rghose/kill-close-wait-connections
      2. https://www.experts-exchange.com/questions/20568402/How-to-clear-CLOSE-WAIT-state-of-a-TCP-connection.html
      3. http://www.shellhacks.com/en/HowTo-Kill-TCP-Connections-in-CLOSEWAIT-State
  • 1
    点赞
  • 1
    收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:书香水墨 设计师:CSDN官方博客 返回首页
评论

打赏作者

Jancy丶

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值