Brendan Gregg’s prestatiemethoden voor latentie en profilering

Waarom Brendan Gregg’s aanpak gokwerk vermindert

Brendan Gregg is een van de meest invloedrijke stemmen op het gebied van systeemprestaties, vooral in de Linux-wereld. Hij heeft veelgebruikte boeken geschreven, praktische tooling gebouwd en—het belangrijkste—duidelijke methoden gedeeld om echte productieproblemen te onderzoeken. Teams passen zijn aanpak toe omdat het werkt onder druk: wanneer latentie piekt en iedereen antwoorden wil, heb je een manier nodig om van “misschien is het X” naar “het is zeker Y” te gaan met zo min mogelijk drama.

Wat een “prestatiemethodologie” echt betekent

Een prestatiemethodologie is geen enkele tool of slimme opdracht. Het is een herhaalbare manier van onderzoeken: een checklist voor wat je eerst moet bekijken, hoe je ziet wat je ziet en hoe je beslist wat je daarna doet.

Die herhaalbaarheid is wat gokwerk reduceert. In plaats van te vertrouwen op degene met de meeste intuïtie (of de luidste mening), volg je een consistent proces dat:

• het probleem terugbrengt tot een specifieke resource, service of codepad
• meet wat er gebeurt in hetzelfde tijdsvenster als het incident
• de bottleneck bevestigt met bewijs voordat je wijzingen doorvoert

De veelvoorkomende fout: fixen voordat je meet

Veel latentieonderzoeken lopen al mis in de eerste vijf minuten. Mensen springen meteen naar fixes: “voeg CPU toe,” “herstart de service,” “vergroot de cache,” “tune de GC,” “het moet het netwerk zijn.” Soms helpt dat—maar vaak verdoezelt het het signaal, verspil je tijd of introduceer je nieuw risico.

Gregg’s methoden dwingen je om “oplossingen” uit te stellen totdat je eenvoudigere vragen kunt beantwoorden: Wat is verzadigd? Wat geeft fouten? Wat is langzamer geworden—throughput, wachtrijen of individuele bewerkingen?

Wat deze gids je helpt doen

Deze gids helpt je de scope te beperken, de juiste signalen te meten en de bottleneck te bevestigen voordat je optimaliseert. Het doel is een gestructureerde workflow voor het onderzoeken van latentie- en profileringproblemen in productie, zodat resultaten niet van geluk afhangen.

Latentie basics: wat te meten vóór je gaat tunen

Latentie is een symptoom: gebruikers wachten langer tot werk klaar is. De oorzaak ligt meestal ergens anders—CPU-contentie, disk- of netwerkwachten, lock-contentie, garbage collection, wachtrijen of vertraging bij externe afhankelijkheden. Alleen latentie meten vertelt je dat er pijn is, niet waar die vandaan komt.

Throughput, latentie en fouten bewegen samen

Deze drie signalen zijn gekoppeld:

• Throughput (verzoeken/second) die stijgt kan wachtrijen doen toenemen, wat latentie verhoogt.
• Fouten kunnen waargenomen latentie verlagen (snelle falingen) of verhogen (retries en timeouts).
• Door throughput te beperken (rate limits, backpressure) kun je tail-latency verbeteren terwijl minder verzoeken slagen.

Voordat je gaat tunen, leg alle drie vast voor hetzelfde tijdsvenster. Anders “los” je latentie mogelijk op door werk te laten vallen of sneller te falen.

Vertrouw niet op gemiddelden: percentielen en tail-latency

Gemiddelde latentie verbergt pieken die gebruikers onthouden. Een service met 50 ms gemiddeld kan nog steeds frequente stalls van 2 s hebben.

Houd percentielen bij:

• p50: typische gebruikerservaring
• p95/p99: tail-latency (waar de meeste incident-pijn zit)

Kijk ook naar de vorm van de latentie: een stabiele p50 met een stijgende p99 wijst vaak op intermitterende stalls (bijv. lock-contentie, I/O-hiccups, stop-the-world pauzes) in plaats van een algemene vertraging.

