Go-geheugenprofilering bij verkeerspieken: een pprof-stapsgewijze handleiding

Wat plotselinge verkeerspieken met het geheugen van een Go-service doen

Een “geheugenpiek” in productie betekent zelden dat één eenvoudig getal omhoog ging. Je kunt zien dat RSS (procesgeheugen) snel stijgt terwijl de Go-heap nauwelijks beweegt, of dat de heap groeit en scherp daalt in golven wanneer de GC draait. Tegelijkertijd wordt latency vaak erger omdat de runtime meer tijd besteedt aan opruimen.

Veelvoorkomende patronen in metrics:

• RSS stijgt sneller dan verwacht en daalt soms niet volledig na de piek
• Heap in-use stijgt, en valt dan in scherpe cycli wanneer GC vaker draait
• Allocatiesnelheid springt omhoog (bytes allocated per second)
• GC-pauzetijd en GC-CPU-tijd nemen toe, zelfs als elke pauze klein is
• Request-latency stijgt en tail-latency wordt lawaaierig

Verkeerspieken vergroten per-request allocaties omdat “kleine” verspilling lineair schaalt met load. Als één request 50 KB extra alloceert (tijdelijke JSON-buffers, per-rij scan-objecten, middleware-contextdata), dan voed je bij 2.000 requests per seconde de allocator met ongeveer 100 MB per seconde. Go kan veel aan, maar de GC moet die kortlevende objecten toch traceren en vrijgeven. Als allocatie sneller gaat dan cleanup, groeit de heap-target, volgt RSS en kun je geheugenlimieten raken.

De symptomen zijn bekend: OOM-kills door je orchestrator, plotselinge latency-stijgingen, meer tijd in GC en een service die er “druk” uitziet zelfs als de CPU niet vastloopt. Je kunt ook GC-thrash krijgen: de service blijft draaien maar blijft zoveel alloceren en verzamelen dat throughput daalt op het moment dat je het het meest nodig hebt.

pprof helpt één vraag snel te beantwoorden: welke codepaden alloceren het meest, en zijn die allocaties noodzakelijk? Een heap-profiel toont wat nu vastgehouden wordt. Allocatie-georiënteerde views (zoals alloc_space) tonen wat er veel gecreëerd en weggegooid wordt.

Wat pprof niet doet, is elk byte van RSS verklaren. RSS bevat meer dan de Go-heap (stacks, runtime-metadata, OS-mappings, cgo-allocaties, fragmentatie). pprof is het meest geschikt om allocatie-hotspots in je Go-code aan te wijzen, niet om een exact containerniveau-geheugentotaal te bewijzen.

pprof veilig opzetten (stap voor stap)

pprof is het makkelijkst te gebruiken als HTTP-endpoints, maar die endpoints kunnen veel over je service onthullen. Behandel ze als een admin-feature, niet als een publieke API.

1) Voeg pprof-endpoints toe

In Go is de eenvoudigste setup pprof op een aparte admin-server te draaien. Dat houdt profiling-routes weg van je hoofdrouter en middleware.

package main

import (
	"log"
	"net/http"
	_ "net/http/pprof"
)

func main() {
	go func() {
		// Admin only: bind to localhost
		log.Println(http.ListenAndServe("127.0.0.1:6060", nil))
	}()

	// Your main server starts here...
	// http.ListenAndServe(":8080", appHandler)
	select {}
}

Als je geen tweede poort kunt openen, kun je pprof-routes in je hoofdserver monteren, maar het is makkelijker om ze per ongeluk bloot te stellen. Een aparte admin-poort is de veiligere standaard.

2) Beveilig het voordat je het uitrolt

Begin met controles die moeilijk fout te doen zijn. Binden aan localhost betekent dat de endpoints niet vanaf internet bereikbaar zijn tenzij iemand die poort ook blootstelt.

Een korte checklist:

