Brendan Gregg:s metoder för latens och profilering

Varför Brendan Gregg:s tillvägagångssätt minskar gissningar

Brendan Gregg är en av de mest inflytelserika rösterna inom systemprestanda, särskilt i Linux-världen. Han har skrivit välanvända böcker, byggt praktiska verktyg och — viktigast av allt — delat tydliga metoder för att undersöka verkliga produktionsproblem. Team tar till sig hans tillvägagångssätt eftersom det fungerar under press: när latensen skjuter i höjden och alla vill ha svar behöver du ett sätt att gå från “kanske är det X” till “det är definitivt Y” med minimal dramatik.

Vad "prestandametodik" egentligen betyder

En prestandametodik är inte ett enda verktyg eller ett fiffigt kommando. Det är ett upprepbart sätt att undersöka: en checklista för vad du ska titta på först, hur du tolkar det du ser och hur du beslutar vad du gör härnäst.

Den upprepbarheten är vad som minskar gissningar. Istället för att lita på den som har mest intuition (eller högsta rösten) följer ni en konsekvent process som:

• begränsar problemet till en specifik resurs, tjänst eller kodväg
• mäter vad som händer i samma tidsfönster som incidenten
• bekräftar flaskhalsen med bevis innan ändringar görs

Det vanliga felmönstret: åtgärda innan du mäter

Många latensutredningar går fel i de första fem minuterna. Folk hoppar direkt till åtgärder: "lägg till CPU", "starta om tjänsten", "öka cachen", "tuna GC", "det måste vara nätverket". Ibland hjälper sådana åtgärder — ofta döljer de signalen, slösar tid eller introducerar ny risk.

Gregg:s metoder uppmanar dig att vänta med "lösningar" tills du kan svara på enklare frågor: Vad är mättat? Vad går fel? Vad blev långsammare — genomströmning, kötid eller enskilda operationer?

Vad den här guiden hjälper dig göra

Den här guiden hjälper dig avgränsa omfattningen, mäta rätt signaler och bekräfta flaskhalsen innan du optimerar. Målet är ett strukturerat arbetsflöde för att undersöka latens- och profileringsproblem i produktion så att resultat inte beror på tur.

Latensgrund: vad du ska mäta innan du tunar

Latens är ett symptom: användare väntar längre på att arbete ska bli klart. Orsaken ligger oftast någon annanstans — CPU-konkurrens, disk- eller nätverksspärrar, låskonkurrens, garbage collection, köning eller fördröjningar i fjärrberoenden. Att mäta endast latens berättar att smärta finns, inte var den kommer ifrån.

Genomströmning, latens och fel rör sig tillsammans

Dessa tre signaler hänger ihop:

• Genomströmning (requests/sek) som stiger kan öka köning, vilket ökar latensen.
• Fel kan minska observerad latens (snabba fel) eller öka den (retryer och timeouts).
• Att begränsa genomströmning (rate limits, backpressure) kan förbättra tail-latens samtidigt som färre förfrågningar lyckas.

Innan du finjusterar, fånga alla tre för samma tidsfönster. Annars kan du "fixa" latens genom att släppa arbete eller misslyckas snabbare.

Lita inte på medelvärden: percentiler och tail-latens

Medellatens döljer toppar som användare minns. En tjänst med 50 ms i medelvärde kan ändå ha frekventa 2 s-stall.

Spåra percentiler:

• p50: typisk användarupplevelse
• p95/p99: tail-latens (där de flesta incidentproblemen bor)

Håll också koll på latensens form: en stabil p50 med en stigande p99 indikerar ofta intermittenta stall (t.ex. låskonkurrens, I/O-hickups, stop-the-world-pauser) snarare än generell fördröjning.

Latensbudgetar: var tiden får gå

En latensbudget är en enkel bokföringsmodell: "Om förfrågan måste bli klar på 300 ms, hur kan tiden användas?" Bryt den i fack som:

• tid i din tjänst (beräkning + väntan)
• tid i nedströms tjänster
• tid i databaser/cacher
• nätverkstransit och TLS
• tid som spenderas i kö (trådar, connection pools, load balancers)

Denna budget ramar in den första mätuppgiften: identifiera vilket fack som växte under spiken och undersök det området istället för att justera blint.

Börja med en tydlig fråga och avgränsning

Latensarbete går fel när problemet beskrivs som systemet är långsamt. Gregg:s metoder börjar tidigare: tvinga frågan till en specifik, testbar fråga.