Latentiebudgetten: waar tijd naartoe mag gaan

Een latentiebudget is een eenvoudige rekenoefening: “Als het verzoek binnen 300 ms klaar moet zijn, hoe kan die tijd worden verdeeld?” Deel het op in buckets zoals:

• tijd in jouw service (rekenwerk + wachten)
• tijd in downstream services
• tijd in databases/caches
• netwerktransit en TLS
• tijd in wachtrijen (threads, connection pools, load balancers)

Dit budget kadert de eerste meettaak: identificeer welke bucket groeide tijdens de spike en onderzoek dat gebied in plaats van blind te tunen.

Begin met een duidelijke vraag en scope

Latentiewerk ontspoort wanneer het “systeem is traag” wordt beschreven. Gregg’s methoden beginnen eerder: dwing de zaak in een specifieke, toetsbare vraag.

Definieer wat “traag” betekent (en voor wie)

Schrijf twee zinnen op voordat je tools aanraakt:

• Wat is traag? (pagina laden, API-endpoint, batchjob, login, checkout, een specifieke SQL-query)
• Waar wordt het traag waargenomen? (klantbrowser, mobiele app, één regio, één pod, één host, een interne service)

Dit voorkomt dat je de verkeerde laag optimaliseert—zoals host-CPU—terwijl de pijn beperkt is tot één endpoint of één downstream afhankelijkheid.

Kies een tijdvenster en scope

Kies een venster dat past bij de klacht en, indien mogelijk, een “goed” vergelijkingsperiode bevat.

Scope je onderzoek expliciet:

• Host vs. service vs. endpoint: “Één Kubernetes-node” is iets anders dan “één API-route.”
• Welke slice van verkeer: regio, klanttier, alleen foutgevende verzoeken of alle verzoeken.
• Welk signaal de melding aandrijft: p95-latentie, timeouts, queue-diepte of user-timing.

Precies zijn hier maakt latere stappen (USE, RED, profilering) sneller omdat je weet welke data zou moeten veranderen als je hypothese klopt.

Behandel recente wijzigingen als hypothesen, niet als antwoorden

Noteer deploys, config-wijzigingen, traffic-shifts en infra-events—maar neem ze niet als gegeven aan. Formuleer ze als “Als X, dan zouden we Y verwachten,” zodat je snel kunt bevestigen of verwerpen.

Houd een lichtgewicht onderzoekslog bij

Een klein log voorkomt dubbel werk tussen teamleden en maakt overdrachten soepeler.

Time | Question | Scope | Data checked | Result | Next step

Zelfs vijf regels zoals dit kunnen van een stressvol incident een herhaalbaar proces maken.

De USE-methode: een snelle inventaris van resource-bottlenecks

De USE-methode (Utilization, Saturation, Errors) is Gregg’s snelle checklist om de “grote vier” resources—CPU, geheugen, schijf (storage) en netwerk—te scannen, zodat je kunt stoppen met raden en beginnen met het versmallen van het probleem.

Wat het is: een checklist per resource

In plaats van naar tientallen dashboards te staren, stel je voor elke resource steeds dezelfde drie vragen:

• Utilization: Hoe druk is het nu?
• Saturation: Stroomt werk op (wachtrijen, wachttijd), zelfs als utilization niet maximaal is?
• Errors: Faalt het of retryt het op manieren die vertraging veroorzaken?

Toegepast als routine wordt dit een snelle inventaris waar “druk” aanwezig is.

Hoe het in de praktijk toe te passen

Voor CPU is utilization het percentage CPU-gebruik, saturation toont zich als run-queue pressure of threads die wachten om te draaien, en errors kunnen throttling (in containers) of slecht werkende interrupts zijn.

Voor geheugen is utilization gebruikt geheugen, saturation verschijnt vaak als paging of frequente garbage collection, en errors omvatten allocatiefouten of OOM-events.

Voor schijf is utilization device busy time, saturation is queue depth en lees/schrijf-wachttijd, en errors zijn I/O-fouten of timeouts.

Voor netwerk is utilization throughput, saturation drops/queues/latency, en errors retransmits, resets of packet loss.

Meest nuttige signalen tijdens latentie-incidenten

Bij melding van traagheid zijn saturatiesignalen vaak het meest onthullend: wachtrijen, wachttijd en contentie correleren meestal directer met latentie dan ruwe utilization.

USE vult servicemetrics aan (vervangt ze niet)

Service-metrics (zoals request-latentie en foutpercentage) vertellen je impact. USE vertelt je waar je vervolgens moet kijken door te identificeren welke resource onder druk staat.

Een praktische lus is:

1. Bevestig gebruikersimpact (Duration/Fouten)
2. Voer de USE-inventarisatie uit
3. Zoom in op de verdachte resource met diepere tooling (profielen, traces, kernel-statistieken)

De RED-methode: service-georiënteerde signalen die naar impact wijzen

De RED-methode houdt je verankerd aan gebruikerservaring voordat je in host-graphs duikt.

• Rate: hoeveel verzoeken per seconde je service of endpoint afhandelt
• Errors: hoeveel verzoeken falen (en wat “falen” betekent voor je app)
• Duration: hoe lang succesvolle verzoeken duren (bij voorkeur percentielen, niet gemiddelden)

Waarom RED helpt prioriteren

RED voorkomt dat je achter “interessante” systeemstatistieken aanholt die gebruikers niet raken. Het dwingt een kortere lus: welk endpoint is traag, voor welke gebruikers en sinds wanneer? Als Duration alleen op één route piekt terwijl CPU overall vlak is, heb je al een scherper startpunt.

Een nuttige gewoonte: houd RED uitgesplitst naar service en top-endpoints (of sleutel-RPC-methoden). Dat maakt het makkelijk om een brede degradatie te onderscheiden van een gelokaliseerde regressie.

RED-symptomen mappen naar USE-checks

RED vertelt je waar de pijn zit. USE helpt je te testen welke resource verantwoordelijk is.

Voorbeelden:

• Duration omhoog + Rate stabiel → check saturation/wachtrijen: CPU run queue, storage-latentie, DB-connectionpools.
• Errors omhoog + Duration omhoog → check timeouts en retries: overbelaste downstreams, threadpools, netwerkdrops.
• Rate omhoog + Duration omhoog → check capaciteitslimieten: CPU-utilization, load balancer-gedrag, autoscaling-vertragingen.

Een minimalistisch “wat veranderde?” dashboard

Houd de indeling gefocust:

1. RED-overzicht: Rate, Errors en p50/p95/p99 Duration voor de service.
2. Top endpoints: dezelfde RED-signalen per endpoint, gesorteerd op verkeer of slechtste p95.
3. Dependencies: RED-stijl panelen voor belangrijke downstreams (DB, cache, externe APIs).
4. Eén correlatierij: een kleine set systeemmetrics (CPU, geheugen, schijf I/O-latentie, netwerk-retransmits) om de sprong van service-view naar root-cause testen te versnellen.

Als je een consistente incident-workflow wilt, koppel dit dan aan de USE-inventaris zodat je sneller van “gebruikers voelen het” naar “deze resource is de beperking” komt zonder veel gedoe.

Prioriteren: kies de volgende beste vraag

Een prestatieonderzoek kan binnen minuten in tientallen grafieken en hypothesen exploderen. Gregg’s denkwijze is om het smal te houden: jouw taak is niet om “meer data te verzamelen”, maar om de volgende vraag te stellen die het snelst onzekerheid wegneemt.

De 80/20-regel voor bottlenecks

De meeste latentieproblemen worden gedomineerd door één kostenpost (of een klein paar): één hete lock, één trage afhankelijkheid, één overbelaste schijf, één GC-patroon. Prioriteren betekent eerst die dominante kost zoeken, want 5% knippen op vijf plekken verschuift zelden zichtbare latentie voor gebruikers.

Een praktische test: “Wat kan het grootste deel van de latentieverandering verklaren?” Als een hypothese slechts een klein deel kan verklaren, heeft het lagere prioriteit.

