-
我的服务跑着跑着就再也接受不了新连接、报 too many open files,我一查发现成百上千条连接全卡在 CLOSE_WAIT 状态死活不消失,一开始以为是对端没规矩不关连接,最后才搞明白 CLOSE_WAIT 恰恰是对端已经关了、正等着我这边关而我的代码根本就忘了调 close 的深度复盘
我的服务对外提供接口、也作为客户端调下游,运行一段时间后开始变诡异:先偶尔报错,后来直接无法接受任何新连接、日志满屏 too many open files——文件描述符耗尽了,重启能暂时恢复但过一阵又复发,典型的资源泄漏。我用 netstat grep CLOSE_WAIT 一统计倒吸凉气:成百上千条连接处于 CLOSE_WAIT 状态且只增不减。我第一反应是对端怎么用完连接不关,可去查对端它那…- 0
- 0
-
一个调用下游接口后忘了关闭连接的服务,在下游主动断开后留下了一大堆 CLOSE_WAIT,把文件描述符耗尽、再也建不了新连接:一次 CLOSE_WAIT 堆积的深度复盘
服务跑一段时间后大量报 too many open files、建不了新连接,netstat 一看成千上万个 CLOSE_WAIT 只增不减、把 fd 耗尽。根因是调下游接口后没正确 Close 响应体/连接:下游处理完主动关闭它那端发来 FIN,我方收到后进入 CLOSE_WAIT(等我方 close),而代码没 close(异常路径漏关、忘了 defer),连接就永远停在 CLOSE_WAIT…- 2
- 0
-
我的服务跑着跑着就再也连不上下游了,报 too many open files,netstat 一看几千个 CLOSE_WAIT 堆在那,我对着忘记关闭 HTTP 响应体导致连接泄漏这个坑排查大半天的复盘
一个让我对关闭资源彻底敬畏的网络坑,可怕在它是缓慢累积定时爆发的雷:服务刚启动一切正常,运行几小时甚至几天后突然像被掐住喉咙,再也无法建立任何新连接、整个服务瘫痪。需求很常见:服务频繁调下游 HTTP 接口拿数据,我用 Go 写了个调用函数 resp,err := http.Get(url),用完却忘了 resp.Body.Close()。测试和刚上线跑得好好的,运行一段后告警:dial tcp …- 0
- 0
-
三万个 CLOSE_WAIT 压垮服务:看懂 TCP 连接状态机
一个风平浪静的上午,核心服务突然刷出满屏 too many open files,接口大面积超时。调大 ulimit 只撑了十几分钟,一条 netstat 揭开真相:三万八千个 CLOSE_WAIT 死死占着句柄只增不减。从这次句柄耗尽事故出发,这篇文章把 TCP 四次挥手状态机、CLOSE_WAIT 与 TIME_WAIT 的本质区别、连接泄漏的定位与修复、长连接复用、超时设置到优雅关闭,一次讲…- 0
- 0
-
线上 TCP CLOSE_WAIT 堆积排查实录:5 个方法定位到应用层 bug
网关 8 小时后 CLOSE_WAIT 几万个、接口大量超时。本文讲透 TCP 状态机 + 5 种诊断方法(ss/lsof/arthas/tcpdump/bpftrace)+ Apache HttpClient / Jedis / Tomcat / Netty 4 个真实泄漏案例 + 内核参数误解辟谣 + 监控告警 + 预防 checklist。- 2
- 0
CLOSE_WAIT
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×