• Draai pprof op een admin-poort, niet op de hoofdgebruikerspoort
• Bind aan 127.0.0.1 (of een private interface) in productie
• Voeg een allowlist toe aan de netwerkrand (VPN, bastion of intern subnet)
• Vereis authenticatie als je edge dit kan afdwingen (basic auth of token)
• Verifieer dat je de profielen kunt ophalen die je nodig hebt: heap, allocs, goroutine

3) Bouw en rol voorzichtig uit

Houd de wijziging klein: voeg pprof toe, ship het en bevestig dat het alleen bereikbaar is vanaf waar je het verwacht. Als je staging hebt, test daar eerst door wat load te simuleren en een heap- en allocs-profiel vast te leggen.

Voor productie: rol geleidelijk uit (één instantie of een klein deel van de traffic). Als pprof verkeerd is geconfigureerd, blijft de blast radius klein terwijl je het oplost.

De juiste profielen vastleggen tijdens een piek

Tijdens een piek is één snapshot zelden genoeg. Leg een korte tijdlijn vast: een paar minuten vóór de piek (baseline), tijdens de piek (impact) en een paar minuten erna (recovery). Dat maakt het makkelijker om echte allocatieveranderingen te scheiden van normale warm-up.

Als je de piek kunt reproduceren met gecontroleerde load, match productie zo goed mogelijk: requestmix, payloadgroottes en concurrency. Een piek van kleine requests gedraagt zich heel anders dan een piek van grote JSON-responses.

Neem zowel een heap-profiel als een allocatiegericht profiel. Ze beantwoorden verschillende vragen:

• Heap (inuse) toont wat nu leeft en geheugen vasthoudt
• Allocaties (alloc_space of alloc_objects) tonen wat zwaar wordt aangemaakt, zelfs als het snel wordt vrijgegeven

Een praktisch capturepatroon: pak één heap-profiel, daarna een allocatieprofiel, en herhaal 30–60 seconden later. Twee punten tijdens de piek helpen je te zien of een verdachte pad stabiel is of accelereert.

# examples: adjust host/port and timing to your setup
curl -o heap_during.pprof "http://127.0.0.1:6060/debug/pprof/heap"
curl -o allocs_30s.pprof "http://127.0.0.1:6060/debug/pprof/allocs?seconds=30"

Naast pprof-bestanden, noteer een paar runtime-statistieken zodat je kunt verklaren wat de GC op dat moment deed. Heapgrootte, aantal GCs en pauzetijd zijn meestal genoeg. Zelfs een korte logregel bij elk capturemoment helpt correlatie te leggen tussen “allocaties stegen” en “GC begon constant te draaien”.

Houd incidentnotities bij: buildversie (commit/tag), Go-versie, belangrijke flags, configuratiewijzigingen en welke traffic er was (endpoints, tenants, payloadgroottes). Die details blijken vaak belangrijk wanneer je profielen vergelijkt en ontdekt dat de requestmix verschoof.

Hoe je heap- en allocatieprofielen leest

Een heap-profiel beantwoordt verschillende vragen afhankelijk van de view.

Inuse space toont wat op het moment van capture nog in geheugen vastzit. Gebruik dit voor leaks, langlevende caches of requests die objecten achterlaten.

Alloc space (totale allocaties) toont wat in de tijd is aangemaakt, zelfs als het snel is vrijgegeven. Gebruik dit wanneer pieken veel GC-werk, latency-stijgingen of OOMs door churn veroorzaken.

Sampling doet ertoe. Go registreert niet elke allocatie. Het samplet allocaties (gereguleerd door runtime.MemProfileRate), dus kleine, frequente allocaties kunnen ondervertegenwoordigd zijn en getallen zijn schattingen. De grootste schuldigen springen nog steeds uit, vooral onder piekcondities. Kijk naar trends en top-bijdragers, niet perfecte boekhouding.

De meest bruikbare pprof-views:

