提示
X
本案例来自tskb,请前往tskb修改源内容:立即前往
'>

【AD】节点服务器存在大量close_wait状态连接,导致服务器无法正常工作

|

问题描述

虚拟服务访问非常卡慢,最终发现服务器存在大量close_wait状态的连接,导致服务器不能正常工作,重启后才能恢复。

有效排查步骤

1、通过分析故障时的数据包,下面这条异常连接完全符合上述分析,服务器在08:15:07收到负载的FIN,并且ACK确认后,过了26s后才在08:15:33关闭连接发送FIN,对照上述tcp状态机,服务器就会在close_wait停留26s,而close_wait状态的连接是会消耗服务器资源的,太多就会导致服务器异常。


2、从下面这个异常连接可以看到,服务器ACK确认收到负载的请求后,过了1分08秒还没有应答,导致请求超时,说明此时服务器可能阻塞无法及时处理请求。


3、再通过下面两条连接对比,可以发现上面的这条连接存在异常:负载发送的FIN服务器没有及时确认,导致负载有重传,而且重传后的FIN,服务应答ack接收窗口win=0,而对比正常情况下的ack,接收窗口win不会为0。



4、最后跟服务器工程师沟通,服务器有开keep-alive,但是从抓包中可以看到存在大量的连接服务器并没有keep-alive,客户端发送了connection:keep-alive,服务器直接回复了connection:close,并且主动发送FIN关闭连接,负载作为客户端和服务器之间的代理,在收到connection:close应答时也会主动发送FIN关闭连接,等于是双方都想要主动关闭连接,那么此时就有先有后,下面的抓包可以看到,有同时FIN的,此时负载和服务器就会都进入time_wait状态;也有负载先FIN,服务器后FIN的,此时负载进入time_wait状态,服务器就会进入close_wait状态。







根因

从TCP协议状态机可知,tcp连接的一端收到FIN并且发送ACK确认后,进入close_wait,正常情况下此时只要关闭连接发送FIN就会进入last_ack状态。服务器上有大量的close_wait,说明服务器在收到负载的FIN后,没有立即发送FIN关闭连接。



解决方案

基于以上分析,通过负载访问服务器,服务器更容易进入close_wait状态,但是只要服务器正常处理关闭连接,那么就不会出现close_wait大量停留的情况,所以需要从两方面进行下一步排查:
1、 服务器上需要针对上述的疑点进行分析排查,但涉及第三方调整可能会比较难。
2、AD负载上可以通过调整配置避免让服务器进入close_wait状态。
(1) 把七层虚拟服务改成四层,这样负载只是纯转发,不会自己主动关闭连接,连接是否主动关闭由客户端决定。
(2) 去掉针对服务器的connect_tcp探测,改为其他类型的探测。

我要分享
文档编号: 199419
作者: admin
更新时间: 2023-04-04 09:36
适用版本: