Encontrando Gargalos

O teste breakpoint terminou: POST /holds mantém o p99 abaixo de 300 ms até cerca de 1 100 requisições por segundo, e a venda precisa de 4 500. E agora? Adicionar pods às cegas pode não mudar nada — ou piorar. Esta página trata do passo entre medir e corrigir: ler os resultados corretamente, localizar o recurso limitante, ver qual código ou consulta o consome e mudar uma coisa por vez até que o gargalo fique onde você quer.

Lendo os resultados

A curva em degraus

Um teste breakpoint que mantém cada taxa por alguns minutos produz um ponto por degrau: carga oferecida, vazão alcançada, p99 e erros. A tabela e o gráfico abaixo são típicos (dados sintéticos com ruído):

Três regiões são visíveis, e cada uma tem um nome que você deve usar nos relatórios:

• Até o joelho (≈ 1 100 req/s): alcançado = oferecido, p99 dentro do SLO. Esta é a capacidade utilizável deste deployment.
• Entre o joelho e o máximo: alcançado ainda ≈ oferecido, mas o p99 quebra o SLO — o sistema está funcionando, só que devagar demais; filas estão se formando.
• Depois do máximo (≈ 1 250 req/s): a vazão alcançada cai enquanto a oferecida continua crescendo, requisições expiram, aparecem erros. O sistema está saturado e, aqui, retrógrado: a sobrecarga o torna menos eficiente (timeouts, retries, comboios de locks).

A capacidade que você reporta é o joelho: "um deployment de inventory com 4 pods sustenta 1 100 reservas/s dentro do SLO; satura em ~1 250 e degrada além disso".

Sintomas e o que geralmente significam

Um catálogo de gargalos comuns

Profiling: de "qual recurso" para "qual código"

As métricas dizem que o inventory passa o tempo esperando ou queimando CPU; um profiler diz qual código faz isso. Profilers modernos são por amostragem: muitas vezes por segundo eles registram a pilha de chamadas de cada thread, e o código que aparece em muitas amostras é para onde vai o tempo. O overhead é baixo o suficiente (tipicamente alguns por cento) para fazer profiling sob carga, até em produção.

Dois tipos de perfil respondem a perguntas diferentes:

• Perfis on-CPU amostram só threads que estão executando. Eles encontram código pesado em CPU — serialização, regexes, hashing, TLS.
• Perfis off-CPU / wall-clock amostram as threads seja lá o que estiverem fazendo, inclusive esperando por locks, sockets e pools. Quando a CPU está baixa mas a latência está alta — o caso comum —, só um perfil wall-clock mostra para onde vai o tempo.

Lendo um flame graph

Um flame graph desenha as pilhas amostradas como caixas aninhadas¹:

• cada caixa é uma função (um frame da pilha); a caixa abaixo dela é quem a chamou;
• a largura é a fração de amostras em que a função estava na pilha — mais larga significa mais tempo;
• o eixo x não é o tempo: os frames são ordenados alfabeticamente para fundir pilhas idênticas;
• procure caixas largas perto do topo (onde o tempo é de fato gasto) e subárvores inesperadamente largas.

Lendo este perfil wall-clock de POST /holds de cima para baixo: quase todo o tempo está dentro de TransactionTemplate.execute — e, dentro dele, um terço das amostras espera em uma leitura de socket dentro de SeatRepository.lockSeats (o banco está nos fazendo esperar por locks de linha), mais de um quarto espera em uma leitura de socket dentro de PricingClient.quote (uma chamada HTTP dentro da transação, segurando a conexão e os locks), e quase um quarto espera em HikariPool.getConnection (esgotamento do pool, causado pelos dois itens anteriores). JSON e logs, os suspeitos de sempre, são fatias finas. Um flame graph de CPU do mesmo serviço teria mostrado principalmente JSON e logs, e apontado para a correção errada.

async-profiler para a JVM

O async-profiler é um profiler por amostragem de baixo overhead para Java que evita o viés de safepoint dos profilers de JVM mais antigos e produz flame graphs diretamente². Ele se acopla a uma JVM em execução:

# distroless images have no shell: attach an ephemeral debug container that shares
# the pod's process namespace, built from an image that contains async-profiler
kubectl debug -it inventory-7f9c-x2k8p --image=<your-debug-image-with-async-profiler> --target=inventory

