Go 服务被 OOMKilled，别先怪 GC

Fri, 22 May 2026 00:01:00 +0800

服务又被 OOMKilled 了。

Pod 刚重启，群里已经有人开始翻 GC 日志。有人说 GC CPU 到了 20%，有人说把 GOGC 调低一点，还有人建议直接上 GOMEMLIMIT。

这些动作不一定错，但顺序错了。

OOMKilled 是结果，不是根因。它只说明容器被内核杀掉了，不说明是谁把内存吃掉了。可能是 Go heap 真的在涨，可能是 goroutine 泄漏把栈和引用一起拖大，可能是 alloc_space 很高导致 GC 忙，可能是 RSS 里有 cgo、mmap、tmpfs，也可能只是容器 limit 给得太紧。

Go 服务的内存问题，最怕一句话定性。

一旦你把所有问题都叫“GC 问题”，排查就会变成调参赌博：今天调 GOGC，明天加 limit，后天又开始怀疑 pprof 没抓准。真正稳定的做法，是先把几条线拆开：Go 堆、Go runtime 管理的内存、RSS、容器 limit，以及业务生命周期。

第一步不是调参数，是确认谁杀了你

线上看到内存上涨，第一件事不是打开 pprof，也不是改 GOGC。

先确认事故事实。

1
2
3
4
5


kubectl describe pod <pod> -n <ns>
kubectl logs <pod> -n <ns> --previous
kubectl top pod <pod> -n <ns> --containers
kubectl get pod <pod> -n <ns> \
 -o jsonpath='{.status.containerStatuses[*].lastState.terminated.reason}'

你要先回答几个问题：

Go GC 占 CPU 5%，到底要不要调 GOGC？

Thu, 21 May 2026 23:30:00 +0800

服务 p99 每隔几十秒抖一下。

监控里 GC CPU 大概 5%，不算夸张，但曲线很准：GC 一来，延迟就往上冒。群里很快有人提议：把 GOGC 从 100 调到 200，先让 GC 少跑几次。

这个动作看起来很合理。

CPU 下来了，GC 日志没那么密了，p99 也安静了几天。然后另一个问题来了：容器内存开始逼近 limit，某个高峰期被 OOMKilled。大家又把 GOGC 调回去，延迟抖动也跟着回来。

这就是很多 Go GC 调优的真实状态：不是不会调参数，而是没想清楚自己到底在买什么。

GOGC 调的是账期，不是魔法。

调高它，相当于允许堆多长一段时间，用内存换 CPU；调低它，相当于让 GC 更勤快，用 CPU 换内存。至于 GOMEMLIMIT，它不是另一个版本的 GOGC，而是在告诉 runtime：这个进程由 Go 管的内存，最好别越过这条线。

所以这篇不打算把 GC 参数逐个解释一遍。线上真正需要的是一条决策路径：要不要调，调什么，调多少，什么时候停手。

先别问 GOGC 设多少，先问谁在付账

Go 官方 GC Guide 给过一个很关键的公式：

1

Target heap memory = Live heap + (Live heap + GC roots) × GOGC / 100

这句话不用背，抓住意思就行。

GOMEMLIMIT on Zampo Blog

Go 服务被 OOMKilled，别先怪 GC

第一步不是调参数，是确认谁杀了你

Go GC 占 CPU 5%，到底要不要调 GOGC？

先别问 GOGC 设多少，先问谁在付账