GOMEMLIMIT for a low-traffic Go container: choosing a value without automatic cgroup v2 detection

Short answer

For a mostly idle Go service under a 256Mi cgroup v2 limit, start with GOMEMLIMIT=192MiB (75% of the container limit). This is below the commonly cited 80–90% heuristic, but that heuristic assumes steady allocation pressure; an idle service has little live heap, so a lower soft limit shrinks RSS further while the GC still has plenty of headroom before CPU overhead becomes visible. Verify with runtime/metrics, and derive the value at startup from /sys/fs/cgroup/memory.max if you want it to track the manifest automatically.

1. Choosing the value and verifying the tradeoff

The tradeoff is simple: lowering GOMEMLIMIT makes the GC run more often, shrinking the heap (and eventually RSS, since the runtime returns memory to the OS) at the cost of GC CPU. For an idle service the live heap is small, so the GC can hold a low target with few cycles — that is exactly the case where aggressive settings are cheap.

1. Deploy with GOMEMLIMIT=192MiB.
2. Under representative (idle) load, watch /sched/gc:cpu_fraction. If it stays under roughly 5%, you have room to go lower; step down in 25MiB increments.
3. If GC CPU climbs or /gc/heap/goal:bytes is pinned at the limit while the live heap keeps pushing against it, you have gone too far — step back up.
4. If RSS barely moves and GC CPU is near zero, the limit is not binding; lower it until it is.

Remember the soft-limit caveat: a burst can temporarily exceed GOMEMLIMIT, and it does not account for CGO allocations, goroutine stacks, or other runtime metadata. Keep enough gap to the 256Mi cgroup hard limit that a spike does not trigger the OOM killer — that gap is the real reason not to set GOMEMLIMIT at 95%+.

2. Deriving it from the cgroup limit at startup

Yes, this is supported. debug.SetMemoryLimit has been available since Go 1.19, so you can read the cgroup v2 limit yourself and set the soft limit programmatically:

data, err := os.ReadFile("/sys/fs/cgroup/memory.max")
if err == nil {
    s := strings.TrimSpace(string(data))
    if s != "max" {
        if limit, err := strconv.ParseInt(s, 10, 64); err == nil {
            debug.SetMemoryLimit(limit * 3 / 4)
        }
    }
}

Handle the "max" case (no limit set) by falling back to a default or leaving the limit unset. This approach keeps the value synchronized with the manifest — a real advantage over a static env var, which can silently drift when someone edits the Deployment's memory limit. The tradeoff is that env-var configuration is more visible to operators and easier to override per environment. Either is defensible; startup derivation is the better default if your platform team resizes containers often.

3. Metrics that confirm it is working

Scrape these via runtime/metrics (or expvar/a metrics exporter) before and after the change:

• /gc/heap/goal:bytes — the GC's target heap size. After the change it should be capped near your GOMEMLIMIT rather than floating at 2× live heap (the default GOGC=100 behavior).
• /memory/classes/heap:bytes (or /memory/classes/total:bytes for the full picture including stacks and metadata) — confirms actual heap stays near the goal and total runtime memory stays comfortably under 256Mi.
• /sched/gc:cpu_fraction — the cost side of the tradeoff. This is the number that tells you whether your memory savings are being paid for in CPU.
• Container-level RSS from your monitoring (cAdvisor/kubelet) — the metric that actually maps to cost. Note that the runtime returns memory to the OS lazily, so RSS may lag the heap reduction; give it minutes, not seconds, before judging.

One missing detail that would change the recommendation: your traffic's burst profile. If "low traffic" means occasional sharp spikes rather than uniformly low load, stay closer to 80–85% (205–218MiB) and accept less RSS reduction, because the OOM risk during a burst outweighs idle savings.