Senior · Memory and runtime
GC budgets under load
Why can a service with little live data still spend substantial CPU in GC?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
Allocation rate drives how quickly another collection is needed; the collector must scan reachable objects, not just count the final heap size. Short-lived allocations can create significant work even with a modest live heap.
GOGC trades collection frequency against heap growth. GOMEMLIMIT is a soft runtime memory limit, not a hard cap on total process or container RSS; non-Go memory and runtime overhead still matter.
Measure allocation profiles, live heap, GC CPU and tail latency under a representative request rate. Reduce needless allocation or pointer-rich retention before tuning, and leave headroom below the container limit.
Common trap
Setting GOMEMLIMIT equal to the container cap leaves no budget for other process memory.
Try it
After reducing the memory limit, CPU increases and p99 worsens. Explain the feedback loop.
Worked solution
A tighter heap budget can trigger more GC work, leaving less CPU to finish requests; queued requests retain more memory. Bound admission, inspect GC metrics and retune with headroom rather than only increasing goroutines.
Change the constraint
Which profile distinguishes allocation churn from a long-lived retention leak?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.