Definiera vad "långsamt" betyder (och för vem)

Skriv ner två meningar innan du rör några verktyg:

• Vad är långsamt? (sidladdning, API-endpoint, batchjobb, login, checkout, en specifik SQL-fråga)
• Var observeras det långsamma? (kundens webbläsare, mobilapp, en region, en pod, en host, en intern tjänst)

Detta hindrar dig från att optimera fel lager — som host-CPU — när problemet är isolerat till en endpoint eller ett nedströmsberoende.

Välj ett tidsfönster och en avgränsning

Välj ett fönster som matchar klagomålet och inkluderar en jämförelseperiod om möjligt.

Avgränsa din undersökning explicit:

• Host vs tjänst vs endpoint: "En Kubernetes-node" är inte samma sak som "en API-route".
• Vilken del av trafiken: region, kundnivå, bara felande förfrågningar eller all trafik.
• Vilken signal som drev rapporten: p95-latens, timeouts, ködjup eller användarmätning.

Att vara precis här gör senare steg (USE, RED, profilering) snabbare eftersom du vet vilken data som skulle förändras om din hypotes stämmer.

Behandla nyliga ändringar som hypoteser, inte svar

Notera deploys, configändringar, trafikskiften och infra-händelser — men anta inte kausalitet. Skriv dem som "Om X, då skulle vi förvänta oss Y", så att du snabbt kan bekräfta eller förkasta.

Håll en lättvikts logg för utredningen

En liten logg förhindrar duplicerat arbete mellan kollegor och gör överlämningar smidigare.

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

Även fem rader som dessa kan förvandla en stressad incident till en upprepbar process.

USE-metoden: en snabb inventering av resursflaskhalsar

USE-metoden (Utilization, Saturation, Errors) är Gregg:s snabba checklista för att skanna de "fyra stora" resurserna — CPU, minne, disk (lagring) och nätverk — så att du kan sluta gissa och börja begränsa problemet.

Vad det är: en per-resurs checklista

Istället för att stirra på dussintals dashboards, ställ samma tre frågor för varje resurs:

• Utilization: Hur upptagen är den just nu?
• Saturation: Bygger arbete upp sig (köer, väntetid), även om användningen inte är maxad?
• Errors: Misslyckas den eller retryar på ett sätt som skapar fördröjning?

Tillämpat konsekvent blir detta en snabb inventering av var "trycket" finns.

Hur du applicerar det i praktiken

För CPU är utilization % CPU upptagen, saturation visar sig som run-queue-tryck eller trådar som väntar på att köra, och fel kan inkludera throttling (i containers) eller problematiska interrupts.

För minne är utilization använt minne, saturation visar sig ofta som paging eller frekvent garbage collection, och fel inkluderar allocationsfailures eller OOM-händelser.

För disk är utilization device busy-tid, saturation är ködjup och läs-/skrivväntetid, och fel är I/O-fel eller timeouts.

För nätverk är utilization genomströmning, saturation är drops/köer/latens, och fel är retransmits, resets eller paketförlust.

Mest användbara signaler under latensincidenter

När användare rapporterar tröghet är saturationssignaler ofta mest avslöjande: köer, väntetid och konkurrens tenderar att korrelera mer direkt med latens än rå utilization.

USE kompletterar tjänstemetriker (ersätter dem inte)

Tjänstenivå-metriker (som förfrågningslatens och felkvot) berättar påverkan. USE berättar var du ska titta härnäst genom att identifiera vilken resurs som är under belastning.

En praktisk loop är:

1. Bekräfta användarpåverkan (Duration/Fel)
2. Kör USE-inventeringen
3. Zooma in på den misstänkta resursen med djupare verktyg (profiler, traces, kernel-statistik)

RED-metoden: tjänste-först-signaler som pekar på påverkan

RED-metoden håller dig förankrad i användarupplevelsen innan du dyker ner i host-grafer.

• Rate: hur många förfrågningar per sekund din tjänst eller endpoint hanterar
• Errors: hur många förfrågningar som misslyckas (och vad "misslyckande" betyder för din app)
• Duration: hur lång tid lyckade förfrågningar tar (spåras som percentiler, inte medelvärden)

Varför RED hjälper dig prioritera

RED förhindrar att du jagar "intressanta" systemmetrik som inte påverkar användarna. Det tvingar ett snävare kretslopp: vilken endpoint är långsam, för vilka användare och sedan när? Om Duration bara spikear på en enda route medan CPU är stabil har du redan en skarpare utgångspunkt.

En nyttig vana: håll RED uppdelat per tjänst och toppendpoints (eller nyckel-RPC-metoder). Det gör det enkelt att skilja mellan bred degradering och lokal regression.

Karta RED-symptom till USE-kontroller

RED berättar var smärtan är. USE hjälper dig testa vilken resurs som är ansvarig.

Exempel:

• Duration upp + Rate stabil → kolla saturation/köning: CPU run queue, lagringslatens, DB-connection pools.
• Errors upp + Duration upp → kolla timeouts och retryer: överbelastade nedströms, trådpooler, nätverksfel.
• Rate upp + Duration upp → kolla kapacitetsgränser: CPU-användning, load balancer-beteende, autoscaling-fördröjningar.

En minimal "vad ändrades?"-dashboard

Håll layouten fokuserad:

1. RED-översikt: Rate, Errors och p50/p95/p99 Duration för tjänsten.
2. Top endpoints: samma RED-signaler per endpoint, sorterat efter trafik eller värst p95.
3. Beroenden: RED-stilpaneler för stora nedströms (DB, cache, externa API:er).
4. En korrelationsrad: en liten uppsättning systemmetrik (CPU, minnespress, disk I/O-latens, nätverksretransmits) för att påskynda hoppet från tjänstvy till rotorsaksprov.

Om du vill ha ett konsekvent incidentarbetsflöde, para ihop den här sektionen med USE-inventeringen så att du snabbt kan gå från "användare känner av det" till "denna resurs är begränsningen" med mindre kast.

Prioritering: välj nästa bästa fråga att ställa

En prestandautredning kan explodera i dussintals grafer och hypoteser på några minuter. Gregg:s tänkesätt är att hålla det snävt: ditt jobb är inte att "samla mer data", utan att ställa nästa fråga som snabbast eliminerar osäkerhet.

80/20-regeln för flaskhalsar

De flesta latensproblem domineras av en enda kostnad (eller ett litet par): en het lås, ett långsamt beroende, en överbelastad disk, ett GC-pausmönster. Prioritering betyder att leta efter den dominerande kostnaden först, eftersom att skära 5 % från fem olika ställen sällan rör användarupplevd latens.

Ett praktiskt test: "Vad kan förklara största delen av latensförändringen vi ser?" Om en hypotes bara kan stå för en liten andel är det en lägre prioritet.

Top-down vs bottom-up: var börja

Använd top-down när du svarar på "Blir användarna påverkade?" Börja från endpoints (RED-stil): latens, genomströmning, fel. Detta hjälper dig undvika att optimera något som inte ligger på den kritiska vägen.

Använd bottom-up när en host tydligt är sjuk (USE-symptom): CPU-saturation, runaway minnespress, I/O-wait. Om en nod är peggad kommer du slösa tid på endpoint-percentiler utan att förstå begränsningen.

Ett enkelt beslutsträd som förhindrar thrash

När ett larm går, välj en gren och håll dig till den tills du bekräftar eller falsifierar den:

• Latensspik + felspik → "Är detta en beroende- eller kapacitetshändelse?" (timeouts, connection pool-exhaustion, nedströms 5xx)
• Latensspik + CPU-spik → "Gör CPU användbar arbete eller sitter den fast?" (on-CPU vs off-CPU-tid)
• Latensspik + hög I/O-wait → "Vilken enhet eller filsystemkö är full?"
• Latensspik utan resurs-spikar → "Var spenderas tiden på att vänta?" (lås, schemaläggare, nätverk, fjärranrop)

Undvik metrikinformation överbelastning, håll det systematiskt

Begränsa dig till en liten startuppsättning signaler och borra bara ner när något rör sig. Om du behöver en checklista för fokus, koppla dina steg till en runbook så att varje ny metrisk har ett syfte: att besvara en specifik fråga.

Profilering i produktion utan att ta ner systemet

Profilering i produktion kan kännas riskabelt eftersom den rör live-systemet — men det är ofta det snabbaste sättet att ersätta debatt med bevis. Loggar och dashboards kan berätta att något är långsamt. Profilering berättar var tiden går: vilka funktioner är varma, vilka trådar väntar och vilka kodvägar dominerar under incidenten.

Vad profilering faktiskt svarar

Profilering är ett verktyg för "tidsbudget". Istället för att diskutera teorier ("det är databasen" vs "det är GC") får du bevis som "45 % av CPU-samples var i JSON-parsning" eller "de flesta förfrågningar blockerades på en mutex". Det smalnar ner nästa steg till en eller två konkreta fixar.

Vanliga typer du kan använda i produktion

• CPU-profilering: visar vilken kod som körs on-CPU.
• Off-CPU (wait) profilering: visar var trådar spenderar tid blockerade (I/O-wait, schemaläggningsfördröjning, sleep, nätverk, disk).
• Låsprofilering: visar konkurrens — tid förlorad väntande på lås, mutexar och read/write-latchar.

Var och en svarar en annan fråga. Hög latens med låg CPU pekar ofta mot off-CPU eller låstid snarare än CPU-hotspots.

Alltid-på vs on-demand

• Alltid-på profilering (kontinuerlig, låg overhead) hjälper med mysterier som hände klockan 03:00 eftersom du kan titta bakåt.
• On-demand profilering är en riktad inspelning under en spik. Den är enklare att införa, men du måste vara redo att trigga den snabbt.

Många team börjar med on-demand och växlar till alltid-på när de litar på säkerheten och ser återkommande problem.

Säkerhet: overhead, sampling och korta fönster

Produktsäker profilering handlar om att kontrollera kostnaden. Föredra sampling (inte att spåra varje event), håll inspelningsfönster korta (t.ex. 10–30 sekunder) och mät overhead i en canary först. Om du är osäker, börja med lågfrekvent sampling och öka bara om signalen är för brusig.

Flame graphs: hur man läser dem och undviker felaktiga slutsatser

Flame graphs visualiserar var sample-tiden gick under ett profileringsfönster. Varje "ruta" är en funktion (eller stackframe) och varje stack visar hur exekveringen nådde den funktionen. De är utmärkta för att snabbt se mönster — men de säger inte automatiskt "felet är här".

Vad en flame graph visar (och inte visar)

En flame graph representerar vanligtvis on-CPU-samples: tid programmet faktiskt körde på en CPU-kärna. Den kan lyfta fram CPU-tunga kodvägar, ineffektiv parsning, överdriven serialisering eller hotspots som verkligen bränner CPU.

Den visar inte direkt väntan på disk, nätverk, schemaläggningsfördröjningar eller tid blockerad på en mutex (det är off-CPU-tid och kräver annan profilering). Den bevisar inte heller kausalitet för användarupplevd latens om du inte kopplar den till ett avgränsat symptom.

Läsa bredd och stackdjup

• Bredd: hur ofta den ramen dök upp i samples. Breda rutor betyder vanligtvis "mer CPU-tid", men bara inom valt tidsfönster.
• Stackdjup: anropsdjup. Djupa stackar är inte per definition dåliga; det som spelar roll är vilka vägar som dominerar och om de matchar arbetet du bryr dig om.

Vanliga fallgropar att undvika

Den bredaste rutan är frestande att skylla på, men fråga: är det en hotspot du kan ändra, eller bara "tid i malloc, GC eller logging" eftersom den verkliga orsaken är uppströms? Var också uppmärksam på saknad kontext (JIT, inlining, symboler) som kan få en ruta att se ut som boven när den bara är budbärare.

Para flame graphs med en precis fråga

Behandla en flame graph som ett svar på en avgränsad fråga: vilken endpoint, vilket tidsfönster, vilka hosts och vad ändrades. Jämför "före vs efter" (eller "frisk vs degraderad") flame graphs för samma request-path för att undvika profileringsbrus.

Off-CPU-tid: den dolda källan till latens

När latensen spikar stirrar många team på CPU% först. Det är förståeligt — men det pekar ofta åt fel håll. En tjänst kan vara "bara 20 % CPU" och ändå vara smärtsamt långsam om trådarna spenderar större delen av sin tid inte körande.

Varför CPU% ensamt missleder

CPU% svarar på "hur upptagen är processorn?" Det svarar inte på "var gick min förfrågnings tid?" Förfrågningar kan stanna upp medan trådar väntar, blockeras eller parkeras av schemaläggaren.

En nyckelidé: en förfrågnings väggklockstid inkluderar både on-CPU-arbete och off-CPU-väntan.

Vanliga off-CPU-skyldiga

