-
内存慢性漏气定期 OOM:Go 协程泄漏避坑复盘
这是一个让我和运维被半夜告警折磨了快一周的事故:一个 Go 写的后端服务上线后一切正常,可跑上两三天内存就会悄悄爬到上限,然后被 OOM 杀掉自动重启,重启后归零又开始新一轮缓慢爬升,周而复始。它不是一上线就崩的急性病,而是跑着跑着就虚了的慢性病,每隔两三天准时 OOM 一次,最折磨人的是 QPS 没涨流量很平稳,内存却像漏气的轮胎只进不出。真正破案靠的是 Go 自带的神器 pprof:把 gor…- 0
- 0
-
Go time.After 在 for-select 循环里每秒 5 万次的内存泄漏 3 天复盘:18 小时准时 OOM + ticker / NewTimer.Reset / Go 1.23 三套正解
event-fanout 服务跑 18 小时稳定 OOM,goroutine 不泄漏 channel 不堆积,heap profile 显示 time.NewTimer 占 63% 分配。根因是 for-select 里 time.After(30s) 每秒触发 5 万次,稳态留 150 万个未到期 timer。本文讲清 time.After 的 runtime 行为、3 种修法、Go 1.23 …- 3
- 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
-
Go GC STW 在 180GB 堆下飙到 800ms 导致风控漏判的复盘:5 种修法从指针消灭到 mmap
一次例行数据更新让 Go 风控引擎的堆从 120GB 涨到 180GB,GC Mark Termination STW 从 1ms 飙到 800ms,刚好命中上游 500ms 超时,触发 4 小时漏判 230 笔潜在欺诈交易、估损 80 万。这篇完整复盘事故时间线、Go 三色标记 GC 真正的 STW 暴涨原因、GOGC/GOMEMLIMIT/消灭指针/mmap off-heap/服务拆分五种修法…- 3
- 0
-
Go goroutine 泄漏的 5 个真实场景:11 万协程 OOM 复盘 + 检测方案
一个 Go 微服务每天涨 200MB,heap profile 一切正常,goroutine profile 却显示 11 万个活跃协程,绝大多数卡在 chan receive 上等一个永远不会写入的 channel。本文整理了生产中最常见的 5 种 goroutine 泄漏场景,每种给出最小复现 + 修法,并给出 pprof + goleak 的 CI 检测方案。- 0
- 0
-
Go goroutine 泄漏:跑了 47 天 OOMKilled 后我们找到的 5 个真实场景
Go 服务跑了 47 天内存涨到 6.2GB,OOMKilled。本文复盘 goroutine 泄漏的 5 个真实场景:channel 写没人读、for-select 缺退出分支、HTTP body 没读完、time.After 滥用、WaitGroup 卡死。每个场景附最小复现 + 修法 + pprof 排查命令。- 0
- 0
pprof
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×