标签频道
Keepalive
该标签下的文章、提问与讨论帖。
现象或背景 在 Kubernetes 集群中，我们曾遇到一个典型场景：使用 HikariCP 5.1.0 + MySQL 8.0.35 时，QPS 稳定 600，P50 8ms，但每天稳定出现 20~50 次「拿到连接后卡满 30s 才抛异
一、现象或背景 一条读多写少的商品详情服务（Java 17 + Spring Boot 3.1 + HikariCP 5.1.0，后端 MySQL 8.0.35，中间隔了一层云 RDS Proxy / SLB），QPS 稳定 600，P50
先给结论 1. 你的「静默死亡窗口」有一个可计算的精确上界：对活跃连接 = "max(app_timeout, keepalive_time + keepalive_intvl × keepalive_probes)"；对空闲池连接 = "
«结论先行：「偶发、低比例、难复现」的 gRPC 超时 / 503，十有八九不是网络抖动，而是 HTTP/2 连接复用与服务端主动断连（GOAWAY）之间的时间差。客户端复用一条「它以为是活的」长连接发出请求，而服务端刚好在这条连接上发了
背景 8 年网络工程，现负责一批跨机房调用链（HTTP/1.1 + gRPC over HTTP/2），单侧新建连接速率峰值约 800 conn/s，存量长连接 2 万上下，内核 5.15。过去 12 个月我复盘过 4 次链路故障类事故，其
连接池全绿却偶发卡 30s：keepalive 与中间件 idle timeout 错配导致的「连接假死」治理 一、现象与背景 一条读多写少的商品详情服务（Java 17 + Spring Boot 3.1 + HikariCP 5.1.0
【背景】 做了 15 年网络工程，keepalive 是我见过「默认值最危险、讨论最少」的参数之一。Linux 默认 "net.ipv4.tcp_keepalive_time=7200"（2 小时）、"tcp_keepalive_intvl
«结论先行：凌晨连接池「假死」，90% 不是 MySQL 的问题，不是 HikariCP 的问题，而是 TCP Keepalive 默认 7200s 的探测周期远远慢于中间 NAT / 负载均衡器的 300s idle timeout——N
背景 15 年网络工程，现在保一批跨机房长连接池（gRPC over HTTP/2 + 一批 HTTP/1.1），单侧连接数 2 万上下。最头疼的一类故障不是"链路断了"，而是对端节点静默死亡（断电、内核 panic、网络分区、交换机黑洞）
«结论先行：凌晨低峰后第一波请求的 P99 尖刺，十有八九不是 GC、不是连接池打满、不是慢查询，而是 TCP keepalive 默认 7200s 远慢于云 LB / NAT 网关的 idle 超时（常见 900s）——中间设备静默把池里
【背景】 我负责一条双活数据中心的 eBGP 出口（本地 AS65000，对端运营商 AS4134），核心交换机是 Cisco N9K（IOS-XR 对端），业务侧是长连接 gRPC，对丢包敏感。最近一次 10G 上联抖动 12 分钟、BG
«结论先行：「偶发、低比例、难复现」的 gRPC 超时 / 503，十有八九不是网络抖动，而是 HTTP/2 连接复用与服务端主动断连（GOAWAY）之间的时间差。客户端复用一条「它以为是活的」长连接发出请求，而服务端刚好在这条连接上发了
TCP keepalive 默认要等 2 小时才发第一个探测包：一次内网"僵尸连接"打满连接池的排查 一、现象：P99 间歇性飙到 30s，但所有资源指标都"正常" 2024 年 11 月，我们一个支付网关服务（Java 17 + Hika
«结论先行：Linux 默认的 "tcp_keepalive_time=1800 / intvl=75 / probes=9"，最坏判定死亡要 1800 + 9×75 = 2475 秒 ≈ 41 分钟。在 NAT 空闲超时 300 秒、LB
文
标题
摘要