• top: snelle kijk wie domineert inuse of alloc (controleer zowel flat als cumulative)
• list : regel-niveau allocatiebronnen binnen een hete functie
• graph: call paths die verklaren hoe je daar kwam

Diffs zijn waar het praktisch wordt. Vergelijk een baseline-profiel (normale traffic) met een piekprofiel om te benadrukken wat veranderde, in plaats van achtergrondruis na te jagen.

Valideer bevindingen met een kleine wijziging voordat je aan een grote refactor begint:

• Hergebruik een buffer (of voeg een kleine sync.Pool toe) in het hete pad
• Verminder per-request objectcreatie (bijv. vermijd het bouwen van tussenliggende maps voor JSON)
• Re-profileer onder dezelfde load en bevestig dat de diff krimpt waar je verwacht

Als de cijfers de goede kant op gaan, heb je een echte oorzaak gevonden, niet alleen een angstaanjagend rapport.

Allocatie-hotspots in JSON-encoding vinden

Tijdens pieken kan JSON-werk een belangrijke geheugenpost worden omdat het bij elk request draait. JSON-hotspots verschijnen vaak als veel kleine allocaties die de GC extra belasten.

Rode vlaggen in pprof

Als de heap- of allocatieview encoding/json aanwijst, kijk goed naar wat je erin stopt. Deze patronen vergroten allocaties vaak:

• map[string]any (of []any) gebruiken voor responses in plaats van getypeerde structs
• Hetzelfde object meerdere keren marshalen (bijv. voor logging en ook retourneren)
• Pretty printing met json.MarshalIndent in productie
• JSON opbouwen via tijdelijke strings (fmt.Sprintf, string-concatenatie) vóór marshaling
• Grote []byte naar string converteren (of terug) alleen om aan een API te voldoen

json.Marshal alloceert altijd een nieuwe []byte voor de volledige output. json.NewEncoder(w).Encode(v) vermijdt meestal die ene grote buffer omdat het naar een io.Writer schrijft, maar kan nog steeds intern alloceren, vooral als v vol zit met any, maps of pointer-rijke structuren.

Snelle fixes en experimenten

Begin met getypeerde structs voor je response-structuur. Ze verminderen reflectiewerk en vermijden per-veld interface-boxing.

Verwijder dan vermijdbare per-request temporaries: hergebruik bytes.Buffer via een sync.Pool (zorgvuldig), noem geen indent in productie en marshal niet opnieuw alleen voor logs.

Kleine experimenten om te bevestigen dat JSON de boosdoener is:

• Vervang map[string]any door een struct voor één heet endpoint en vergelijk profielen
• Schakel van Marshal naar Encoder die direct naar de response schrijft
• Verwijder MarshalIndent of debug-only formatting en re-profileer onder dezelfde load
• Sla JSON-encoding over voor ongewijzigde gecachte responses en meet de daling

Allocatie-hotspots bij query-scanning vinden

Wanneer geheugen tijdens een piek omhoog schiet, zijn database-reads een veelvoorkomende verrassing. Het is makkelijk om je op SQL-tijd te richten, maar de scanstap kan per rij veel alloceren, vooral als je in flexibele types scant.

Veelvoorkomende daders:

• Scannen in interface{} (of map[string]any) en de driver typen laten kiezen
• []byte naar string converteren voor elk veld
• Nullable wrappers (sql.NullString, sql.NullInt64) gebruiken in grote resultsets
• Grote tekst-/blobkolommen ophalen die je niet altijd nodig hebt

Een patroon dat stilletjes geheugen verbrandt, is rijdatabuffer scannen in tijdelijke variabelen en die dan kopiëren naar een echte struct (of per rij een map bouwen). Als je rechtstreeks in een struct met concrete velden kunt scannen, vermijd je extra allocaties en typechecks.

