Métodos de Desempenho de Brendan Gregg para Latência e Perfilagem

Por que a abordagem de Brendan Gregg reduz suposições

Brendan Gregg é uma das vozes mais influentes em desempenho de sistemas, especialmente no universo Linux. Ele escreveu livros amplamente usados, criou ferramentas práticas e — mais importante — compartilhou métodos claros para investigar problemas reais em produção. Equipes adotam sua abordagem porque funciona sob pressão: quando a latência sobe e todo mundo quer respostas, você precisa de um jeito de ir de “talvez seja X” para “é definitivamente Y” com o mínimo de drama.

O que “metodologia de desempenho” realmente significa

Uma metodologia de desempenho não é uma única ferramenta ou um comando esperto. É uma forma repetível de investigar: um checklist do que olhar primeiro, como interpretar o que aparece e como decidir o próximo passo.

Essa repetibilidade é o que reduz suposições. Em vez de depender de quem tem mais intuição (ou da opinião mais alta), você segue um processo consistente que:

• reduz o problema a um recurso, serviço ou caminho de código específico
• mede o que está acontecendo na mesma janela de tempo do incidente
• confirma o gargalo com evidência antes de fazer mudanças

O modo comum de falha: consertar antes de medir

Muitas investigações de latência dão errado nos primeiros cinco minutos. As pessoas pulam direto para correções: “adicione CPU”, “reinicie o serviço”, “aumente o cache”, “ajuste a GC”, “deve ser a rede”. Às vezes essas ações ajudam — frequentemente elas escondem o sinal, desperdiçam tempo ou introduzem novo risco.

Os métodos do Gregg empurram você a atrasar as “soluções” até responder perguntas mais simples: O que está saturado? O que está gerando erros? O que ficou mais lento — throughput, enfileiramento ou operações individuais?

O que este guia ajuda você a fazer

Este guia ajuda a restringir o escopo, medir os sinais certos e confirmar o gargalo antes de otimizar. O objetivo é um fluxo de trabalho estruturado para investigar latência e questões de perfilagem em produção para que os resultados não dependam da sorte.

Noções básicas de latência: o que medir antes de ajustar

Latência é um sintoma: usuários esperam mais tempo pelo término de um trabalho. A causa geralmente está em outro lugar — contenção de CPU, esperas em disco ou rede, contenção de locks, coleta de lixo, enfileiramento ou atrasos em dependências remotas. Medir apenas a latência diz que a dor existe, não de onde ela se origina.

Throughput, latência e erros andam juntos

Esses três sinais são acoplados:

• Throughput (requisições/segundo) subindo pode aumentar o enfileiramento, o que aumenta a latência.
• Erros podem reduzir a latência observada (falhas rápidas) ou aumentá-la (retries e timeouts).
• Limitar o throughput (rate limits, backpressure) pode melhorar a latência de cauda enquanto faz menos requisições terem sucesso.

Antes de ajustar, capture os três no mesmo intervalo de tempo. Caso contrário, você pode “resolver” a latência derrubando trabalho ou fazendo falhar mais rápido.

Não confie em médias: percentis e latência de cauda

A latência média esconde picos que os usuários lembram. Um serviço com média de 50 ms pode ter stalls frequentes de 2 s.

Monitore percentis:

• p50: experiência típica do usuário
• p95/p99: latência de cauda (onde mora a maior parte da dor em incidentes)

Observe também a forma da latência: um p50 estável com p99 subindo frequentemente indica stalls intermitentes (por exemplo, contenção de locks, hiccups de I/O, pausas stop-the-world) em vez de uma lentidão geral.

Orçamentos de latência: onde o tempo pode ser gasto

Um orçamento de latência é um modelo simples de contabilidade: “Se a requisição precisa terminar em 300 ms, como esse tempo pode ser gasto?” Divida em buckets como:

• tempo no seu serviço (cálculo + espera)
• tempo em serviços downstream
• tempo em bancos de dados/caches
• trânsito de rede e TLS
• tempo enfileirado (threads, pools de conexão, load balancers)

Esse orçamento orienta a primeira tarefa de medição: identifique qual bucket cresceu durante o pico e investigue essa área em vez de ajustar às cegas.

Comece com uma pergunta clara e escopo

O trabalho de latência saí do rumo quando o “problema” é descrito como o sistema está lento. Os métodos do Gregg começam antes: force a questão a uma pergunta específica e testável.