Top-down vs. bottom-up: waar te beginnen

Gebruik top-down als je antwoordt op “Hebben gebruikers er last van?” Begin bij endpoints (RED-signalen): latentie, throughput, fouten. Dat helpt je voorkomen dat je iets optimaliseert dat niet op het kritieke pad ligt.

Gebruik bottom-up als de host duidelijk ziek is (USE-symptomen): CPU-saturatie, runaway geheugen, I/O-wacht. Als een node vastloopt, verspil je tijd met endpoint-percentielen zonder de beperking te begrijpen.

Een eenvoudige beslisboom die thrash voorkomt

Wanneer een alert afgaat, kies een tak en blijf daarop totdat je het bevestigt of falsificeert:

• Latency spike + errors spike → “Is dit een dependency- of capaciteitsgebeurtenis?” (timeouts, connection pool-exhaustie, downstream 5xx)
• Latency spike + CPU spike → “Doet CPU nuttig werk of staat het vast?” (on-CPU vs off-CPU tijd)
• Latency spike + hoge I/O-wacht → “Welke device of filesystem-queue loopt vol?”
• Latency spike zonder resource-spikes → “Waar wordt tijd gewacht?” (locks, scheduler, netwerk, remote calls)

Voorkom metric-overload, blijf systematisch

Beperk jezelf tot een kleine set start-signalen en graaf pas door wanneer iets beweegt. Als je een checklist nodig hebt om focus te houden, koppel je stappen aan een runbook zodat elke nieuwe metric een doel heeft: het beantwoorden van een specifieke vraag.

Profileren in productie zonder het systeem neer te halen

Productieprofilering voelt riskant omdat het het live-systeem raakt—maar het is vaak de snelste manier om debat te vervangen door bewijs. Logs en dashboards vertellen je dat iets traag is. Profiling vertelt je waar tijd naartoe gaat: welke functies heet lopen, welke threads wachten en welke codepaden domineren tijdens het incident.

Wat profiling daadwerkelijk beantwoordt

Profiling is een tool om tijd te budgetteren. In plaats van te discussiëren (“het is de database” vs “het is GC”), krijg je bewijs zoals “45% van CPU-samples zat in JSON-parsing” of “de meeste requests zijn geblokkeerd op een mutex.” Dat versmalt de volgende stap tot één of twee concrete fixes.

Veelvoorkomende types die je in productie kunt gebruiken

• CPU-profiling: toont welke code on-CPU draait.
• Off-CPU (wait) profiling: toont waar threads hun tijd geblokkeerd doorbrengen (I/O-wachten, scheduler-delays, sleep, netwerk, schijf).
• Lock-profiling: toont contentie—tijd verloren wachtend op locks, mutexes en read/write-latches.

Elk beantwoordt een andere vraag. Hoge latentie met lage CPU wijst vaak naar off-CPU of lock-tijd in plaats van CPU-hotspots.

Always-on vs on-demand

• Always-on profiling (continu, lage overhead) helpt bij mysteries die “om 3 uur 's nachts” gebeurden omdat je kunt terugkijken.
• On-demand profiling is een gerichte capture tijdens een spike. Het is eenvoudiger in te voeren, maar je moet snel kunnen triggeren.

Veel teams beginnen met on-demand en schakelen naar always-on zodra ze de veiligheid vertrouwen en terugkerende issues zien.

Veiligheid: overhead, sampling en korte vensters

Productieve veilige profiling draait om kostenbeheersing. Geef de voorkeur aan sampling (niet elk event traceren), houd capture-vensters kort (bijv. 10–30 seconden) en meet overhead eerst in een canary. Als je twijfelt, begin met lage samplefrequentie en verhoog alleen als het signaal te ruisig is.

Flame graphs: hoe ze te lezen en valse conclusies te vermijden

Flame graphs visualiseren waar sampled tijd naartoe ging tijdens een profiling-venster. Elke “box” is een functie (of stack frame) en elke stack toont hoe uitvoering die functie bereikte. Ze zijn uitstekend om snel patronen te zien—maar ze zeggen niet automatisch “de bug zit hier.”