Batchgrootte en paginering veranderen je geheugenpatroon. 10.000 rijen in één slice ophalen alloceert voor slice-groei en elke rij, alles tegelijk. Als de handler alleen een pagina nodig heeft, push dat naar de query en houd de paginaformaat stabiel. Als je veel rijen moet verwerken, stream ze en aggregeer kleine samenvattingen in plaats van elke rij op te slaan.

Grote tekstvelden vragen speciale zorg. Veel drivers geven tekst als []byte. Dat naar string converteren kopieert de data, dus dat voor elke rij doen kan allocaties explosief laten groeien. Als je de waarde soms alleen nodig hebt, vertraag de conversie of scan minder kolommen voor dat endpoint.

Om te bevestigen of de driver of jouw code het meeste alloceert, kijk wat dominant is in je profielen:

• Als frames naar je mapping-code wijzen, focus dan op scan-doelen en conversies
• Als frames naar database/sql of de driver wijzen, beperk eerst rijen en kolommen en overweeg driver-specifieke opties
• Controleer zowel alloc_space als alloc_objects; veel kleine allocaties kunnen erger zijn dan een paar grote

Voorbeeld: een "list orders" endpoint scant SELECT * in []map[string]any. Tijdens een piek bouwt elk request duizenden kleine maps en strings. De query veranderen naar alleen benodigde kolommen en scannen in []Order{ID int64, Status string, TotalCents int64} reduceert vaak allocaties direct. Hetzelfde idee geldt als je een gegenereerde Go-backend van AppMaster profileert: de hotspot zit meestal in hoe je resultaatdata vormgeeft en scant, niet de database zelf.

Middleware-patronen die stilletjes per request alloceren

Middleware voelt goedkoop omdat het “maar een wrapper” is, maar het draait bij elk request. Tijdens een piek tellen kleine per-request allocaties snel op en verschijnen ze als een stijgende allocatiesnelheid.

Logging-middleware is een veelvoorkomende bron: strings formatteren, maps van velden bouwen of headers kopiëren voor nettere output. Request-ID helpers kunnen alloceren wanneer ze een ID genereren, die naar string converteren en dan in de context zetten. Zelfs context.WithValue kan alloceren als je nieuwe objecten (of nieuwe strings) bij elk request opslaat.

Compressie en body-handling zijn een andere frequente boosdoener. Als middleware de volledige request-body leest om te "peeken" of valideren, kun je per request een grote buffer krijgen. Gzip-middleware kan veel alloceren als er per keer nieuwe readers en writers gemaakt worden in plaats van buffers te hergebruiken.

Auth- en session-lagen kunnen vergelijkbaar zijn. Als elk request tokens parseert, cookies base64-decodeert of session-blobs in verse structs laadt, krijg je constante churn zelfs als handler-werk licht is.

Tracing en metrics kunnen meer alloceren dan verwacht wanneer labels dynamisch worden opgebouwd. Route-namen, user-agents of tenant-IDs in nieuwe strings per request samenvoegen is een klassieke verborgen kost.

Patronen die vaak als “death by a thousand cuts” naar voren komen:

• Logregels bouwen met fmt.Sprintf en nieuwe map[string]any waarden per request
• Headers kopiëren naar nieuwe maps of slices voor logging of signing
• Nieuwe gzip-buffers en readers/writers maken in plaats van poolen
• Metrics met hoge cardinaliteit labels (veel unieke strings)
• Nieuwe structs in context stoppen bij elk request

Om middleware-kosten te isoleren, vergelijk twee profielen: één met de volledige keten ingeschakeld en één met middleware tijdelijk uitgeschakeld of vervangen door een no-op. Een simpele test is een health-endpoint dat bijna geen allocaties zou moeten doen. Als /health veel alloceert tijdens een piek, is de handler niet het probleem.

Als je Go-backends genereert met AppMaster geldt dezelfde regel: houd cross-cutting features (logging, auth, tracing) meetbaar en behandel per-request allocaties als een budget dat je kunt auditen.

