established 太多_ss -s closed过多,NON_ESTABLISHED告警

博客内容涉及了阿里云服务器出现报警,疑似由于连接数过多引起。作者尝试通过调整TCP keepalive参数来解决time_wait状态过长的问题,但未见成效。使用`ss`命令检查连接状态,发现大量closed连接,并通过`ps`命令定位到6646进程,处理后closed连接数量下降。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

image.png

阿里云报警,以为是连接数上去了,检查无果。

又认为是TCP断开连接时候time_wait时间过长,于是

sysctl -w net.ipv4.tcp_keepalive_time=1800

sysctl -w net.ipv4.tcp_keepalive_probes=3

sysctl -w net.ipv4.tcp_keepalive_intvl=15

仍然无果。

执行 ss -s

# ss -s

Total: 65957 (kernel 66625)

TCP: 65599 (estab 36, closed 65534, orphaned 0, synrecv 0, timewait 3/0), ports 0

Transport Total IP IPv6

* 66625 - -

RAW 0 0 0

UDP 24 17 7

TCP 65 57 8

INET 89 74 15

FRAG 0 0 0

java 6646 root *786u sock 0,7 0t0 1431969496 protocol: TCP

java 6646 root *787u sock 0,7 0t0 1431971854 protocol: TCP

java 6646 root *788u sock 0,7 0t0 1431970488 protocol: TCP

java 6646 root *789u sock 0,7 0t0 1431969497 protocol: TCP

java 6646 root *790u sock 0,7 0t0 1431960142 protocol: TCP

查找6646进程 ps -ef|grep 6646

处理后,再次执行 ss -s,closed数量下降

# ss -s

Total: 401 (kernel 1725)

TCP: 90 (estab 36, closed 28, orphaned 1, synrecv 0, timewait 3/0), ports 0

Transport Total IP IPv6

* 1725 - -

RAW 0 0 0

UDP 25 17 8

TCP 62 56 6

INET 87 73 14

FRAG 0 0 0

### TCP 连接状态转换的原因分析 当服务器上的某个连接经历从 `ESTABLISHED` 到 `CLOSE_WAIT`,再到 `LAST_ACK` 并最终到达 `CLOSED` 的过程时,这通常表明客户端主动关闭了该连接,而服务器端未能及时响应或处理这一事件。以下是每种状态的具体含义及其可能引发此序列的原因: #### 1. **ESTABLISHED** 这是正常的双向通信阶段,在这个状态下,双方都可以发送数据。 #### 2. **CLOSE_WAIT** 进入 `CLOSE_WAIT` 表明远程主机已经发出了 FIN 数据包来请求终止连接,但是本地应用程序尚未调用 close() 函数以释放资源。这意味着服务器程序可能存在逻辑错误或者性能瓶颈,未正确处理来自客户端的断开信号[^3]。 ```bash netstat -an | grep CLOSE_WAIT ``` 上述命令可以帮助识别处于这种状态下的连接数量。 #### 3. **LAST_ACK** 在此阶段,本机已回应了一个 FIN 包给对方,并等待最后一个 ACK 来确认整个会话结束。如果发现大量此类状态,则可能是由于网络延迟或是某些实现细节导致超时设置不合理所致[^4]。 #### 4. **CLOSED** 一旦收到最后那个ACK之后,就正式进入了closed状态表示这条链路已经被完全拆除不再存在任何活动流量。 --- ### 解决方案建议 针对以上提到的各种潜在问题可以采取如下措施加以改善: - 定期检查服务端应用层代码是否存在遗漏close操作的情况; - 增加日志记录以便于追踪哪些具体情况下会产生过多的close_wait实例; - 对长时间保持在last_ack中的链接考虑适当调整tcp_fin_timeout参数值; 可以通过修改Linux系统的内核参数优化TCP行为模式比如减少TIME-WAIT队列长度等做法缓解压力. ```bash echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout ``` 上面的例子展示了如何降低默认fin timeout时间至更短周期从而加速清理processes lingering too long within last ack phase.[^5] --- ### 结论 综上所述,通过合理配置操作系统层面的相关选项以及改进软件设计缺陷能够有效防止不必要的资源消耗并提升整体效率表现。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值