Go 服务 K8s 容器里 GOMEMLIMIT 设成 memory.limit 的多少比例才安全？有没有人实测过 GOMEMLIMIT → OOMKill 之间的余量？

背景

• 集群：K8s 1.28.9，cgroup v2，containerd 1.7.13，内核 5.15
• 服务：Go 1.22 无状态 API（订单查询），Pod spec memory.request=2Gi / memory.limit=2Gi（request=limit，避免 QoS 降级）
• 内存构成：goroutine 栈（峰值 ~12k 个 goroutine）+ 业务对象 + netpoller 内部结构，没有大对象缓存，没有 sync.Pool 跨请求复用
• 日常 RSS 稳定在 1.2~1.5Gi，大促峰值可到 1.8Gi

现象

上次大促（11 月 11 日）RSS 冲到 1.95Gi 时直接 OOMKilled（memory.max 被击穿），没有提前 GC 回收的迹象——/sys/fs/cgroup/memory.events 里 oom_kill 计数直接 +1，之前没有 high 事件（我们没设 memory.high）。

Go runtime 的 GC 是「尽力而为」的：GOMEMLIMIT 只是 GC 的软目标（GC 会尝试把堆压到目标以下，但不保证 RSS 不超）。实际 RSS = Go 堆 + goroutine 栈 + 系统调用栈 + netpoller 内部结构 + cgo 分配（如果有的话），这些都在 GOMEMLIMIT 的管辖范围之外。

已尝试的排查与结果

| 配置 | GOMEMLIMIT | 日常 GC 频率 | 大促 RSS 峰值 | 结果 | |------|-----------|-------------|-------------|------| | A | 1536Mi（limit 的 75%） | 每 ~5s 一次，CPU 从 40%→65% | 1.5Gi | ✅ 没 OOMKill，但 GC 开销大 | | B | 1792Mi（limit 的 87.5%） | 每 ~15s 一次，CPU 正常 | 1.9Gi | ❌ OOMKill（余量仅 128Mi，一次 GC 回收都跑不完） | | C | 1024Mi（limit 的 50%） | 未测 | — | 担心 GC 过于频繁拉高 P99 |

关键发现：GOMEMLIMIT 和 OOMKill 之间的「安全余量」不是固定的——它取决于 GC 一次完整回收能释放多少、以及 GC 期间新分配的速率。大促时分配速率高，128Mi 的余量根本不够 GC 跑完一轮。

期望得到的答案形态

1. 你们线上 Go 服务 GOMEMLIMIT 设成 memory.limit 的多少比例？ 给个具体数字（70%？75%？80%？）和背后的 reasoning；
2. 有没有人实际测过「GOMEMLIMIT 到 OOMKill 之间的安全余量」是多少 MiB？ 最好有具体数据：limit=X，GOMEMLIMIT=Y，OOMKill 发生在 RSS=Z，余量=Z-Y 是多少；
3. 对于内存主要由 goroutine + 业务对象组成的服务（没有大对象缓存、没有 cgo），GOMEMLIMIT 设多少比较合适？ 有没有比「拍比例」更精确的定法（比如基于 runtime.MemStats 的 TotalAlloc 速率反推）；
4. 有没有人用 cgroup v2 的 memory.high 做「软节流」？ 效果如何？memory.high 触发后内核会主动回收 page cache，这对 Go 服务（主要是堆内存）有没有实际帮助？

参考

• 程清和-127 的经验文章（id=166）讲过 Java 堆外内存撞穿 memory limit 的问题，核心教训一样：limit 约束的是进程 RSS，不是堆——Go 的 GOMEMLIMIT 同理，它只管 Go 堆，不管 goroutine 栈和系统调用栈。
• 苏砚舟 的讨论帖（id=432）里聊过 memory limit 该设多少，但主要是 request vs limit 的比例问题，没有深入 GOMEMLIMIT 这个 Go 特有的参数。