Oplossingen die meestal snel renderen

Zodra je heap- en allocs-views uit pprof hebt, prioriteer veranderingen die per-request allocaties verminderen. Het doel is geen slimme trucjes, maar het hete pad minder kortelevende objecten laten maken, vooral onder load.

Begin met de veilige, saaie winst

Als groottes voorspelbaar zijn, prealloceer. Als een endpoint meestal rond de 200 items terugstuurt, maak je slice met capaciteit 200 zodat het niet meerdere keren groeit en kopieert.

Vermijd het bouwen van strings in hete paden. fmt.Sprintf is handig, maar alloceert vaak. Voor logging: geef de voorkeur aan gestructureerde velden en hergebruik een kleine buffer waar zinvol.

Als je grote JSON-responses genereert, overweeg ze te streamen in plaats van één enorme []byte of string in geheugen te bouwen. Een veelvoorkomend piekpatroon is: request komt binnen, je leest een groot body, bouwt een grote response, geheugen schiet omhoog totdat GC bijhoudt.

Snelle wijzigingen die doorgaans duidelijk zichtbaar zijn in before/after profielen:

• Slices en maps vooraf reserveren als je de omvang ongeveer weet
• fmt-zware formatting vervangen in requesthandling door goedkopere alternatieven
• Grote JSON-responses streamen (encodeer direct naar response writer)
• sync.Pool gebruiken voor herbruikbare, gelijkvormige objecten (buffers, encoders) en ze consistent terugzetten
• Request-limieten instellen (bodygrootte, payloadgrootte, page size) om worst cases te begrenzen

Gebruik sync.Pool voorzichtig

sync.Pool helpt wanneer je herhaaldelijk hetzelfde ding alloceert, zoals een bytes.Buffer per request. Het kan ook schaden als je objecten poolt met onvoorspelbare groottes of vergeet ze te resetten, wat grote backing-arrays in leven houdt.

Meet voor en na met dezelfde workload:

• Pak een allocs-profiel tijdens het piekmoment
• Pas één wijziging per keer toe
• Draai dezelfde requestmix opnieuw en vergelijk total allocs/op
• Let op tail-latency, niet alleen geheugen

Als je Go-backends genereert met AppMaster, gelden deze fixes ook voor custom code rond handlers, integraties en middleware. Daar verbergen spike-gedreven allocaties zich meestal.

Veelgemaakte pprof-fouten en valse alarmen

De snelste manier om een dag te verspillen is het optimaliseren van het verkeerde. Als de service traag is, begin met CPU. Als die wordt gekilled door OOM, begin met heap. Als hij het overleeft maar GC constant draait, kijk naar allocatiesnelheid en GC-gedrag.

Een andere valkuil is naar "top" staren en het daarmee afdoen. "Top" verbergt context. Inspecteer altijd call stacks (of een flame graph) om te zien wie de allocator aanriep. De fix zit vaak één of twee frames boven de hete functie.

Let ook op de verwarring tussen inuse en churn. Een request kan 5 MB aan kortlevende objecten alloceren, extra GC triggeren en eindigen met slechts 200 KB inuse. Als je alleen naar inuse kijkt, mis je churn. Als je alleen naar totale allocaties kijkt, optimaliseer je misschien iets dat nooit resident blijft en geen OOM-risico vormt.

Snelle sanity checks vóór je code verandert:

• Bevestig dat je in de juiste view zit: heap inuse voor retentie, alloc_space/alloc_objects voor churn
• Vergelijk stacks, niet alleen functienamen (encoding/json is vaak een symptoom)
• Reproduceer traffic realistisch: dezelfde endpoints, payloadgroottes, headers, concurrency
• Leg een baseline en een piekprofiel vast en diff ze