Defina o que “lento” significa (e para quem)

Anote duas frases antes de tocar em qualquer ferramenta:

• O que está lento? (carregamento de página, endpoint da API, job em lote, login, checkout, uma query SQL específica)
• Onde a lentidão é observada? (navegador do cliente, app móvel, uma região, um pod, um host, um serviço interno)

Isso evita otimizar a camada errada — por exemplo, CPU do host — quando a dor está isolada a um endpoint ou a uma dependência downstream.

Escolha uma janela de tempo e um escopo

Escolha uma janela que bata com a queixa e inclua um período de comparação “bom”, se possível.

Defina explicitamente o escopo da investigação:

• Host vs. serviço vs. endpoint: “Um nó Kubernetes” é diferente de “uma rota de API”.
• Qual fatia de tráfego: região, tier de cliente, apenas requisições com erro ou todas as requisições.
• Qual sinal gerou o relatório: p95, timeouts, profundidade da fila ou user timing.

Ser preciso aqui torna os passos seguintes (USE, RED, perfilagem) mais rápidos porque você saberá quais dados devem mudar se sua hipótese estiver certa.

Trate mudanças recentes como hipóteses, não respostas

Anote deploys, mudanças de configuração, shifts de tráfego e eventos de infraestrutura — mas não assuma causalidade. Escreva-os como “Se X, então esperaríamos Y”, para que você possa confirmar ou rejeitar rapidamente.

Mantenha um registro leve da investigação

Um pequeno log evita trabalho duplicado entre colegas e facilita handoffs.

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

Mesmo cinco linhas como essa podem transformar um incidente estressante em um processo repetível.

O Método USE: um inventário rápido de gargalos de recurso

O Método USE (Utilization, Saturation, Errors) é o checklist rápido do Gregg para escanear os “quatro grandes” recursos — CPU, memória, disco (armazenamento) e rede — para que você pare de adivinhar e comece a estreitar o problema.

O que é: um checklist por recurso

Em vez de olhar dezenas de dashboards, faça as mesmas três perguntas para cada recurso:

• Utilização: quão ocupado está agora?
• Saturação: o trabalho está se acumulando (filas, tempo de espera), mesmo que a utilização não esteja no máximo?
• Erros: está falhando ou fazendo retries de forma que cria atraso?

Aplicado de forma consistente, isso vira um inventário rápido de onde existe “pressão”.

Como aplicar na prática

Para CPU, utilização é % de CPU ocupado, saturação aparece como pressão na run-queue ou threads esperando para rodar, e erros podem incluir throttling (em containers) ou interrupts mal comportados.

Para memória, utilização é memória usada, saturação frequentemente aparece como paginação ou coleta de lixo frequente, e erros incluem falhas de alocação ou eventos OOM.

Para disco, utilização é tempo de dispositivo ocupado, saturação é profundidade de fila e tempo de espera de leitura/gravação, e erros são erros de I/O ou timeouts.

Para rede, utilização é throughput, saturação são drops/filas/latência, e erros são retransmissões, resets ou perda de pacotes.

Sinais mais úteis durante incidentes de latência

Quando os usuários reportam lentidão, sinais de saturação costumam ser os mais reveladores: filas, tempo de espera e contenção tendem a correlacionar mais diretamente com latência do que utilização bruta.

USE complementa métricas de serviço (não as substitui)

Métricas em nível de serviço (como latência de requisição e taxa de erro) dizem o impacto. USE diz onde olhar a seguir identificando qual recurso está sob pressão.

Um loop prático é:

1. Confirme o impacto ao usuário (Duração/Erros)
2. Rode o inventário USE
3. Aprofunde no recurso suspeito com ferramentas mais detalhadas (perfis, traces, estatísticas do kernel)

O Método RED: sinais centrados no serviço que apontam para o impacto

O Método RED mantém você ancorado na experiência do usuário antes de mergulhar em gráficos de host.

• Rate: quantas requisições por segundo seu serviço ou endpoint está atendendo
• Errors: quantas requisições estão falhando (e o que “falha” significa para sua app)
• Duration: quanto tempo requisições bem-sucedidas levam (rastreado por percentis, não médias)

Por que RED ajuda a priorizar

RED impede que você persiga métricas de sistema “interessantes” que não afetam os usuários. Força um ciclo mais apertado: qual endpoint está lento, para quais usuários e desde quando? Se a Duration sobe apenas em uma rota enquanto a CPU geral está estável, você já tem um ponto de partida mais afiado.

