-
我的服务跑着跑着就再也接受不了新连接、报 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
-
数据库很闲却拿不到连接:连接池耗尽避坑复盘
有个服务平时跑得好好的,可一到流量高峰就突然集体卡死:大量请求超时,日志清一色报 Connection is not available, request timed out after 30000ms——等了 30 秒都没从连接池拿到一个数据库连接。诡异的是数据库本身一点不忙,CPU 内存都很闲、慢查询日志干干净净,明明数据库很空闲我的服务却拿不到连接,问题显然不在数据库而在那个连接池上。盯着监…- 6
- 0
-
数据库连接泄漏完全指南:从一次"服务跑着跑着就 too many connections 卡死"看懂连接池、归还与事务
2022 年我做一个 Web 后端服务每个请求进来都要查几次数据库查用户查订单查配置用数据库这件事我压根没多想第一版我做得很省事用数据库不就是拿一个连接执行 SQL 把结果拿回来需要数据时我连上拿个连接把 SQL 发过去把结果取回来就完事了本地开发时真不错我点几下页面每个请求稳稳查到数据响应又快又准几行代码搞定我心里很踏实可等这个服务真正上线扛起每天几万次请求一串问题冒了出来第一种最先把我打懵服务…- 0
- 0
连接泄漏
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×