Onrealistische loadtests veroorzaken valse alarmen. Als je test kleine JSON-bodies stuurt maar productie 200 KB payloads stuurt, optimaliseer je het verkeerde pad. Als je test één database-rij retourneert, zie je nooit het scan-gedrag dat bij 500 rijen optreedt.

Jacht niet op ruis. Als een functie alleen in het piekprofiel verschijnt (niet in baseline), is dat een sterke aanwijzing. Als het in beide op hetzelfde niveau verschijnt, kan het normaal achtergrondwerk zijn.

Een realistische incident-walkthrough

Op maandagochtend gaat er een promotie uit en je Go-API krijgt 8x normale traffic. Het eerste symptoom is geen crash. RSS klimt, GC wordt drukker en p95-latency stijgt. Het heetste endpoint is GET /api/orders omdat de mobiele app het bij elk scherm refresh't.

Je neemt twee snapshots: één uit een rustige periode (baseline) en één tijdens de piek. Neem hetzelfde type heap-profiel beide keren zodat de vergelijking eerlijk blijft.

De flow die in het moment werkt:

• Neem een baseline heap-profiel en noteer huidige RPS, RSS en p95-latency
• Tijdens de piek: neem nog een heap-profiel plus een allocatieprofiel binnen hetzelfde 1–2 minuut venster
• Vergelijk de top-allocators tussen de twee en focus op wat het meest groeide
• Loop van de grootste functie naar zijn callers tot je je handlerpad bereikt
• Maak één kleine wijziging, deploy naar één instantie en profileer opnieuw

In dit geval liet het piekprofiel zien dat de meeste nieuwe allocaties van JSON-encoding kwamen. De handler bouwde rijen als map[string]any en riep json.Marshal op een slice van maps aan. Elk request creëerde veel kortlevende strings en interface-waarden.

De kleinste veilige fix was stoppen met maps bouwen. Scan database-rijen rechtstreeks in een getypeerde struct en encodeer die slice. Verder veranderde niets: dezelfde velden, dezelfde responsevorm, dezelfde statuscodes. Na het uitrollen van de wijziging naar één instantie daalden de allocaties in het JSON-pad, nam GC-tijd af en stabiliseerde de latency.

Pas daarna rol je geleidelijk verder uit terwijl je geheugen, GC en foutpercentages in de gaten houdt. Als je services bouwt op een no-code platform zoals AppMaster, is dit ook een herinnering om responsmodellen getypeerd en consistent te houden, omdat dat helpt verborgen allocatiekosten te vermijden.

Volgende stappen om de volgende geheugenspiek te voorkomen

Als je een piek hebt gestabiliseerd, maak de volgende saai. Behandel profilering als een herhaalbare oefening.

Schrijf een korte runbook die je team kan volgen als ze moe zijn. Het moet zeggen wat vastgelegd moet worden, wanneer en hoe te vergelijken met een bekende goede baseline. Houd het praktisch: exacte commando's, waar profielen heen gaan en wat “normaal” is voor je top-allocators.

Voeg lichte monitoring toe voor allocatiedruk voordat je OOM raakt: heapgrootte, GC-cycli per seconde en bytes allocated per request. Het opvangen van “allocaties per request 30% omhoog week-over-week” is vaak nuttiger dan wachten op een harde geheugenalarm.

Push checks eerder met een korte loadtest in CI op een representatief endpoint. Kleine response-wijzigingen kunnen allocaties verdubbelen als ze extra kopieën triggeren, en het is beter dat te vinden voordat productieverkeer het doet.

Als je een gegenereerde Go-backend runt, exporteer dan de bron en profileer het op dezelfde manier. Gegenereerde code is nog steeds Go-code en pprof wijst naar echte functies en regels.

Als je requirements vaak veranderen, kan AppMaster (appmaster.io) een praktische manier zijn om schone Go-backends te herbouwen en te regenereren terwijl de app evolueert, en vervolgens de geëxporteerde code onder realistische load te profileeren voordat het wordt vrijgegeven.