Off-CPU-tid döljer sig ofta bakom beroenden och konkurrens:

• Disk I/O: synkrona läsningar/skrivningar, fsyncs, långsam lagring, page cache-missar.
• Nätverksväntan: DNS-uppslag, TCP-retransmits, överbelastade upstream-tjänster.
• Lås- och mutex-konkurrens: trådar blockerade på lås, reader/writer-lås, allocator-konkurrens.
• Köning: väntan i trådpooler, connection pools eller interna arbetsköer.

Symptom att hålla koll på

Ett par signaler korrelerar ofta med off-CPU-flaskhalsar:

• stigande kötid (förfrågningar väntar innan de börjar exekvera)
• ökande runnable threads (mer konkurrens om CPU-tid)
• förhöjd I/O wait och längre disk-/nätverkslatens

Dessa symptom säger "vi väntar", men inte på vad du väntar.

Hur off-CPU-profilering visar "var tiden gick"

Off-CPU-profilering tillskriver tid till orsaken till att du inte körde: blockerad i syscall, väntar på lås, sleep eller descheduled. Det är kraftfullt för latensarbete eftersom det förvandlar vaga långsamma perioder till handlingsbara kategorier: "blockerad på mutex X", "väntar på read() från disk" eller "fast i connect() till en upstream." När du kan namnge väntan kan du mäta den, bekräfta den och åtgärda den.

Bekräfta flaskhalsen med bevis, inte intuition

Prestandaarbete misslyckas ofta i samma ögonblick: någon ser en misstänkt metrisk, deklarerar den "problemet" och börjar tunna. Gregg:s metoder uppmuntrar dig att bromsa och bevisa vad som begränsar systemet innan du ändrar något.

Flaskhals, hotspot och brus

En flaskhals är den resurs eller komponent som för närvarande sätter gränsen för genomströmning eller driver latens. Om du avlastar den ser användarna förbättring.

En hotspot är var tid spenderas (t.ex. en funktion som ofta dyker upp i en profil). Hotspots kan vara verkliga flaskhalsar — eller bara upptagen tid som inte påverkar den långsamma vägen.

Brus är allt som ser meningsfullt ut men inte är det: bakgrundsjobb, engångsspikar, samplingartefakter, cache-effekter eller "top talkers" som inte korrelerar med det användarobserverade problemet.

Bevisa det med jämförelser och kontrollerad ändring

Börja med att ta en ren före-snapshot: det användarvända symptomet (latens eller felkvot) och de ledande kandidat-signalerna (CPU-saturation, ködjup, disk I/O, låskonkurrens osv.). Applicera sedan en kontrollerad ändring som borde påverka bara din misstänkta orsak.

Exempel på kausala tester:

• Lägg till kapacitet för den misstänkta resursen (en mer worker, fler CPU-andelar, större connection pool) och kontrollera om latensen förbättras.
• Minska tillfälligt efterfrågan (begränsa en bullrig endpoint, spela upp ett mindre arbetsflöde) och se om den misstänkta begränsningen släpper.

Korrelation är en vink, inte en dom. Om "CPU går upp när latens går upp", verifiera genom att ändra CPU-tillgänglighet eller minska CPU-arbetet och observera om latensen följer efter.

Dokumentera vad du bevisade

Skriv ner: vad som mättes, den exakta ändringen som gjordes, före/efter-resultaten och den observerade förbättringen. Detta förvandlar en engångsvinst till en återanvändbar playbook för nästa incident — och förhindrar att "intuition" skriver om historien senare.

Bygg ett upprepbart arbetsflöde för prestandaincidenter

Prestandaincidenter känns brådskande, vilket är precis när gissningar smyger in. Ett lättviktigt, upprepbart arbetsflöde hjälper dig gå från "något är långsamt" till "vi vet vad som ändrades" utan thrash.

Incidentloopen: upptäck → triagera → mät → åtgärda

Upptäck: larma på användarobserverbar latens och felkvot, inte bara CPU. Pagera när p95/p99-latens korsar en tröskel under en varaktig period.

Triagera: svara omedelbart på tre frågor: vad är långsamt, när startade det och vem påverkas? Om du inte kan namnge omfattningen (tjänst, endpoint, region, kohort) är du inte redo att optimera.

Mät: samla bevis som begränsar flaskhalsen. Föredra tidsbegränsade inspelningar (t.ex. 60–180 sekunder) så du kan jämföra "dåligt" vs "bra".