asprof -d 30 -e cpu   -f /tmp/cpu.html   1    # on-CPU samples, 30 s, JVM is PID 1
asprof -d 30 -e wall  -t -f /tmp/wall.html 1  # wall-clock, split by thread: includes waiting
asprof -d 30 -e lock  -f /tmp/lock.html  1    # contended Java monitors and locks
asprof -d 30 -e alloc -f /tmp/alloc.html 1    # allocation hot spots (GC pressure)

Rode o profiler enquanto o teste de carga está no platô — o perfil de um serviço ocioso só mostra código ocioso. Se perf_events não for permitido no container, -e itimer (ou ctimer) é uma alternativa de amostragem de CPU. O Java Flight Recorder, embutido no JDK, é a alternativa sem ferramenta extra (jcmd 1 JFR.start duration=60s filename=/tmp/inventory.jfr settings=profile); abra a gravação no JDK Mission Control ou converta-a em flame graph com o conversor do async-profiler.

py-spy para Python

O serviço assistant é Python (FastAPI). O py-spy é um profiler por amostragem que lê a memória do interpretador de fora do processo — sem mudar código, sem reiniciar³:

py-spy top    --pid 1                                   # live "top" of Python functions
py-spy record --pid 1 --duration 30 -o cpu.svg          # flame graph (SVG) of running code
py-spy record --pid 1 --duration 30 --idle -o wall.svg  # include idle/waiting threads
py-spy dump   --pid 1                                   # current stack of every thread, once

Em um container o py-spy precisa da capability SYS_PTRACE (adicione-a ao container de debug, não à aplicação). Para código asyncio, lembre-se de que corrotinas esperando não são threads: uma visão wall-clock do event loop mostra onde o loop está bloqueado — o bug clássico sendo uma chamada síncrona (um cliente HTTP bloqueante, parsing pesado em CPU) dentro de um handler async def.

Profiling contínuo

Fazer profiling só durante incidentes significa que você não tem um "antes" para comparar. O profiling contínuo amostra todas as instâncias o tempo todo com baixa frequência e guarda os perfis como métricas (Grafana Pyroscope, profilers das nuvens; o OpenTelemetry está adicionando perfis como um quarto sinal). Ele permite flame graphs diferenciais — esta versão vs a anterior —, que tornam óbvias as regressões de desempenho em um canary.

Gargalos de banco de dados

O banco de dados é o gargalo mais comum de um sistema como o BoxOffice, porque é o único componente difícil de escalar horizontalmente e que toda escrita precisa alcançar.

Quais consultas?

Comece pelo agregado, não por um palpite. A extensão pg_stat_statements registra estatísticas de cada consulta normalizada:

SELECT left(query, 70)                         AS query,
       calls,
       round(total_exec_time)                  AS total_ms,
       round(mean_exec_time::numeric, 2)       AS mean_ms,
       round(100 * total_exec_time / sum(total_exec_time) OVER (), 1) AS pct
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

Ordene pelo tempo total, não pela média: uma consulta de 2 ms chamada 3 000 vezes por segundo custa mais que um relatório de 2 s rodado uma vez por hora.

Por que está lenta? EXPLAIN ANALYZE

O EXPLAIN mostra o plano escolhido pelo otimizador; o EXPLAIN (ANALYZE, BUFFERS) executa a consulta e reporta tempos reais, contagens reais de linhas e páginas lidas⁴. A consulta do mapa de assentos da venda:

EXPLAIN (ANALYZE, BUFFERS)
SELECT id, section, row_label, seat_number, price_cents
FROM seats
WHERE event_id = 4242 AND status = 'AVAILABLE'
ORDER BY section, row_label, seat_number
LIMIT 8;

Limit  (cost=187432.10..187432.12 rows=8 width=40) (actual time=412.551..412.555 rows=8 loops=1)
  Buffers: shared hit=2112 read=59861
  ->  Sort  (cost=187432.10..187507.10 rows=30000 width=40) (actual time=412.549..412.551 rows=8 loops=1)
        Sort Key: section, row_label, seat_number
        Sort Method: top-N heapsort  Memory: 26kB
        ->  Seq Scan on seats  (cost=0.00..186832.00 rows=30000 width=40) (actual time=0.031..405.127 rows=31480 loops=1)
              Filter: ((event_id = 4242) AND (status = 'AVAILABLE'::text))
              Rows Removed by Filter: 5968520
Planning Time: 0.142 ms
Execution Time: 412.601 ms

Como ler, de baixo para cima (o nó mais interno executa primeiro):