Wat een flame graph toont (en wat niet)

Een flame graph vertegenwoordigt meestal on-CPU samples: tijd dat het programma daadwerkelijk op een CPU-core draaide. Het kan CPU-intensieve codepaden, inefficiënte parsing, overmatige serialisatie of hotspots die echt CPU verbranden, aan het licht brengen.

Het toont niet direct wachten op schijf, netwerk, scheduler-delays of wachten op een mutex (dat is off-CPU tijd en vereist andere profiling). Het bewijst ook geen causaliteit voor gebruikerszichtbare latentie tenzij je het koppelt aan een afgebakend symptoom.

Breedte en stackdiepte lezen

• Breedte: hoe vaak dat frame in samples voorkwam. Breder betekent meestal “meer CPU-tijd,” maar alleen binnen het gekozen tijdsvenster.
• Stackdiepte: aanroepdiepte. Diepe stacks zijn niet per se slecht; belangrijk is welke paden domineren en of ze overeenkomen met het werk dat je belangrijk vindt.

Veelvoorkomende valkuilen

De breedste box is verleidelijk om te beschuldigen, maar vraag: is het een hotspot die je kunt veranderen, of gewoon “tijd besteed in malloc, GC of logging” omdat het echte probleem upstream ligt? Let ook op ontbrekende context (JIT, inlining, symbolen) die een box als schuldige kan doen lijken terwijl het slechts de boodschapper is.

Koppel flame graphs aan een precieze vraag

Behandel een flame graph als antwoord op een afgebakende vraag: welk endpoint, welk tijdvenster, welke hosts en wat veranderde. Vergelijk “voor vs na” (of “gezond vs gedegradeerd”) flame graphs voor hetzelfde request-pad om profiling-ruis te vermijden.

Off-CPU tijd: de verborgen bron van latentie

Wanneer latentie piekt, kijken veel teams eerst naar CPU%. Dat is begrijpelijk—maar vaak wijst het in de verkeerde richting. Een service kan “maar 20% CPU” gebruiken en toch pijnlijk traag zijn als threads het grootste deel van hun tijd niet draaien.

Waarom CPU% alleen misleidt

CPU% beantwoordt “hoe druk is de processor?” Het beantwoordt niet “waaraan ging de tijd van mijn verzoek op?” Verzoeken kunnen stagneren terwijl threads wachten, geblokkeerd zijn of gepauzeerd door de scheduler.

Een kernidee: wall-clock tijd van een verzoek omvat zowel on-CPU werk als off-CPU wachten.

Veelvoorkomende off-CPU boosdoeners

Off-CPU tijd verbergt zich vaak achter afhankelijkheden en contentie:

• Schijf I/O: synchrone reads/writes, fsyncs, trage opslag, page cache misses.
• Netwerkwachten: DNS-lookup, TCP-retransmits, overbelaste upstream services.
• Locks en mutex-contentie: threads geblokkeerd op locks, reader/writer-locks, allocator-contentie.
• Queueing: wachten in threadpools, connection pools of interne werkqueues.

Symptomen om op te letten

Een paar signalen correleren vaak met off-CPU bottlenecks:

• stijgende queue time (verzoeken wachten voordat ze beginnen)
• toenemende runnable threads (meer concurrentie om CPU-tijd)
• verhoogde I/O wait en langere schijf-/netwerk-latenties

Deze symptomen vertellen je “we wachten,” maar niet waarop.

Hoe off-CPU profiling laat zien “waarnaar de tijd ging”

Off-CPU profiling schrijft tijd toe aan de reden dat je niet draaide: geblokkeerd in syscalls, wachten op locks, slapen of gedescheduled worden. Dat is krachtig voor latentiewerk omdat het vage vertragingen in actiegerichte categorieën verandert: “geblokkeerd op mutex X”, “wacht op read() van schijf” of “vast in connect() naar upstream.” Als je de wacht kunt benoemen, kun je het meten, bevestigen en verhelpen.