Åtgärda: ändra en sak i taget, mät sedan om samma signaler förbättras för att bekräfta och utesluta placebo.

Standardisera en liten uppsättning grafer

Håll en delad dashboard som alla använder under incidenter. Gör den tråkig och konsekvent:

• Latens: p50 / p95 / p99 (per kritisk endpoint)
• RED-signaler: Rate, Errors, Duration (tjänst-först vy)
• Ett fåtal USE-metriker: utilization, saturation, errors för CPU, disk och nätverk

Målet är inte att grafa allt; det är att korta tiden till första fakta.

Definiera "golden signals" per kritisk endpoint

Instrumentera de endpoints som betyder mest (checkout, login, search), inte varje endpoint. För varje, kom överens om: förväntad p95, maximal felkvot och nyckelberoende (DB, cache, tredjepart).

Bestäm vad som ska fångas under incidenter

Innan nästa outage, kom överens om ett fångstkit:

• Profiler (CPU och off-CPU), plus flame graphs
• Traces för de långsamma endpoints
• Loggar för fel/timeouts (samplade)

Dokumentera det i en kort runbook (t.ex. en runbook för latency), inklusive vem som kan köra inspelningar och var artefakter sparas.

Var Koder.ai passar in i ett Gregg-liknande arbetsflöde

Gregg:s metodologi handlar i grunden om kontrollerade ändringar och snabb verifiering. Om ditt team bygger tjänster med Koder.ai (en chattdriven plattform för att generera och iterera web-, backend- och mobilappar) så matchar två funktioner väl med det tankesättet:

• Planning Mode hjälper dig omvandla "kanske är det X" till en tydlig hypotes och en liten, testbar ändringsuppsättning innan du rör produktion.
• Snapshots and rollback stödjer säkra, envariabel-experiment: applicera en ändring, mät RED/USE-signalerna och rulla tillbaka snabbt om bevisen säger "nej."

Även om du inte genererar ny kod under en incident så är vanorna — små diffar, mätbara utfall och snabb återställning — samma vanor Gregg förespråkar.

En praktisk genomgång: från latensspik till verifierad fix

Scenariot: p99 hoppar vid peak-trafik

Klockan är 10:15 och din dashboard visar att p99-latensen för API:et klättrar från ~120 ms till ~900 ms under peak-trafik. Felkvoten är stabil, men kunder rapporterar "långa" svarstider.

Steg 1 — Starta med RED för att hitta användarpåverkan

Börja tjänst-först: Rate, Errors, Duration.

Du delar Duration per endpoint och ser att en route dominerar p99: POST /checkout. Rate har ökat 2×, fel är normala, men Duration spikear specifikt när samtidigheten stiger. Det pekar på köning eller konkurrens, inte ett fullständigt fel.

Kolla om latensen är beräknings-tid eller vänt-tid: jämför applikationens "handler time" mot total request-tid (eller upstream vs downstream-spans om du har tracing). Handler-tiden är låg, total tid är hög — förfrågningarna väntar.

Steg 2 — Applicera USE på de misstänkta hostarna

Inventera sannolika flaskhalsar: Utilization, Saturation, Errors för CPU, minne, disk och nätverk.

CPU-utilization är bara ~35 %, men CPU run queue och context switches stiger. Disk och nätverk ser stabila ut. Den mismatchen (låg CPU%, hög vänt) är en klassisk ledtråd: trådar bränner inte CPU — de är blockerade.

Steg 3 — Välj profilering baserat på symptomen

• Om CPU är hög: använd CPU-profilering (on-CPU flame graphs) för att se var tiden spenderas.
• Om förfrågningar väntar: använd off-CPU-profilering för att se vad trådar blockerar på (lås, I/O, schemaläggning).

Du tar en off-CPU-profil under spiken och hittar mycket tid i en mutex runt en delad "promotion validation"-cache.

Steg 4 — Åtgärda, sedan verifiera

Du byter ut globalt lås mot per-nyckel-lås (eller en lock-free read-väg), deployar och ser p99 gå tillbaka till baseline medan Rate är fortsatt hög.

Post-incident checklista:

• Dokumentera de exakta RED-symptomen och den avgränsade endpointen.
• Spara profilen och tidsfönstret.
• Lägg till en alert för den specifika saturationssignalen (t.ex. lock wait / run queue).
• Skriv ner nästa fråga att ställa om det händer igen.