Metodi di Brendan Gregg per le prestazioni: latenza e profiling

Perché l'approccio di Brendan Gregg riduce le supposizioni

Brendan Gregg è una delle voci più influenti nelle prestazioni dei sistemi, specialmente nell'ambito Linux. Ha scritto libri molto usati, creato strumenti pratici e — soprattutto — condiviso metodi chiari per investigare problemi reali in produzione. I team adottano il suo approccio perché funziona sotto pressione: quando la latenza sale e tutti vogliono risposte, serve un modo per passare da “forse è X” a “è sicuramente Y” con il minimo clamore.

Cosa significa davvero “metodologia di performance”

Una metodologia di performance non è un singolo strumento o un comando intelligente. È un modo ripetibile di investigare: una checklist su cosa guardare per primo, come interpretare ciò che vedi e come decidere il passo successivo.

Questa ripetibilità è ciò che riduce le supposizioni. Invece di affidarci a chi ha più intuito (o all'opinione più forte), seguiamo un processo coerente che:

• restringe il problema a una risorsa, servizio o percorso di codice specifico
• misura cosa sta succedendo nella stessa finestra temporale dell'incidente
• conferma il collo di bottiglia con evidenze prima di applicare cambiamenti

Il modo comune in cui si fallisce: correggere prima di misurare

Molte indagini sulla latenza vanno storto nei primi cinque minuti. Si passa subito alle soluzioni: “aggiungi CPU”, “riavvia il servizio”, “aumenta la cache”, “tweaka il GC”, “dev'essere la rete”. A volte queste azioni aiutano—spesso però nascondono il segnale, sprecano tempo o introducono nuovo rischio.

I metodi di Gregg ti spingono a rimandare le “soluzioni” finché non puoi rispondere a domande più semplici: cosa è satura? cosa genera errori? cosa è rallentato — il throughput, la coda o le singole operazioni?

Cosa ti aiuta a fare questa guida

Questa guida ti aiuta a restringere l'ambito, misurare i segnali giusti e confermare il collo di bottiglia prima di ottimizzare. L'obiettivo è un workflow strutturato per investigare problemi di latenza e di profiling in produzione, così i risultati non dipendono dalla fortuna.

Fondamenti di latenza: cosa misurare prima di ottimizzare

La latenza è un sintomo: gli utenti aspettano più a lungo che il lavoro finisca. La causa di solito è altrove — contesa CPU, attese su disco o rete, contesa di lock, garbage collection, code o ritardi in dipendenze remote. Misurare solo la latenza ti dice che c'è un dolore, non da dove proviene.

Throughput, latenza ed errori si muovono insieme

Questi tre segnali sono collegati:

• Throughput (richieste/secondo) in aumento può aumentare la coda, che aumenta la latenza.
• Errori possono ridurre la latenza osservata (fallimenti rapidi) o aumentarla (retry e timeout).
• Limitare il throughput (rate limit, backpressure) può migliorare la latenza di coda pur facendo fallire più richieste.

Prima di ottimizzare, cattura tutti e tre per la stessa finestra temporale. Altrimenti potresti “risolvere” la latenza eliminando lavoro o facendo fallire più rapidamente.

Non fidarti delle medie: percentili e latenza di coda

La latenza media nasconde i picchi che gli utenti ricordano. Un servizio con una media di 50 ms può comunque avere frequenti stall da 2 s.

Monitora i percentili:

• p50: esperienza tipica dell'utente
• p95/p99: latenza di coda (dove vive la maggior parte del dolore degli incidenti)

Osserva anche la forma della latenza: un p50 stabile con p99 in aumento spesso indica stall intermittenti (per esempio contesa su lock, problemi I/O, pause stop-the-world) piuttosto che un rallentamento generale.

Budget di latenza: dove può andare il tempo

Un budget di latenza è un modello di rendiconto semplice: “se la richiesta deve finire in 300 ms, come può essere speso quel tempo?” Scomponilo in cassette come:

• tempo nel tuo servizio (calcolo + attesa)
• tempo in servizi a valle
• tempo in database/cache
• transito di rete e TLS
• tempo in coda (thread, pool di connessioni, load balancer)

Questo budget inquadra il primo compito di misura: identifica quale bucket è cresciuto durante il picco, quindi indaga quella area invece di ottimizzare alla cieca.

Parti da una domanda e un ambito chiari

Il lavoro sulla latenza deraglia quando il “problema” è descritto come il sistema è lento. I metodi di Gregg partono prima: costringono a trasformare il problema in una domanda specifica e verificabile.

Definisci cosa significa “lento” (e per chi)

Scrivi due frasi prima di toccare strumenti:

• Cosa è lento? (caricamento pagina, endpoint API, job batch, login, checkout, una query SQL specifica)
• Dove è osservato il rallentamento? (browser cliente, app mobile, una regione, un pod, un host, un servizio interno)

Questo evita di ottimizzare lo strato sbagliato — per esempio la CPU dell'host — quando il dolore è isolato a un endpoint o a una dipendenza a valle.

Scegli una finestra temporale e l'ambito

Scegli una finestra che corrisponda al reclamo e includa, se possibile, un periodo di confronto “buono”.

Definisci esplicitamente l'ambito dell'indagine:

• Host vs servizio vs endpoint: “un nodo Kubernetes” è diverso da “una route API”.
• Quale fetta di traffico: regione, tier di clienti, solo richieste in errore o tutte le richieste.
• Quale segnale ha guidato il report: p95 latency, timeout, profondità delle code o metriche utente.

Essere precisi qui rende i passi successivi (USE, RED, profiling) più veloci perché saprai quali dati dovrebbero cambiare se la tua ipotesi è corretta.

Tratta i cambi recenti come ipotesi, non come risposte

Annota deploy, cambi di configurazione, shift di traffico ed eventi infrastrutturali—ma non presumere causalità. Scrivili come “Se X, allora ci aspetteremmo Y”, così puoi confermare o rifiutare rapidamente.

Tieni un registro leggero dell'indagine

Un piccolo registro evita lavoro duplicato tra i membri del team e rende i passaggi più semplici da trasferire.

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

Anche cinque righe come queste possono trasformare un incidente stressante in un processo ripetibile.

Il metodo USE: inventario rapido delle risorse

Il Metodo USE (Utilization, Saturation, Errors) è la checklist rapida di Gregg per scandagliare le “quattro grandi” risorse — CPU, memoria, disco (storage) e rete — così puoi smettere di indovinare e iniziare a restringere il problema.

Cos'è: una checklist per risorsa

Invece di fissare decine di dashboard, poni le stesse tre domande per ogni risorsa:

• Utilization: quanto è occupata in questo momento?
• Saturation: il lavoro si accumula (code, tempo di attesa), anche se l'utilizzo non è al massimo?
• Errors: sta fallendo o ritentando in modi che generano ritardi?

Applicato con costanza, diventa un inventario rapido di dove esiste “pressione”.

Come applicarlo nella pratica

Per la CPU, utilization è la percentuale di CPU occupata, saturation appare come pressione della run-queue o thread in attesa di esecuzione, e gli errori possono includere throttling (nelle container) o interrupt mal gestiti.

Per la memoria, utilization è memoria usata, saturation si manifesta come paging o garbage collection frequente, e gli errori includono fallimenti di allocazione o eventi OOM.

Per il disco, utilization è il tempo device busy, saturation è la profondità della coda e il tempo di attesa read/write, e gli errori sono I/O error o timeout.

Per la rete, utilization è throughput, saturation sono drop/code/latenza, e gli errori sono retransmit, reset o perdita di pacchetti.

I segnali più utili durante incidenti di latenza

Quando gli utenti segnalano lentezza, i segnali di saturation sono spesso i più rivelatori: code, tempo di attesa e contesa tendono a correlare più direttamente con la latenza rispetto al solo utilizzo.

USE integra le metriche di servizio (non le sostituisce)

Le metriche a livello di servizio (come latenza delle richieste e tasso di errore) ti dicono impatto. USE ti dice dove guardare dopo identificando quale risorsa soffre.

Un ciclo pratico è:

1. Conferma l'impatto utente (Duration/Errori)
2. Esegui l'inventario USE
3. Approfondisci la risorsa sospetta con strumenti più dettagliati (profiling, trace, statistiche kernel)

Il metodo RED: segnali servizio‑centrati che indicano impatto

Il metodo RED ti tiene ancorato all'esperienza utente prima di tuffarti nei grafici host.

• Rate: quante richieste al secondo gestisce il tuo servizio o endpoint
• Errors: quante richieste falliscono (e cosa significa “fallire” per la tua app)
• Duration: quanto durano le richieste riuscite (tracciate come percentili, non medie)

Perché RED aiuta a dare priorità

RED ti impedisce di inseguire metriche di sistema “interessanti” che non impattano gli utenti. Ti forza a un ciclo più stretto: quale endpoint è lento, per quali utenti e da quando? Se Duration sale solo su una route mentre la CPU globale è piatta, hai già un punto di partenza più preciso.

Una buona abitudine: mantieni RED suddiviso per servizio e endpoint principali (o RPC chiave). Così distingui facilmente un degrado ampio da una regressione localizzata.

Mappare i sintomi RED ai controlli USE

RED ti dice dove fa male. USE ti aiuta a testare quale risorsa è responsabile.

Esempi:

• Duration in aumento + Rate stabile → controlla saturazione/code: run queue della CPU, latenza dello storage, pool di connessioni DB.
• Errors in aumento + Duration in aumento → controlla timeout e retry: downstream sovraccarichi, pool di thread, drop di rete.
• Rate in aumento + Duration in aumento → controlla limiti di capacità: utilizzo CPU, comportamento del load balancer, ritardi nell'autoscaling.

Un dashboard minimale “what changed?”

Mantieni il layout focalizzato:

1. Panoramica RED: Rate, Errori e p50/p95/p99 Duration per il servizio.
2. Top endpoints: stessi segnali RED per endpoint, ordinati per traffico o peggior p95.
3. Dipendenze: pannelli in stile RED per i principali downstream (DB, cache, API esterne).
4. Una riga di correlazione: un piccolo set di metriche di sistema (CPU, pressione memoria, latenza I/O, retransmit di rete) per accelerare il passaggio dalla vista servizio al testing della causa radice.

Se vuoi un workflow di incidente coerente, abbina questa vista all'inventario USE in /blog/use-method-overview così puoi passare da “gli utenti lo percepiscono” a “questa risorsa è il vincolo” con meno caos.

Prioritizzazione: scegli la prossima domanda più utile

Un'indagine sulle prestazioni può esplodere in decine di grafici e ipotesi in pochi minuti. La mentalità di Gregg è mantenerla ristretta: il tuo lavoro non è “raccogliere più dati”, ma porre la prossima domanda che elimina più rapidamente l'incertezza.

La regola 80/20 per i colli di bottiglia

La maggior parte dei problemi di latenza è dominata da un singolo costo (o da una coppia): un lock caldo, una dipendenza lenta, un disco sovraccarico, un pattern di pause GC. Prioritizzare significa cercare prima quel costo dominante, perché ridurre del 5% cinque parti diverse difficilmente migliora la latenza percepita.

Una prova pratica: “Cosa potrebbe spiegare la maggior parte della variazione di latenza che vediamo?” Se un'ipotesi ne spiega solo una piccola fetta, è di bassa priorità.

Top-down vs bottom-up: dove iniziare

Usa un approccio top-down quando devi rispondere “Gli utenti sono impattati?” Parti dagli endpoint (segnali in stile RED): latenza, throughput, errori. Questo evita di ottimizzare qualcosa che non è sul percorso critico.

Usa un approccio bottom-up quando l'host è chiaramente malato (sintomi USE): CPU satura, memoria fuori controllo, I/O atteso. Se un nodo è bloccato, perderai tempo a guardare percentili di endpoint senza capire il vincolo.

Un semplice albero decisionale per evitare confusione

Quando scatta un alert, scegli un ramo e resta su quello finché non lo confermi o lo scarti:

• Picco di latenza + picco di errori → “È una dipendenza o un evento di capacità?” (timeout, esaurimento pool di connessioni, downstream 5xx)
• Picco di latenza + picco di CPU → “La CPU sta facendo lavoro utile o è bloccata?” (on-CPU vs off-CPU)
• Picco di latenza + alto I/O wait → “Quale device o filesystem è in coda?”
• Picco di latenza senza spike di risorse → “Dove si spende il tempo in attesa?” (lock, scheduler, rete, chiamate remote)

Evita l'overload di metriche, resta sistematico

Limitati a un piccolo set iniziale di segnali, poi approfondisci solo quando qualcosa si muove. Se ti serve una checklist per mantenere il focus, collega i passi a un runbook come /blog/performance-incident-workflow così ogni nuova metrica ha uno scopo: rispondere a una domanda specifica.

Profiling in produzione senza fermare il sistema

Il profiling in produzione può sembrare rischioso perché tocca il sistema live — ma spesso è il modo più veloce per sostituire il dibattito con l'evidenza. Log e dashboard possono dirti che qualcosa è lento. Il profiling ti dice dove va il tempo: quali funzioni sono calde, quali thread aspettano e quali percorsi di codice dominano durante l'incidente.

Cosa risponde realmente il profiling

Il profiling è uno strumento di “budget del tempo”. Invece di dibattere teorie (“è il database” vs “è il GC”), ottieni evidenze come “il 45% dei campioni CPU era nel parsing JSON” o “la maggior parte delle richieste è bloccata su un mutex”. Questo restringe il passo successivo a una o due correzioni concrete.

Tipi comuni utilizzabili in produzione

• CPU profiling: mostra quale codice sta eseguendo on-CPU.
• Off-CPU (wait) profiling: mostra dove i thread passano tempo bloccati (attese I/O, scheduler, sleep, rete, disco).
• Lock profiling: mostra la contesa — tempo perso in attesa di lock, mutex e latch read/write.

Ognuno risponde a una domanda diversa. Alta latenza con poca CPU spesso indica off-CPU o contesa di lock piuttosto che hotspot CPU.

Always-on vs on-demand

• Profiling always-on (continuo, basso overhead) aiuta per misteri “è successo alle 3 di notte” perché puoi guardare indietro.
• Profiling on-demand è una cattura mirata durante un picco. È più semplice da adottare, ma devi essere pronti a attivarlo rapidamente.

Molti team partono on-demand, poi passano al always-on quando si fidano della sicurezza e vedono problemi ricorrenti.

Sicurezza: overhead, campionamento e finestre brevi

Il profiling sicuro in produzione riguarda il controllo del costo. Preferisci il campionamento (non tracciare ogni evento), mantieni le finestre di cattura brevi (per esempio 10–30 secondi) e misura l'overhead in un canary prima. Se sei insicuro, parti con campionamento a bassa frequenza e aumenta solo se il segnale è troppo rumoroso.

Flame graphs: come leggerli ed evitare conclusioni errate

I flame graph visualizzano dove il tempo campionato è andato durante una finestra di profiling. Ogni “box” è una funzione (o frame di stack) e ogni stack mostra come l'esecuzione è arrivata a quella funzione. Sono eccellenti per individuare pattern rapidamente — ma non dicono automaticamente “qui c'è il bug”.

Cosa mostra (e cosa non mostra) un flame graph

Un flame graph rappresenta di solito campioni on-CPU: tempo in cui il programma stava effettivamente girando su un core. Può evidenziare percorsi CPU-costosi, parsing inefficiente, serializzazione e hotspot che consumano CPU.

Non mostra direttamente attese su disco, rete, scheduler o tempo bloccato su mutex (quello è off-CPU e richiede profiling diverso). Non prova neppure la causalità rispetto alla latenza utente a meno che non lo leghi a una domanda circoscritta.

Larghezza e profondità dello stack

• Larghezza: quante volte quel frame è apparso nei campioni. Più ampio significa di solito “più tempo CPU”, ma sempre dentro la finestra scelta.
• Profondità dello stack: profondità di chiamata. Stack profondi non sono intrinsecamente cattivi; importa quali percorsi dominano e se corrispondono al lavoro che ti interessa.

Trappole comuni da evitare

La box più larga è tentante da incolpare, ma chiediti: è uno hotspot che puoi cambiare o solo “tempo speso in malloc, GC o logging” perché il vero problema è a monte? Fai attenzione anche al contesto mancante (JIT, inlining, simboli) che può far sembrare una box colpevole quando è solo il messaggero.

Abbina i flame graph a una domanda precisa

Tratta un flame graph come risposta a una domanda circoscritta: quale endpoint, quale finestra temporale, quali host e cosa è cambiato. Confronta flame graph “prima vs dopo” (o “sano vs degradato”) per lo stesso percorso di richiesta per evitare rumore di profiling.

Off-CPU: la fonte nascosta della latenza

Quando la latenza sale, molti team guardano prima la CPU%. È comprensibile — ma spesso porta nella direzione sbagliata. Un servizio può avere “solo il 20% di CPU” e risultare comunque dolorosamente lento se i suoi thread passano la maggior parte del tempo a non essere in esecuzione.

Perché la sola CPU% inganna

La CPU% risponde a “quanto è impegnato il processore?” Non risponde a “dove è andato il tempo della mia richiesta?” Le richieste possono bloccarsi mentre i thread aspettano, sono bloccati o parcheggiati dallo scheduler.

Un'idea chiave: il tempo di muro di una richiesta include sia lavoro on-CPU sia attese off-CPU.

Colpevoli comuni dell'off-CPU

Il tempo off-CPU spesso si nasconde dietro dipendenze e contese:

• I/O disco: letture/scritture sincrone, fsync, storage lento, miss della page cache.
• Attese di rete: lookup DNS, retransmit TCP, upstream sovraccarichi.
• Contesa di lock e mutex: thread bloccati su lock, reader/writer lock, contesa sull'allocatore.
• Queueing: attesa in thread pool, pool di connessioni o code interne.

Sintomi da osservare

Alcuni segnali correlano spesso a colli off-CPU:

• aumento del tempo in coda (richieste in attesa prima di iniziare)
• crescita dei thread runnable (più competizione per la CPU)
• aumento di I/O wait e latenza disco/rete più lunga

Questi sintomi dicono “stiamo aspettando”, ma non cosa stiamo aspettando.

Come il profiling off-CPU mostra “dove è andato il tempo”

Il profiling off-CPU attribuisce tempo al motivo per cui non stavamo girando: bloccati in syscall, in attesa di lock, in sleep o deschedulati. Questo è potente per la latenza perché trasforma rallentamenti vaghi in categorie azionabili: “bloccato su mutex X”, “in attesa di read() dal disco” o “impantanato in connect() verso un upstream”. Una volta che puoi nominare l'attesa, puoi misurarla, confermarla e correggerla.

Conferma il collo di bottiglia con evidenze, non con intuizioni

Il lavoro sulle prestazioni fallisce spesso nello stesso punto: qualcuno vede una metrica sospetta, la dichiara “il problema” e inizia a tuning. I metodi di Gregg ti spingono a rallentare e provare cosa limita il sistema prima di cambiare qualsiasi cosa.

Collo di bottiglia, hot spot e rumore

Un collo di bottiglia è la risorsa o componente che attualmente limita il throughput o guida la latenza. Se lo allevi, gli utenti vedranno miglioramento.

Un hot spot è dove si spende tempo (per esempio una funzione che appare spesso in un profilo). Gli hotspot possono essere veri colli di bottiglia — oppure semplice lavoro che non impatta il percorso lento.

Il rumore è tutto ciò che sembra significativo ma non lo è: job in background, picchi isolati, artefatti di campionamento, effetti di cache o “top talkers” che non correlano col problema visibile all'utente.

Dimostralo con confronti e cambi controllati

Inizia catturando un clean prima: il sintomo utente (latenza o error rate) e i segnali principali sospetti (saturazione CPU, profondità code, I/O disco, contesa lock, ecc.). Poi applica un cambiamento controllato che dovrebbe influenzare solo la causa sospettata.

Esempi di test causali:

• Aggiungi capacità alla risorsa sospettata (un worker in più, più CPU share, pool di connessioni più grande) e verifica se la latenza migliora.
• Riduci temporaneamente la domanda (limitando un endpoint rumoroso, riproducendo un carico più piccolo) e vedi se il vincolo si allenta.

La correlazione è un indizio, non una sentenza. Se “la CPU sale quando la latenza sale”, verifica cambiando la disponibilità CPU o riducendo il lavoro CPU e osserva se la latenza segue.

Documenta ciò che hai dimostrato

Annota: cosa è stato misurato, la modifica esatta fatta, i risultati prima/dopo e il miglioramento osservato. Questo trasforma un successo isolato in un playbook riutilizzabile per il prossimo incidente — e impedisce che l’intuizione riscriva la storia dopo l'evento.

Costruisci un workflow ripetibile per gli incidenti di performance

Gli incidenti prestazionali sembrano urgenti, ed è proprio allora che la supposizione si insinua. Un workflow leggero e ripetibile aiuta a passare da “qualcosa è lento” a “sappiamo cosa è cambiato” senza troppa confusione.

Il loop dell'incidente: rileva → triage → misura → correggi

Rileva: allerta su latenza ed errori visibili all'utente, non solo su CPU. Avvisa quando p95/p99 supera una soglia per un intervallo sostenuto.

Triage: rispondi subito a tre domande: cosa è lento, quando è cominciato e chi è impattato? Se non riesci a nominare l'ambito (servizio, endpoint, regione, coorte), non sei pronto per ottimizzare.

Misura: raccogli evidenze che restringano il collo di bottiglia. Preferisci catture a tempo (es. 60–180 secondi) per poter confrontare “male” vs “bene”.

Correggi: cambia una cosa per volta, poi misura gli stessi segnali per confermare il miglioramento e scartare l'effetto placebo.

Standardizza un piccolo set di grafici

Mantieni una dashboard condivisa che tutti usano durante gli incidenti. Rendila noiosa e coerente:

• Latenza: p50 / p95 / p99 (per endpoint critici)
• Segnali RED: Rate, Errors, Duration (vista servizio-centrica)
• Alcuni metriche USE: utilization, saturation, errors per CPU, disco e rete

L'obiettivo non è disegnare tutto; è accorciare il tempo per ottenere il primo fatto.

Definisci i “golden signals” per endpoint critici

Instrumenta gli endpoint che contano davvero (checkout, login, search), non ogni singolo endpoint. Per ciascuno, concorda: p95 atteso, tasso massimo di errori e dipendenza chiave (DB, cache, terze parti).

Decidi cosa catturare durante gli incidenti

Prima del prossimo outage, concorda un kit di cattura:

• Profili (CPU e off-CPU), più flame graph
• Tracce per gli endpoint lenti
• Log per errori/timeout (sampled)

Documentalo in un runbook breve (es., /runbooks/latency), includendo chi può attivare le catture e dove conservare gli artifact.

Dove si inserisce Koder.ai in un workflow alla Gregg

La metodologia di Gregg è fondamentalmente su cambi controllati e verifica rapida. Se il tuo team costruisce servizi con Koder.ai (una piattaforma chat-driven per generare e iterare app web, backend e mobile), due feature si allineano bene con questa mentalità:

• Planning Mode ti aiuta a trasformare “forse è X” in un'ipotesi esplicita e un piccolo set di modifiche testabili prima di toccare la produzione.
• Snapshots and rollback permettono esperimenti sicuri a variabile singola: applica una modifica, misura RED/USE e rollback rapido se l'evidenza dice “no”.

Anche se non stai generando nuovo codice durante un incidente, quelle abitudini — diff piccoli, risultati misurabili e rapida reversibilità — sono le stesse che Gregg promuove.

Una walkthrough pratica: dal picco di latenza al fix verificato

Lo scenario: p99 sale nel picco di traffico

Sono le 10:15 e la dashboard mostra p99 dell'API che passa da ~120 ms a ~900 ms durante il picco. Il tasso di errore è stabile, ma i clienti segnalano richieste “lente”.

Passo 1 — Parti da RED per trovare l'impatto utente

Inizia servizio-centrico: Rate, Errors, Duration.

Fetta la Duration per endpoint e vedi che una route domina il p99: POST /checkout. Il rate è salito di 2×, gli errori sono normali, ma la Duration sale specificamente quando aumenta la concurrency. Questo punta a code o contesa, non a un fallimento totale.

Controlla se la latenza è tempo di calcolo o di attesa: confronta il “handler time” dell'app vs il tempo totale (o span upstream vs downstream se hai tracing). L'handler è basso, il tempo totale è alto — le richieste stanno aspettando.

Passo 2 — Applica USE ai host sospetti

Fai l'inventario delle probabili risorse: Utilization, Saturation, Errors per CPU, memoria, disco e rete.

La CPU è solo ~35%, ma la run queue e i context switch aumentano. Disco e rete sembrano stabili. Questo mismatch (bassa CPU%, alta attesa) è un indizio classico: i thread non stanno consumando CPU — sono bloccati.

Passo 3 — Scegli il profiling in base ai sintomi

• Se la CPU è alta: usa CPU profiling (flame graph on-CPU) per vedere dove si spende il tempo.
• Se le richieste stanno aspettando: usa off-CPU profiling per vedere su cosa i thread sono bloccati (lock, I/O, scheduler).

Catturi un profilo off-CPU durante il picco e trovi molto tempo speso in un mutex attorno a una cache condivisa di “promotion validation”.

Passo 4 — Correggi e verifica

Sostituisci il lock globale con un lock per chiave (o un percorso di lettura lock-free), deploy e osservi il p99 tornare ai livelli normali mentre il Rate resta alto.

Checklist post-incident:

• Registra i sintomi RED esatti e l'endpoint ristretto.
• Salva il profilo e la finestra temporale.
• Aggiungi un alert per il segnale di saturazione specifico (es., attesa su lock / run queue).
• Scrivi la “prossima domanda” se succede di nuovo.