-
我的服务调用下游一切正常,可一到高峰期就大量报连接失败、报错说没有可用端口了,我的机器明明负载不高、内存也充足,排查半天发现是几万个处于 TIME_WAIT 状态的连接把本地端口耗光了的深度复盘
我有个服务要频繁调用一个下游接口,写法很干净:每次调用都新建连接、发请求、拿响应、然后立刻关掉,用完即走。平时跑得好好的。可一到流量高峰就灾难了:服务大量报 Cannot assign requested address(没有可用端口),新的下游建连接连失败。我以为机器扛不住了,可一看监控傻眼:CPU 不高、内存充足、下游也好好的,机器很闲,凭什么连接就建不出来?直到我 netstat 统计连接状…- 0
- 0
-
我的服务用连接池复用长连接调下游,平时好好的,却总在低峰期之后偶发 connection reset,排查发现是连接被对端的空闲超时悄悄关了、我的连接池却还留着这条已死的连接照样拿来用的深度复盘
我的服务用连接池复用到下游的长连接(避免每次新建,这是对的)。平时高峰期一切正常,可总在低峰期之后(凌晨流量小或一段时间没请求后)出怪事:之后的第一批请求偶发失败、报 Connection reset by peer 或 Broken pipe,而重试一下又成功了。复盘才搞懂:连接池为复用会把用完的长连接留着、放回池里下次直接用;可一条连接空闲太久,对端(下游服务、或中间的 LB/NAT/防火墙)…- 4
- 0
-
调用下游服务的接口慢得离谱、机器上还堆了几万个 TIME_WAIT,我抓包才发现每发一个请求都在重新三次握手加 TLS 握手:一次 HTTP 连接没复用、每次新建连接把建连开销付了无数遍的深度复盘
我写了个服务频繁调用下游 HTTP 接口,压测时 QPS 怎么也上不去、延迟还高,机器上 netstat 里密密麻麻几万个 TIME_WAIT。一开始以为下游慢,抓包才发现:我每发一个 HTTP 请求都在新建一个全新 TCP 连接——请求前三次握手+TLS 握手,请求后立刻关闭,大部分时间耗在建连和关连上、真正传输反而很少;而主动关闭的连接大量堆在 TIME_WAIT 耗端口。根因是每次请求 ne…- 2
- 0
-
我的服务从连接池取到的长连接其实早就"死"了、发请求全卡到超时,可连接池却以为它还活着,我对着连接假死和心跳保活排查了大半天的复盘
做了个调下游 RPC 的服务,用长连接+连接池复用,平时正常,可每当下游重启、或中间防火墙/LB 抖动后,就冒出一批诡异超时:从连接池取到的某些连接一发请求就卡到超时,连接池却一直认为它们可用、反复借出。盯着监控百思不得其解:连接不是好好在池里吗怎么用起来是死的?排查大半天才理解 TCP 长连接的隐蔽陷阱——连接假死:TCP 连接是虚拟约定,不发数据时网络无信号确认对端在;异常断开(对端宕机没发F…- 0
- 0
-
我的 C# 服务跑一段时间就报连接池耗尽、超时连不上数据库,代码看着都正常、连接也都"用完了",我对着 IDisposable 没释放排查了大半天的复盘
用 C# 写的数据服务,刚启动正常,跑上几小时到一天就报 The connection pool has been exhausted(连接池耗尽)、获取连接超时、数据库操作全线卡死,重启又好、过段时间又复发。盯着代码看了又看,每个查询都好好地拿连接、执行SQL、拿结果,逻辑上连接都用完了啊怎么会耗尽?排查大半天才理解 C# 里对资源管理至关重要却极易忽略的概念——IDisposable 与 us…- 0
- 0
-
我的服务调外部接口一到高峰就报"cannot assign requested address"、机器上堆了几万个 TIME_WAIT 连接,我盯着 netstat 排查了大半天才发现连接根本没复用
我的服务频繁调外部 HTTP 接口,一到高峰就大面积报错 cannot assign requested address、延迟还变高。netstat 一看惊呆:机器上堆了几万个 TIME_WAIT。深挖才懂:我每次请求都新建一个 TCP 连接、用完就关、从不复用——后果一是每次都白付三次握手(HTTPS 还有 TLS 握手)的延迟;后果二更致命,主动关闭的连接进入 TIME_WAIT 要停留约 2…- 4
- 0
-
我图省事每次请求都新建一个 HTTP 客户端,平时跑得好好的,流量一上来就连接耗尽、TIME_WAIT 堆成山、还报 too many open files,我查了好几天才懂连接要复用的深度复盘
我的服务频繁调外部 HTTP 接口,图省事每次请求都 new 一个 HTTP 客户端、用完就扔。低流量没事,可一到高峰:请求变慢、TIME_WAIT 堆成山把端口占光、还报 too many open files、甚至连不上外部接口。深究才懂:我把"连接"当成了廉价消耗品频繁创建销毁,可它是昂贵(每次要 TCP 三次握手+HTTPS 的 TLS 握手)又有限(端口约 6 万、f…- 0
- 0
-
服务跑着跑着就报"cannot assign requested address",我以为是端口配置错了,真相却是几万个 TIME_WAIT 把端口耗光了的复盘
一个高频调用下游 HTTP 接口的服务,跑一段时间后开始报 dial tcp: cannot assign requested address。我以为是端口配置错,直到 netstat 一统计——近三万个 TIME_WAIT!根因是我为每个请求都新建 TCP 连接、用完就关,主动关闭方的连接进入 TIME_WAIT 停留 60 秒,每秒几百个累积起来,把本机约 2.8 万个临时端口占光了。这篇从 …- 0
- 0
-
服务跑一段时间就报连接池已满和打开文件太多、重启又复发像慢慢漏气的轮胎:IDisposable 资源没 Dispose 导致连接句柄泄漏的避坑复盘
这是一个跑着跑着就枯竭的慢性病,和我之前遇到的内存泄漏有几分神似但病根不同。现象是我们一个 C# 写的服务刚启动时一切正常,可运行一段时间后几小时到一两天不等就开始报错,一会儿是数据库相关的连接池已满无法从池中获取连接,一会儿又是 Too many open files 打开的文件句柄太多,重启一下好了再跑一段时间又复发,就像一个会慢慢漏气的轮胎跑一阵就瘪补一下又能跑一阵。排查的结果指向了 C# …- 0
- 0
-
端口被 TIME_WAIT 占满:TCP 短连接避坑复盘
这次事故的报错信息第一眼看上去毫无道理:我们一个服务在流量高峰期偶发性地报一个奇怪的错误 Cannot assign requested address 无法分配请求的地址。我盯着这行错误懵了好一会儿:分配地址?我又没在创建什么地址,我只是在调用一个下游的 HTTP 接口而已啊,而且这个错误只在高峰期出现,服务器的 CPU 内存带宽也都不紧张,一个资源充裕的服务器却报无法分配地址,这到底是什么玄学…- 0
- 0
-
偶发 connection reset:连接池复用死连接避坑
有个服务调用下游接口平时好好的,可总会偶发地毫无规律报一个错:Connection reset by peer——连接被对端重置了,频率不高几百次请求一两次、重试又能成功,起初没太当回事,可流量增长后积累的失败量越来越扎眼。这个错最磨人的就是随机性:同样的代码同样的接口绝大多数都好好的偏偏隔一阵冒一个失败。抓了好久包对了好久日志才慢慢拼出真相,藏在一个我从没留意的细节里:这些失败几乎都发生在一段时…- 7
- 0
-
数据库很闲却拿不到连接:连接池耗尽避坑复盘
有个服务平时跑得好好的,可一到流量高峰就突然集体卡死:大量请求超时,日志清一色报 Connection is not available, request timed out after 30000ms——等了 30 秒都没从连接池拿到一个数据库连接。诡异的是数据库本身一点不忙,CPU 内存都很闲、慢查询日志干干净净,明明数据库很空闲我的服务却拿不到连接,问题显然不在数据库而在那个连接池上。盯着监…- 6
- 0
-
下游换了 IP 我却死连旧址:JVM DNS 缓存避坑
下游团队做了一次寻常的机房迁移:换了台机器、域名没变,只把 DNS 指向新 IP,并通知调用方切换无感知。可切换之后我们的服务开始疯狂报错,连接超时、连接被拒,日志全是连不上下游的红字。诡异的是同一台机器上我用 ping 和 curl 访问那个域名,解析到的明明是新 IP、访问也完全正常,可我的 Java 进程就是死活连着那个早已废弃的旧 IP 不撒手;把进程重启一下问题立刻消失。这个重启就好的特…- 2
- 0
-
下游没挂自己先崩:TCP 连接 TIME_WAIT 端口耗尽避坑
一个调用下游接口的服务,平时风平浪静,流量一冲高就大面积抽风:日志刷屏般地报 connection refused,更多的是一句陌生的 cannot assign requested address,可被调用的下游监控却一切正常、根本没挂。我顺着"下游扛不住"查了半天一无所获,直到在本机敲下 ss -s,数字一出来就全明白了——几万个连接密密麻麻堆在 TIME_WAIT,本机用…- 7
- 0
-
三万个 CLOSE_WAIT 压垮服务:看懂 TCP 连接状态机
一个风平浪静的上午,核心服务突然刷出满屏 too many open files,接口大面积超时。调大 ulimit 只撑了十几分钟,一条 netstat 揭开真相:三万八千个 CLOSE_WAIT 死死占着句柄只增不减。从这次句柄耗尽事故出发,这篇文章把 TCP 四次挥手状态机、CLOSE_WAIT 与 TIME_WAIT 的本质区别、连接泄漏的定位与修复、长连接复用、超时设置到优雅关闭,一次讲…- 0
- 0
-
从应用层手写字符串拼接 SQL 有注入风险 + 每次请求新建连接不复用 + 几乎不建索引查询全表扫描 + 循环里逐条查的 N+1 灾难 + 大事务长时间持锁 + 单库单表硬扛全部读写 + 没有慢查询监控不看执行计划凭感觉优化 古老数据库使用体系 → 2026 参数化预编译彻底防注入 + HikariCP 连接池化复用 + 合理索引与覆盖索引 + 批量查询消灭 N+1 + 清晰事务边界与乐观锁 + 读写分离与分库分表水平扩展 + 慢查询日志加 EXPLAIN 执行计划分析 + Redis 旁路缓存与穿透击穿雪崩防护 现代数据库工程体系 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学
12 位 DBA 与后端工程师 87 天把一套跑了七年的粗放数据库使用体系——应用层手写字符串拼接 SQL 随时可能被注入脱库、每次请求新建连接不复用、几乎不建索引查询全表扫描、ORM 在循环里逐条查的 N+1 灾难、一个大事务包住一大堆操作长时间持锁让热点行排队、单库单表硬扛全部读写流量一大主库就 CPU 打满、没有慢查询监控不看执行计划全凭感觉瞎调——用在线 DDL 加双写灰度的稳健方式重构到…- 0
- 0
-
Go context 用 Background 启动后台 goroutine 拖死 PG 连接池的 3 天复盘:1800 个僵尸 goroutine 实战定位 + WithoutCancel 正解
一个 Go 订单聚合服务在 QPS 1200 时数据库连接池被打到 95%,根因是为了让审计归档任务跑完, 同事在异步 goroutine 里把 ctx 替换成了 context.Background, 加上同步 SDK 偶发卡死, 导致 PG 连接被 1800 个僵尸 goroutine 持续 hold。本文复盘 3 天定位过程, 讲清楚 pprof 排查、context 传播机制、contex…- 0
- 0
-
TCP TIME_WAIT 占满端口导致支付网关全面失败的复盘:90 分钟故障 + 5 种修法 + 8 条网络编程纪律
一次"优化"上线把 HttpClient 从连接池改成每次 new,90 分钟内 1.2 万 QPS 把网关本地端口耗尽,所有外部银行接口失败。本文复盘事故全过程、TIME_WAIT 的内核机制、5 种修法实测对比(连接池/tcp_tw_reuse/扩端口范围等)、8 条网络编程纪律、DNS/eBPF/TLS 等深度治理经验。- 0
- 0
-
TCP 连接优化完全指南:从一次"压测 QPS 上不去,CPU 内存全很闲,连接却建不动"看懂三次握手与 TIME_WAIT
2021 年我接手优化公司一个内部 API 网关一场大促前要给它压测看能扛多少 QPS 怎么把它的吞吐做上去这件事我压根没多想第一版我做得很顺手网关嘛收到请求转发给后端服务拿到响应再返回我用最直接的写法每来一个请求就新建一个连接到后端转发完拿到结果把连接关掉就完事了本地拿低并发一压真不错延迟很低转发又快又稳我心里很笃定TCP 连接不就是个透明的管道connect 一下就有了网络快不快只看带宽连接本…- 0
- 0
-
数据库连接池完全指南:从一次"连接数被打满、服务集体 500"看懂连接池
2021 年我做一个 web 服务的后端。每个 HTTP 请求进来都要查一下数据库。第一版我写得很直接请求进来 connect 建一个数据库连接查询然后第一版我连 close 都忘了写。本地开发我自己点几下页面一切正常。压测 QPS 不高也正常。可一上线扛了一阵数据库开始报错 Too many connections 整个服务集体 500。我登上数据库一看连接数被打满了几百个连接全都显示在用可实际…- 0
- 0
-
数据库连接池完全指南:连接池耗尽是如何拖垮整个服务的
2023 年我维护的电商订单服务在大促预热出了事故:高峰期一到大量请求超时,接口从几十毫秒飙到十几秒,日志刷满 HikariPool-1 - Connection is not available, request timed out after 30000ms。我第一反应是连接不够,把 HikariCP 的 maximumPoolSize 从 20 一口气调到 200,缓解十几分钟后事故以更糟的…- 0
- 0
-
高峰期接口大面积超时:一次数据库连接池配置的复盘
流量高峰所有接口集体超时,日志刷满 Connection is not available。我以为数据库扛不住,登上去一看它很闲——问题在连接池。几天彻底治理:读懂报错、连接池不是越大越好、揪出连接泄漏、慢 SQL 头号杀手、超时参数全家桶、连接池监控告警。- 0
- 0
-
服务假死数据库却很闲:一次连接池耗尽排查的复盘
大促时订单服务假死、接口大面积超时,但 CPU 内存和数据库全都很闲。jstack 一抓,几百个线程齐刷刷卡在 getConnection——连接池被占满了。根子是连接数太小、慢 SQL 长占连接、连接泄漏。几天梳理 HikariCP:连接池参数、连接泄漏检测、事务范围、连接保活、连接池监控。- 2
- 0
-
TIME_WAIT 堆到四万:一次 HTTP 客户端连接池踩坑的复盘
一个对外调用频繁的聚合服务,调第三方 API 平时几十毫秒,高峰却飙到一两秒,机器上 TIME_WAIT 堆了四万多个、端口几乎耗尽。根子是 HTTP 客户端用得太随意:每次请求 new 一个 client,连接用完就扔。几天梳理 HTTP 客户端:连接池配置、连接泄漏、三个超时、连接保活、客户端监控。- 0
- 0
连接池
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×