Um hábito útil: mantenha RED quebrado por serviço e principais endpoints (ou principais métodos RPC). Isso facilita distinguir uma degradação ampla de uma regressão localizada.

Mapeando sintomas RED para checagens USE

RED diz onde dói. USE ajuda a testar qual recurso é responsável.

Exemplos:

• Duration aumenta + Rate estável → verifique saturação/enfileiramento: run queue de CPU, latência de armazenamento, pools de conexão do BD.
• Erros aumentam + Duration aumenta → verifique timeouts e retries: downstreams sobrecarregados, pools de threads, drops de rede.
• Rate aumenta + Duration aumenta → verifique limites de capacidade: utilização de CPU, comportamento do load balancer, atrasos no autoscaling.

Um dashboard mínimo “o que mudou?”

Mantenha o layout focado:

1. Visão RED: Rate, Errors e p50/p95/p99 Duration do serviço.
2. Top endpoints: mesmos sinais RED por endpoint, ordenados por tráfego ou pior p95.
3. Dependências: painéis estilo RED para principais downstreams (BD, cache, APIs externas).
4. Uma linha de correlação: um pequeno conjunto de métricas de sistema (CPU, pressão de memória, latência de I/O de disco, retransmissões de rede) para acelerar a transição da visão de serviço para testes de causa raiz.

Se quiser um fluxo de incidente consistente, emparelhe esta seção com o inventário USE em /blog/use-method-overview para que você possa mover de “os usuários sentem” para “este recurso é a restrição” com menos tração.

Priorização: escolha a próxima melhor pergunta a fazer

Uma investigação de desempenho pode explodir em dezenas de gráficos e hipóteses em minutos. A mentalidade do Gregg é manter estreito: seu trabalho não é “coletar mais dados”, mas fazer a próxima pergunta que elimina incerteza o mais rápido possível.

A regra 80/20 para gargalos

A maioria dos problemas de latência é dominada por um único custo (ou um pequeno par): um lock quente, uma dependência lenta, um disco sobrecarregado, um padrão de pausa de GC. Priorizar significa caçar esse custo dominante primeiro, porque reduzir 5% em cinco lugares raramente muda a latência visível ao usuário.

Um teste prático: “O que poderia explicar a maior parte da mudança de latência que estamos vendo?” Se uma hipótese só explica uma fatia pequena, é uma pergunta de menor prioridade.

Top-down vs. bottom-up: onde começar

Use top-down quando estiver respondendo “Os usuários estão impactados?” Comece por endpoints (sinais estilo RED): latência, throughput, erros. Isso evita otimizar algo que não está no caminho crítico.

Use bottom-up quando o host estiver claramente doente (sintomas estilo USE): saturação de CPU, pressão de memória fora de controle, I/O elevado. Se um nó está no limite, você vai perder tempo olhando percentis de endpoint sem entender a restrição.

Uma árvore de decisão simples que previne thrash

Quando um alerta dispara, escolha um ramo e mantenha-se nele até confirmar ou falsificar:

• Pico de latência + pico de erros → “Isso é um evento de dependência ou de capacidade?” (timeouts, exaustão de pools de conexão, 5xx downstream)
• Pico de latência + pico de CPU → “A CPU está fazendo trabalho útil ou está travada?” (on-CPU vs off-CPU)
• Pico de latência + alto I/O wait → “Qual dispositivo ou fila de sistema de arquivos está enfileirando?”
• Pico de latência sem picos de recurso → “Onde o tempo está sendo gasto esperando?” (locks, escalonador, rede, chamadas remotas)

Evite sobrecarga de métricas, mantenha-se sistemático

Limite-se a um pequeno conjunto inicial de sinais e aprofunde apenas quando algo se mover. Se precisar de um checklist para manter o foco, vincule seus passos a um runbook como /blog/performance-incident-workflow para que cada nova métrica tenha um propósito: responder a uma pergunta específica.

Perfilagem em produção sem derrubar o sistema

Perfilagem em produção pode parecer arriscada porque toca o sistema vivo — mas frequentemente é a via mais rápida para trocar debate por evidência. Logs e dashboards podem dizer que algo está lento. Perfilagem diz onde o tempo vai: quais funções estão quentes, quais threads esperam e quais caminhos de código dominam durante o incidente.