Bevestig de bottleneck met bewijs, niet intuïtie

Prestatiewerk faalt vaak op hetzelfde moment: iemand ziet een verdacht metric, verklaart het “het probleem” en begint te tunen. Gregg’s methoden dwingen je te vertragen en te bewijzen wat het systeem beperkt voordat je iets verandert.

Bottleneck, hot spot en ruis

Een bottleneck is de resource of component die nu doorvoer beperkt of latentie gedreven heeft. Als je die verlicht, zien gebruikers verbetering.

Een hot spot is waar tijd aan besteed wordt (bijvoorbeeld een functie die vaak in een profiel voorkomt). Hot spots kunnen echte bottlenecks zijn—of gewoon druk werk dat het trage pad niet raakt.

Ruis is alles wat relevant lijkt maar dat niet is: achtergrondjobs, éénmalige pieken, sampling-artifacten, cache-effecten of “top talkers” die niet correleren met het gebruikerszichtbare probleem.

Bewijs leveren met vergelijkingen en gecontroleerde veranderingen

Begin met het vastleggen van een schoon voor-snapshot: het gebruikerssymptoom (latentie of foutpercentage) en de leidende kandidaat-signalen (CPU-saturatie, queue-diepte, schijf I/O, lock-contentie, enz.). Voer daarna een gecontroleerde wijziging uit die alleen je vermoede oorzaak zou moeten beïnvloeden.

Voorbeelden van causale tests:

• Voeg capaciteit toe aan de vermoede resource (een extra worker, meer CPU-shares, hogere connection pool) en controleer of latentie verbetert.
• Verminder tijdelijk de vraag (beperk een lawaaierig endpoint, replay een kleiner workload) en kijk of de vermoedelijke beperking ontspant.

Correlatie is een hint, geen verdict. Als “CPU stijgt wanneer latentie stijgt,” verifieer dan door CPU-beschikbaarheid te veranderen of CPU-werk te verminderen en observeer of latentie volgt.

Documenteer wat je bewezen hebt

Schrijf op: wat gemeten is, de exacte wijziging, voor/na-resultaten en de waargenomen verbetering. Dit maakt van een éénmalige winst een herbruikbaar recept voor het volgende incident—en voorkomt dat “intuïtie” later de geschiedenis herschrijft.

Bouw een herhaalbare workflow voor prestatie-incidenten

Prestatie-incidenten voelen urgent aan, wat precies het moment is waarop gokwerk insluipt. Een lichtgewicht, herhaalbare workflow helpt je om van “iets is traag” naar “we weten wat veranderde” te gaan zonder te veel te switchen.

De incidentlus: detecteren → triage → meten → fixen

Detecteer: alert op gebruikerszichtbare latentie en foutpercentages, niet alleen CPU. Laat pagen wanneer p95/p99-latentie een drempel overschrijdt voor een aanhoudend venster.

Triage: beantwoord meteen drie vragen: wat is traag, wanneer begon het en wie is getroffen? Als je de scope (service, endpoint, regio, cohort) niet kunt benoemen, ben je nog niet klaar om te optimaliseren.

Meet: verzamel bewijs dat de bottleneck versmalt. Geef de voorkeur aan tijdsgebonden captures (bijv. 60–180 seconden) zodat je “slecht” vs “goed” kunt vergelijken.

Fix: verander één ding tegelijk en meet daarna dezelfde signalen om verbetering te bevestigen en placebo uit te sluiten.

Standaardiseer een kleine set grafieken

Houd een gedeeld dashboard dat iedereen tijdens incidenten gebruikt. Maak het saai en consistent:

• Latentie: p50 / p95 / p99 (per kritisch endpoint)
• RED-signalen: Rate, Errors, Duration (service-georiënteerd)
• Enkele USE-metrics: utilization, saturation, errors voor CPU, schijf en netwerk

Het doel is niet alles te grafieken; het doel is de time-to-first-fact te verkorten.

Definieer “golden signals” per kritisch endpoint

