Geschiedenis Voor Go 1.19 bood de runtime alleen GOGC aan om garbage collection te controleren, wat de heap-triggers schaalt in verhouding tot het actieve geheugen. Dit bleek onvoldoende voor containerized deployments waar cgroups absolute geheugenlimieten opleggen. Ontwikkelaars kregen te maken met OOM kills omdat de runtime geen concept van een plafond had.
Probleem Wanneer een Go-proces draait binnen een container met een harde geheugenlimiet (bijv. 512 MiB via Docker of Kubernetes), staat de standaard GOGC=100 de heap toe om te verdubbelen voordat GC wordt geactiveerd. Zonder bewustzijn van de containergrens, alloceert de runtime totdat de kernel de OOM-killer oproept, wat het proces laat crashen in plaats van overleving te prioriteren.
Oplossing Go 1.19 introduceerde GOMEMLIMIT, een zachte geheugenlimiet die door de runtime wordt afgedwongen. In tegenstelling tot een harde limiet, stopt het geen allocaties, maar wijzigt het de snelheid van GC. Wanneer de heapgrootte (inclusief stacks, globale data en runtime overhead) de limiet nadert, berekent de runtime een nieuw punt voor GC-triggering dat agressiever is dan GOGC zou suggereren. Het gebruikt de formule: als de volgende GC-cyclus de limiet zou overschrijden, trigger dan onmiddellijk. Dit kan GC-cycli tot 100% CPU aandrijven indien nodig, waarbij doorvoer wordt ingewisseld voor stabiliteit.
import "runtime/debug" // Stel zachte limiet in op 400 MiB // Waarde is in bytes; 0 schakelt de limiet uit debug.SetMemoryLimit(400 << 20) // Alternatief via omgevingsvariabele GOMEMLIMIT=400MiB
De Crisis Onze dataverwerkingspipeline consumeerde grote CSV-bestanden, waardoor het geheugen tijdens het parseren tot 600 MiB steeg. Uitgevoerd op Kubernetes met een limiet van 512 MiB, stierven de pods met status OOMKilled elk uur. De standaard GOGC hield de heapverhouding te hoog voor de beperkte omgeving.
Oplossing 1: Agressieve GOGC-afstemming We overwoogen om GOGC=20 in te stellen om eerdere verzamelingen af te dwingen. Dit verlaagde het piekgeheugen tot ongeveer 480 MiB. Echter, het CPU-gebruik steeg constant van 10% naar 40%, zelfs tijdens inactieve periodes wanneer de geheugenlast laag was. Het verspilde middelen en degradede onnodig de latentie.
Oplossing 2: Handmatig GC-triggeren We implementeerden een geheugenwaakhond die runtime.GC() aanriep telkens wanneer runtime.ReadMemStats() hoge allocaties meldde. Dit was fragiel; het vereiste polling-overhead en maakte vaak te laat een melding tijdens plotselinge pieken, of te vroeg waardoor thrashing ontstond. Het negeerde ook de genuanceerde pacing die de runtime zou kunnen bieden.
Oplossing 3: GOMEMLIMIT-integratie We stelden GOMEMLIMIT=400MiB in (met ruimte voor stack-pieken) via het deploymentsmanifest. De runtime beperkte automatisch de frequentie van GC naar boven naarmate het geheugen groeide. Tijdens inactiviteit bleef GC zelden voorkomen; tijdens CSV-parsing draaide de collectie bijna continu maar hield het geheugen op 400 MiB. We accepteerden de CPU-wissel alleen onder druk.
Beslissing en resultaat We kozen voor Oplossing 3 omdat het het containercontract respecteerde zonder handmatige instrumentatie. De service stabiliseerde: nul OOM-kills in 30 dagen. Het CPU-gebruik voor GC gemiddeld 8% (tegenover 40% met statische GOGC) en spikte naar 25% alleen tijdens zware parsing, wat acceptabel was voor de gewonnen betrouwbaarheid.
Hoe houdt GOMEMLIMIT rekening met het geheugen van goroutine-stacks in zijn berekeningen?
Velen nemen aan dat GOMEMLIMIT alleen heapobjecten bijhoudt. In werkelijkheid omvat de limiet al het geheugen dat door de Go-runtime is gemapt: de heap, goroutine-stacks, runtime-metadata en CGO-allocaties. De runtime werkt periodiek zijn schatting van geheugen in gebruik bij via de sys-meter. Als duizenden goroutines tegelijkertijd hun stacks laten groeien, telt dit mee voor de limiet en kan GC activeren, zelfs als de heap klein is. Kandidaten missen vaak dat dit een "totaal geheugen"-limiet is, niet alleen voor de heap.
Wat gebeurt er met de latentie van allocaties wanneer de actieve heap permanent de GOMEMLIMIT overschrijdt?
Kandidaten geloven vaak dat GOMEMLIMIT fungeert als een harde plafond die allocatie blokkeert. Het is in feite een zacht doel. Als de actieve heap na een GC-cyclus al groter is dan de limiet (bijv. het laden van een enorme onvermijdelijke dataset), stelt de runtime het volgende GC-triggerpunt gelijk aan de huidige heapgrootte, waardoor GC bij elke allocatie draait. Dit "GC-thrashing" prioriteert levensduur boven doorvoer. Het programma vertraagt dramatisch, maar panikeert of crasht niet door de limiet zelf; het kan nog steeds OOM raken als de LIMIET van het OS wordt bereikt, maar GOMEMLIMIT probeert dit te voorkomen door de reclamemoeite te maximaliseren.
Waarom kan GOMEMLIMIT prestatieverlies veroorzaken, zelfs wanneer het geheugengebruik goed onder de limiet lijkt te blijven?
Dit heeft te maken met de scavenger en pacing heuristieken. Wanneer dicht bij de limiet, voert de runtime niet alleen vaker GC uit, maar geeft ook fysiek geheugen agressiever terug aan het OS via MADV_DONTNEED. Als de toepassing een zaagtand patroon voor allocaties heeft (piek dan inactief), kan de scavenger pagina's vrijgeven, alleen om de volgende piek hen terug te laten ophalen. Deze "pagina-foutstorm" verschijnt als latentiepieken. Kandidaten missen dat GOMEMLIMIT samenwerkt met GOGC via een minimale trigger-berekening: de limiet stelt effectief een vloer in voor de frequentie van GC, wat GOGC kan overschrijven, zelfs wanneer het geheugen veilig lijkt als de runtime voorspelt dat de groei de limiet zal overschrijden.