O que a perfilagem realmente responde

Perfilagem é uma ferramenta de “orçamento de tempo”. Em vez de debater teorias (“é o banco de dados” vs “é a GC”), você obtém evidência como “45% das amostras de CPU estavam em parsing de JSON” ou “a maioria das requisições está bloqueada em um mutex”. Isso restringe o próximo passo a uma ou duas correções concretas.

Tipos comuns que se pode usar em produção

• Perfilagem de CPU: mostra qual código está sendo executado on-CPU.
• Perfilagem off-CPU (wait): mostra onde threads passam tempo bloqueadas (esperas de I/O, atrasos do escalonador, sleep, rede, disco).
• Perfilagem de locks: mostra contenção — tempo perdido esperando locks, mutexes e travas de leitura/escrita.

Cada uma responde a uma pergunta diferente. Latência alta com CPU baixa frequentemente aponta para off-CPU ou contenção de locks em vez de pontos quentes de CPU.

Sempre ligado vs on-demand

• Perfilagem sempre ligada (contínua, baixo overhead) ajuda mistérios de “aconteceu às 3h” porque você pode olhar para trás.
• Perfilagem on-demand é uma captura direcionada durante um pico. É mais simples de adotar, mas você precisa estar pronto para dispará-la rapidamente.

Muitas equipes começam on-demand e depois migram para sempre ligado quando confiam na segurança e veem issues recorrentes.

Segurança: overhead, amostragem e janelas curtas

Perfilagem segura em produção é sobre controlar custo. Prefira amostragem (não trace cada evento), mantenha janelas de captura curtas (por exemplo, 10–30 segundos) e meça overhead em um canário primeiro. Se estiver em dúvida, comece com amostragem de baixa frequência e aumente só se o sinal estiver muito ruidoso.

Flame graphs: como lê-los e evitar conclusões erradas

Flame graphs visualizam onde o tempo amostrado foi durante uma janela de perfilagem. Cada “caixa” é uma função (ou frame de pilha), e cada pilha mostra como a execução chegou nessa função. Eles são excelentes para identificar padrões rapidamente — mas não dizem automaticamente “o bug está aqui”.

O que um flame graph mostra (e o que não mostra)

Um flame graph normalmente representa amostras on-CPU: tempo em que o programa realmente rodou em um core de CPU. Pode destacar caminhos de código que queimam CPU, parsing ineficiente, serialização excessiva ou hotspots que realmente consomem CPU.

Não mostra diretamente espera em disco, rede, atrasos do escalonador ou tempo bloqueado em um mutex (isso é off-CPU e precisa de outro tipo de perfilagem). Também não prova causalidade para latência percebida pelo usuário a menos que você conecte à uma questão bem delimitada.

Largura e profundidade de pilha

• Largura: com que frequência aquele frame apareceu nas amostras. Mais largo geralmente significa “mais tempo de CPU”, mas somente dentro da janela de tempo escolhida.
• Profundidade de pilha: profundidade de chamadas. Pilhas profundas não são inerentemente ruins; o que importa é quais caminhos dominam e se correspondem ao trabalho que você se importa.

Armadilhas comuns a evitar

A caixa mais larga é tentadora para culpar, mas pergunte: é um hotspot que você pode mudar ou apenas “tempo gasto em malloc, GC ou logging” porque o problema real está mais acima na cadeia? Também fique atento a contexto faltante (JIT, inlining, símbolos) que pode fazer uma caixa parecer culpada quando ela é só mensageira.

Emparelhe flame graphs com uma pergunta precisa

Trate um flame graph como resposta a uma pergunta delimitada: qual endpoint, qual janela de tempo, quais hosts e o que mudou. Compare flame graphs “antes vs depois” (ou “saudável vs degradado”) para o mesmo caminho de requisição para evitar ruído de perfilagem.

Tempo off-CPU: a fonte oculta de latência

Quando a latência dispara, muitas equipes olham para %CPU primeiro. Isso é compreensível — mas frequentemente aponta na direção errada. Um serviço pode estar “com só 20% de CPU” e ainda assim ser dolorosamente lento se suas threads passam a maior parte do tempo não rodando.

Por que só o %CPU engana

%CPU responde “quão ocupado está o processador?” Não responde “onde foi o tempo da minha requisição?” Requisições podem travar enquanto threads estão esperando, bloqueadas ou estacionadas pelo escalonador.