Instrumenteer de endpoints die er het meest toe doen (checkout, login, search), niet elk endpoint. Spreek voor elk af: verwachte p95, maximale foutpercentage en belangrijkste afhankelijkheid (DB, cache, derde partij).

Bepaal wat je tijdens incidenten vastlegt

Stem vooraf af wat er bij een volgend uitval vastgelegd moet worden:

• Profielen (CPU en off-CPU), plus flame graphs
• Traces voor de trage endpoints
• Logs voor fouten/timeouts (gesampled)

Documenteer dit in een kort runbook (bijv. een latency-runbook), inclusief wie captures mag uitvoeren en waar artefacten worden opgeslagen.

Waar Koder.ai in een Gregg-stijl workflow past

Gregg’s methodologie draait fundamenteel om gecontroleerde verandering en snelle verificatie. Als je team diensten bouwt met Koder.ai (een chatgestuurd platform om web-, backend- en mobiele apps te genereren en itereren), sluiten twee features hier goed op aan:

• Planning Mode helpt je om van “misschien is het X” naar een expliciete hypothese en een kleine, toetsbare wijzigingsset te gaan voordat je productie aanraakt.
• Snapshots en rollback ondersteunen veilige, één-variabele-experimenten: voer één wijziging door, meet RED/USE-signalen opnieuw en rol snel terug als het bewijs “nee” zegt.

Zelfs als je tijdens een incident geen nieuwe code genereert, zijn die gewoonten—kleine diffs, meetbare uitkomsten en snelle omkeerbaarheid—dezelfde gewoonten die Gregg promoot.

Een praktische walkthrough: van latentie-spike naar geverifieerde fix

Het scenario: p99 stijgt tijdens piekverkeer

Het is 10:15 en je dashboard toont dat p99-latentie voor de API stijgt van ~120ms naar ~900ms tijdens piekverkeer. Het foutpercentage blijft vlak, maar klanten melden “langzame” verzoeken.

Stap 1 — Begin met RED om gebruikersimpact te vinden

Begin service-first: Rate, Errors, Duration.

Je snijdt Duration per endpoint en ziet één route domineren in de p99: POST /checkout. Rate is 2× hoger, fouten zijn normaal, maar Duration piekt specifiek wanneer concurrency stijgt. Dat wijst op wachtrijen of contentie, niet op een volledige uitval.

Controleer vervolgens of de latentie rekenwerk is of wachten: vergelijk applicatie “handler-tijd” met totale requesttijd (of upstream vs downstream spans als je tracing hebt). Handler-tijd is laag, totale tijd is hoog—verzoeken wachten.

Stap 2 — Pas USE toe op de verdachte host(s)

Maak een inventaris van waarschijnlijke bottlenecks: Utilization, Saturation, Errors voor CPU, geheugen, schijf en netwerk.

CPU-utilization is maar ~35%, maar de CPU run queue en context switches stijgen. Schijf en netwerk zien er stabiel uit. Die mismatch (lage CPU%, hoge wachttijd) is een klassiek hint: threads verbranden geen CPU—ze zijn geblokkeerd.

Stap 3 — Kies profiling op basis van symptomen

• Als CPU hoog is: gebruik CPU-profiling (on-CPU flame graphs) om te zien waar tijd aan besteed wordt.
• Als verzoeken wachten: gebruik off-CPU profiling om te zien waarop threads geblokkeerd zijn (locks, I/O, scheduler).

Je neemt een off-CPU profiel tijdens de spike en vindt veel tijd in een mutex rond een gedeelde “promotion validation” cache.

Stap 4 — Fix en verifieer

Je vervangt de globale lock door een per-key lock (of een lock-free read-path), deployt en ziet p99 terugkeren naar baseline terwijl Rate hoog blijft.

Post-incident checklist:

• Noteer de exacte RED-symptomen en het gespecificeerde endpoint.
• Bewaar het profiel en het tijdsvenster.
• Voeg een alert toe voor het specifieke saturatiesignaal (bijv. lock-wacht / run queue).
• Schrijf op welke “volgende vraag” je stelt als het opnieuw gebeurt.