• Seq Scan com Rows Removed by Filter: 5968520 — o PostgreSQL leu todos os 6 milhões de assentos de todos os eventos para ficar com 31 480. Esse é o problema.
• Buffers: … read=59861 — cerca de 60 000 páginas (8 KB cada, ≈ 470 MB) vieram do disco ou do cache do SO, e não do cache de buffers do PostgreSQL. Sob carga, isso é saturação de I/O.
• Sort … top-N heapsort — ordenar 31 480 linhas para ficar com 8; barato aqui, mas evitável.
• Compare as linhas estimadas rows=30000 com as reais rows=31480: próximas, então as estatísticas estão boas. Uma diferença grande (100× fora) apontaria estatísticas desatualizadas (ANALYZE) ou colunas correlacionadas.

Um índice parcial que corresponda ao filtro e à ordenação permite ao PostgreSQL ler os 8 primeiros assentos disponíveis diretamente, em ordem:

CREATE INDEX CONCURRENTLY seats_available_idx
    ON seats (event_id, section, row_label, seat_number)
    WHERE status = 'AVAILABLE';

Limit  (cost=0.43..9.87 rows=8 width=40) (actual time=0.041..0.058 rows=8 loops=1)
  Buffers: shared hit=5
  ->  Index Scan using seats_available_idx on seats  (cost=0.43..35392.11 rows=30000 width=40) (actual time=0.040..0.055 rows=8 loops=1)
        Index Cond: (event_id = 4242)
Planning Time: 0.210 ms
Execution Time: 0.079 ms

De 412 ms para 0,08 ms e de ~62 000 páginas para 5. O CONCURRENTLY constrói o índice sem bloquear escritas — essencial em uma tabela em uso. (Índices não são de graça: cada um desacelera as escritas e usa memória; indexe o que o modelo de carga diz que é quente.)

-- Lab 6: indexes for the listing "upcoming events in a city, soonest first".
-- Walk events in starts_at order and stop after one page, instead of sorting 20,000 rows:
CREATE INDEX events_starts_at_idx ON catalog.events (starts_at, id);
-- Count/filter the events of a city's venues without reading the whole table:
CREATE INDEX events_venue_starts_at_idx ON catalog.events (venue_id, starts_at);
CREATE INDEX venues_city_idx ON catalog.venues (city);

Contenção de locks e linhas quentes

Quando todos querem os mesmos assentos, as transações fazem fila por locks de linha. Descubra quem espera por quem:

SELECT pid,
       pg_blocking_pids(pid)        AS blocked_by,
       wait_event_type, wait_event,
       now() - query_start          AS waiting_for,
       left(query, 60)              AS query
FROM pg_stat_activity
WHERE cardinality(pg_blocking_pids(pid)) > 0;

Três mudanças reduzem a contenção, em ordem de esforço:

1. Mantenha as transações curtas. Nunca chame outro serviço (preços, pagamento) segurando uma transação: calcule o preço antes do BEGIN, chame o provedor de pagamento depois do COMMIT (com um outbox ou uma saga — veja Mensageria — padrões).

2. Não brigue pela mesma linha. Quando o fã pede "2 assentos no setor A", quaisquer dois assentos livres servem. O SKIP LOCKED permite que transações concorrentes peguem linhas livres diferentes em vez de fazer fila na primeira:

   BEGIN;
   SELECT id FROM seats
   WHERE event_id = 4242 AND section = 'A' AND status = 'AVAILABLE'
   ORDER BY row_label, seat_number
   LIMIT 2
   FOR UPDATE SKIP LOCKED;
   UPDATE seats
      SET status = 'HELD', held_by = $1, hold_expires_at = now() + interval '10 minutes'
    WHERE id = ANY($2);
   COMMIT;
   

3. Controle a admissão. Se 50 000 fãs tentam reservar assentos no mesmo segundo, nenhuma estratégia de lock deixa o PostgreSQL feliz. Uma sala de espera admite fãs na taxa que o inventário consegue absorver — transformando contenção em uma fila ordenada (Mensageria — filas).

Dimensionando o pool de conexões

Um pool de conexões pode ser gargalo nos dois sentidos: pequeno demais e as requisições esperam uma conexão; grande demais e o banco passa o tempo alternando entre centenas de sessões, brigando por locks e memória. Dimensione-o com a Lei de Little — conexões necessárias = vazão × tempo em que cada requisição segura uma conexão:

A primeira correção não é um pool maior — é segurar a conexão por menos tempo. Depois, dimensione pela capacidade do banco: o PostgreSQL funciona melhor com um número de conexões ativas da ordem de algumas vezes seus núcleos de CPU (o ponto de partida muito citado do HikariCP é conexões ≈ núcleos × 2 + discos efetivos)⁵. Vinte pods × um pool de 20 = 400 conexões está muito além disso; coloque o PgBouncer em modo transaction pooling entre os pods e o banco, para que centenas de conexões de clientes compartilhem algumas dezenas de conexões de servidor. E falhe rápido:

spring:
  datasource:
    hikari:
      maximum-pool-size: 10
      minimum-idle: 10            # a fixed-size pool: no ramp-up during the spike
      connection-timeout: 2000    # wait at most 2 s for a connection (the default is 30 s)

; PgBouncer: thousands of client connections, a few dozen real PostgreSQL connections.
[databases]
boxoffice = host=db port=5432 dbname=boxoffice

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
auth_type = scram-sha-256
auth_file = /etc/pgbouncer/userlist.txt
admin_users = boxoffice

; transaction pooling: a server connection is lent for ONE transaction, then returned
pool_mode = transaction
; real connections to PostgreSQL per (database, user) pair
default_pool_size = 20
; client connections PgBouncer accepts (all services and replicas together)
max_client_conn = 1000
; protocol-level prepared statements work in transaction mode (PgBouncer >= 1.21)
max_prepared_statements = 200
ignore_startup_parameters = extra_float_digits,options

Uma mudança por vez: um diário de otimização

Mantenha um diário de cada execução: o que mudou, o novo joelho e o que saturou em seguida. Um gargalo removido revela o próximo; o objetivo não é "nenhum gargalo" (sempre há um), mas o gargalo no lugar certo com capacidade suficiente. O diário abaixo ilustra uma campanha típica em POST /holds:

Depois da execução 6, o gargalo é deliberado: a taxa de admissão da sala de espera, definida abaixo do joelho do banco. Escalar além disso exigiria particionar o inventário por evento ou local (Bancos de dados — particionamento) — uma mudança muito maior, agora justificada por números.

Experimente: o cenário monolith (um servidor de aplicação e um PostgreSQL, perfil breakpoint) produz as duas primeiras linhas de um registro desses em poucos minutos. Rode como está e abra o Relatório: o gargalo é o app, já 86 % ocupado a cerca de 430 req/s, e o sistema quebra a cerca de 590 req/s. Mude uma coisa — selecione o app e suba as réplicas para 6 — e rode de novo: o ponto de ruptura salta para cerca de 2.520 req/s, e o gargalo passa para o db, 87 % ocupado a cerca de 2.180 req/s. Agora mude a coisa errada: 12 réplicas em vez de 6. O ponto de ruptura continua em cerca de 2.520 req/s enquanto o custo mensal vai de cerca de 1.170 para 1.890 USD — acrescentar capacidade a um componente que não é o gargalo não compra nada.

Como se conecta

flowchart LR
    CURVE["stepped curve<br/>and symptoms"] --> RES["which resource?<br/>USE → Methodology"]
    RES --> PROF["which code? flame graphs,<br/>async-profiler, py-spy"]
    RES --> DBQ["which query? pg_stat_statements,<br/>EXPLAIN ANALYZE"]
    DBQ --> IDX["indexes, N+1<br/>→ Databases models"]
    DBQ --> LOCK["hot rows, SKIP LOCKED<br/>→ Databases transactions"]
    DBQ --> POOL["pool sizing by Little's Law,<br/>PgBouncer"]
    RES --> CACHE["low hit ratio, stampede<br/>→ Caching failure modes"]
    RES --> DEP["slow dependency<br/>→ Reliability patterns"]
    PROF --> LOG["one change at a time:<br/>the optimization log"]

Componentes da paleta: app (CPU, GC, pools de threads, serialização) · sql (índices, locks, pools de conexões) · cache (taxa de acerto, chaves quentes, stampedes) · queue (tirar escritas disputadas do caminho da requisição) · thirdparty (dependências lentas) · tracing (consultas N+1 aparecem como dezenas de spans idênticos) e metrics (contadores de pool e de throttling). Cenários: monolith (perfil breakpoint: encontrar o primeiro recurso a saturar), read-heavy-cache, flash-sale (linhas quentes de assentos). Continua em: Bancos de dados — transações, Bancos de dados — particionamento, Cache — modos de falha, Mensageria — filas e pub/sub, Confiabilidade — padrões, Planejamento de capacidade.