Memory leaks en GC-druk in productie debuggen
Diagnosticeer geleidelijke geheugengroei, pauzes door garbage collection en out-of-memory-crashes in actieve services met heapanalyse en allocatieprofiling.
Memory leaks en GC-druk in productie debuggen is een gratis Draaiboek voor debuggen in productie en incidentrespons-les op CoddyKit. Dit is les 4 van 4. Je kunt 3 lessen uit dit leerpad gratis volledig lezen — daarna ontgrendelt CoddyKit PRO alle lessen, plus praktische oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject Draaiboek voor debuggen in productie en incidentrespons. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Draaiboek voor debuggen in productie en incidentrespons bevat in totaal 4 lessen.
Symptomen van een geheugenprobleem
Geheugenproblemen kondigen zichzelf zelden duidelijk aan. Let op deze patronen:
- RSS die langzaam stijgt en nooit daalt
- Toenemende latentie door langere GC-pauzes
- Periodieke OOM-beëindigingen en herstarts
Deze les behandelt hoe je ze in productie diagnosticeert.
Lek, overmatige omvang of churn
Maak onderscheid tussen drie fouttypen:
- Lek: het geheugen groeit onbeperkt en wordt nooit vrijgegeven
- Overmatige omvang: hoog maar stabiel gebruik door grote caches
- Churn: snelle cycli van toewijzen en vrijgeven die de GC belasten
Voor elk type is een andere oplossing nodig.
De geheugencurve lezen
Breng het geheugen in de tijd in kaart. Een lek laat een gestaag stijgende basislijn zien, zelfs na GC. Overmatige omvang geeft een hoge maar vlakke lijn. Gezonde diensten hebben een zaagtandpatroon dat na elke verzameling opnieuw begint.
leak: /\/\/\/ (baseline climbs)
healthy: /|/|/| (baseline flat)Heap-snapshots
Een heap-snapshot legt elk actief object op één moment vast. Maak twee snapshots met enkele minuten ertussen en vergelijk ze: objecten die in die tijd zijn gegroeid, zijn verdachten bij het lek.
# python
import tracemalloc
tracemalloc.start()
snap1 = tracemalloc.take_snapshot()
# ... run workload ...
snap2 = tracemalloc.take_snapshot()
for stat in snap2.compare_to(snap1, 'lineno')[:10]:
print(stat)Dominatorbomen en vasthouders
Een object blijft actief omdat iets het vasthoudt. De keten van vasthouders laat zien wie de verwijzing vasthoudt. De dominatorboom laat zien welk afzonderlijk object, als het wordt vrijgegeven, het meeste geheugen zou vrijmaken.
Volg de vasthouders om de onbedoelde verwijzing te vinden die het geheugen actief houdt.
Veelvoorkomende bronnen van lekken
De meeste lekken komen voort uit een handvol patronen:
- Caches zonder limieten voor verwijdering
- Eventlisteners die nooit worden afgemeld
- Groeiende globale verzamelingen
- Closures die grote objecten vastleggen
# unbounded cache = leak
cache = {}
def get(k):
if k not in cache:
cache[k] = expensive(k)
return cache[k]Toewijzingsprofilering
Bij GC-churn gaat het om de snelheid van geheugentoewijzingen, niet om de omvang van het actieve geheugen. Een toewijzingsprofiler laat zien welke aanroeplocaties de meeste kortlevende objecten maken, waardoor de verzamelaar bezig blijft.
GC-pauzes begrijpen
Lange GC-pauzes veroorzaken pieken in de latentie. Oorzaken zijn onder andere heaps die te klein zijn en daardoor vaak moeten worden verzameld, of enorme heaps waarbij elke verzameling veel tijd kost.
Vergelijk pauzeduren in GC-logboeken met je latentietracing om te bevestigen dat GC de oorzaak is voordat je gaat afstellen.
GC pause: 412ms heap_before: 3.8G heap_after: 1.1GAfstellen versus oplossen
GC-afstelling (heapgrootte, keuze van verzamelaar) behandelt symptomen. Minder toewijzingen of het oplossen van een lek behandelt de oorzaak. Geef altijd de voorkeur aan de oplossing; stel alleen af om tijd te winnen of een in wezen gezonde werklast te egaliseren.
Veilig gegevens vastleggen in productie
Heap-dumps kunnen het proces pauzeren en gevoelige gegevens bevatten. Maak ze op een canary-instantie die uit de rotatie is gehaald, bewaar de dumps veilig en geef voor voortdurend inzicht de voorkeur aan profilers die steekproeven nemen en weinig overhead hebben.
Een workflow voor geheugendebugging
Alles samengebracht:
- Bevestig aan de hand van de geheugencurve of het om een lek, overmatige omvang of churn gaat
- Maak heap-snapshots en vergelijk ze
- Volg ketens van vasthouders naar de verwijzing die het object vasthoudt
- Gebruik bij churn toewijzingsprofilering
- Los de oorzaak op; stel GC alleen af als dat nodig is
Korte controle
Test je begrip van geheugendebugging.
Samenvatting
Je hebt geleerd geheugenproblemen in actieve diensten te debuggen.
- Onderscheid lekken, overmatige omvang en churn met de geheugencurve
- Vergelijk heap-snapshots en volg de vasthouders
- Profileer toewijzingen voor GC-churn
- Los oorzaken op; stel GC alleen af om een gezonde belasting te egaliseren
Leer Draaiboek voor debuggen in productie en incidentrespons met een AI-tutor — gratis
Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.
- Cursussen
- 12
- Lessen
- 48
Veelgestelde vragen
Is de les “Memory leaks en GC-druk in productie debuggen” gratis?
Ja — je kunt hier op het web alle 3 lessen van het leerpad Draaiboek voor debuggen in productie en incidentrespons, waaronder “Memory leaks en GC-druk in productie debuggen”, gratis volledig lezen. Daarna ontgrendelt CoddyKit PRO alle lessen, plus interactieve oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. De cursus Draaiboek voor debuggen in productie en incidentrespons bevat in totaal 4 lessen.
Wat leer ik in “Memory leaks en GC-druk in productie debuggen”?
Diagnosticeer geleidelijke geheugengroei, pauzes door garbage collection en out-of-memory-crashes in actieve services met heapanalyse en allocatieprofiling. Je oefent met Draaiboek voor debuggen in productie en incidentrespons door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.
Heb ik ervaring nodig om met Draaiboek voor debuggen in productie en incidentrespons te beginnen?
Ervaring vooraf is niet nodig. Draaiboek voor debuggen in productie en incidentrespons op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 4 van 4.
Hoe lang duurt de les “Memory leaks en GC-druk in productie debuggen”?
De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.
Kan ik code schrijven en uitvoeren in deze les over Draaiboek voor debuggen in productie en incidentrespons?
Ja. Elke les over Draaiboek voor debuggen in productie en incidentrespons bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.
Alle lessen in deze cursus
- Performancebottlenecks identificeren
- Geavanceerde profiling van systemen en applicaties
- Strategieën voor databaseperformance bij debuggen
- Memory leaks en GC-druk in productie debuggen