Uma ideia chave: o tempo de relógio de uma requisição inclui tanto trabalho on-CPU quanto espera off-CPU.

Causas comuns de off-CPU

Tempo off-CPU tipicamente esconde dependências e contenção:

• I/O de disco: leituras/gravações síncronas, fsyncs, armazenamento lento, misses de page cache.
• Espera de rede: resoluções DNS, retransmissões TCP, services upstream sobrecarregados.
• Locks e contenção de mutexes: threads bloqueadas em locks, travas leitor/escritor, contenção do alocador.
• Enfileiramento: esperando em pools de threads, pools de conexão ou filas internas de trabalho.

Sintomas a observar

Alguns sinais costumam correlacionar com gargalos off-CPU:

• aumento de tempo de fila (requisições aguardando antes mesmo de começar a executar)
• aumento de threads executáveis (mais competição por tempo de CPU)
• elevação de I/O wait e maiores latências de disco/rede

Esses sintomas dizem “estamos esperando”, mas não no que estamos esperando.

Como a perfilagem off-CPU mostra “onde o tempo foi”

A perfilagem off-CPU atribui tempo ao motivo pelo qual você não estava rodando: bloqueado em syscalls, esperando locks, dormindo ou desescalonado. Isso é poderoso para trabalho de latência porque transforma lentidões vagas em categorias acionáveis: “bloqueado no mutex X”, “esperando read() do disco” ou “preso em connect() para um upstream”. Uma vez que você consegue nomear a espera, pode medi-la, confirmá-la e corrigi-la.

Confirme o gargalo com evidências, não intuição

O trabalho de desempenho costuma falhar no mesmo momento: alguém vê uma métrica suspeita, declara “isso é o problema” e começa a ajustar. Os métodos do Gregg empurram você a desacelerar e provar o que está limitando o sistema antes de mudar qualquer coisa.

Gargalo, hotspot e ruído

Um gargalo é o recurso ou componente que no momento limita throughput ou dirige a latência. Se você aliviá-lo, os usuários veem melhoria.

Um hotspot é onde o tempo é gasto (por exemplo, uma função que aparece frequentemente em um perfil). Hotspots podem ser gargalos reais — ou apenas trabalho ocupado que não afeta o caminho lento.

Ruído é tudo que parece significativo mas não é: jobs em background, picos isolados, artefatos de amostragem, efeitos de cache ou “top talkers” que não se correlacionam com o problema visível ao usuário.

Prove com comparações e mudança controlada

Comece capturando um snapshot limpo de antes: o sintoma voltado ao usuário (latência ou taxa de erro) e os sinais candidatos principais (saturação de CPU, profundidade de fila, I/O de disco, contenção de locks etc.). Então aplique uma mudança controlada que deva afetar apenas a causa suspeita.

Exemplos de testes causais:

• Adicione capacidade ao recurso suspeito (mais um worker, mais shares de CPU, pool de conexões maior) e verifique se a latência melhora.
• Reduza temporariamente a demanda (limite um endpoint barulhento, reprocesse uma carga menor) e veja se a restrição suspeita relaxa.

Correlação é uma pista, não um veredito. Se “a CPU sobe quando a latência sobe”, verifique mudando a disponibilidade de CPU ou reduzindo trabalho de CPU e observando se a latência acompanha.

Documente o que você provou

Anote: o que foi medido, a mudança exata feita, os resultados antes/depois e a melhoria observada. Isso transforma uma vitória pontual em um playbook reutilizável para o próximo incidente — e evita que “intuição” reescreva a história depois.

Construa um fluxo de trabalho repetível para incidentes de desempenho

Incidentes de desempenho parecem urgentes, e é exatamente quando suposições aparecem. Um fluxo leve e repetível ajuda a ir de “algo está lento” para “sabemos o que mudou” sem thrashing.

O loop de incidente: detectar → triagem → medir → consertar

Detectar: alerte na latência e taxa de erro visíveis aos usuários, não só na CPU. Chame quando p95/p99 cruzarem um limiar por uma janela sustentada.

Triagem: responda imediatamente três perguntas: o que está lento, quando começou e quem está afetado? Se você não consegue nomear o escopo (serviço, endpoint, região, coorte), não está pronto para otimizar.

Medir: colete evidências que estreitem o gargalo. Prefira capturas com limite de tempo (por exemplo, 60–180 segundos) para poder comparar “ruim” vs “bom”.

Consertar: mude uma coisa por vez e então meça os mesmos sinais para confirmar a melhoria e descartar placebo.

Padronize um pequeno conjunto de gráficos

Mantenha um dashboard compartilhado que todos usam durante incidentes. Torne-o entediante e consistente:

• Latência: p50 / p95 / p99 (por endpoint crítico)
• Sinais RED: Rate, Errors, Duration (visão centrada no serviço)
• Alguns métricas USE: utilização, saturação, erros para CPU, disco e rede

O objetivo não é graficar tudo; é encurtar o tempo-para-primeiro-fato.

Defina “sinais dourados” por endpoint crítico

Instrumente os endpoints que importam (checkout, login, busca), não todos os endpoints. Para cada um, concorde em: p95 esperado, taxa máx de erro e dependência chave (BD, cache, terceiro).

Decida o que capturar durante incidentes

Antes do próximo outage, concorde um kit de captura:

• Perfis (CPU e off-CPU), mais flame graphs
• Traces para endpoints lentos
• Logs de erros/timeouts (amostrados)

Documente num runbook curto (por exemplo, /runbooks/latency), incluindo quem pode rodar capturas e onde os artefatos são armazenados.

Onde o Koder.ai se encaixa em um fluxo de trabalho estilo Gregg

A metodologia do Gregg é fundamentalmente sobre mudança controlada e verificação rápida. Se sua equipe constrói serviços usando o Koder.ai (uma plataforma orientada por chat para gerar e iterar apps web, backend e mobile), duas funcionalidades se alinham bem a essa mentalidade:

• Planning Mode ajuda a transformar “talvez seja X” em uma hipótese explícita e um pequeno conjunto de mudanças testáveis antes de tocar a produção.
• Snapshots and rollback suportam experimentos seguros de variável única: aplique uma mudança, re-meça sinais RED/USE e reverta rapidamente se a evidência disser “não”.

Mesmo que você não esteja gerando novo código durante um incidente, esses hábitos — diffs pequenos, resultados mensuráveis e rápida reversibilidade — são os mesmos hábitos que o Gregg promove.

Um walkthrough prático: do pico de latência à correção verificada

O cenário: p99 sobe no pico de tráfego

São 10:15 e seu dashboard mostra p99 da API subindo de ~120ms para ~900ms durante o pico. A taxa de erro está estável, mas clientes relatam requisições “lentas”.

Passo 1 — Comece com RED para achar o impacto ao usuário

Comece centrado no serviço: Rate, Errors, Duration.

Fatie Duration por endpoint e veja uma rota dominando o p99: POST /checkout. A Rate subiu 2×, erros normais, mas a Duration dispara especificamente quando a concorrência aumenta. Isso aponta para enfileiramento ou contenção, não uma falha completa.

Em seguida, verifique se a latência é tempo de computação ou de espera: compare “handler time” da aplicação com o tempo total da requisição (ou spans upstream vs downstream se tiver tracing). O handler time é baixo, o tempo total é alto — requisições estão esperando.

Passo 2 — Aplique USE nos hosts suspeitos

Faça o inventário dos gargalos prováveis: Utilização, Saturação, Erros para CPU, memória, disco e rede.

A utilização de CPU está só em ~35%, mas a run queue e as trocas de contexto sobem. Disco e rede parecem estáveis. Esse desencontro (CPU baixo, espera alta) é uma dica clássica: threads não estão queimando CPU — estão bloqueadas.

Passo 3 — Escolha perfilagem baseada nos sintomas

• Se a CPU está alta: use perfilagem de CPU (flame graphs on-CPU) para ver onde o tempo é gasto.
• Se requisições estão esperando: use perfilagem off-CPU para ver em que threads estão bloqueadas (locks, I/O, escalonador).

Você captura um perfil off-CPU durante o pico e encontra muito tempo em um mutex ao redor de um cache compartilhado de “validação de promoção”.

Passo 4 — Corrija, então verifique

Você substitui o lock global por um lock por chave (ou uma via de leitura sem lock), faz o deploy e observa o p99 voltar ao baseline enquanto a Rate permanece alta.

Checklist pós-incidente:

• Registre os sintomas RED exatos e o endpoint restringido.
• Salve o perfil e a janela de tempo.
• Adicione um alerta para o sinal de saturação específico (por exemplo, espera de lock / run queue).
• Anote a “próxima pergunta a fazer” caso volte a ocorrer.