Análise de Performance USE+TSA de Brendan Gregg

Visão Geral

Um procedimento fixo e baseado em evidências para depuração de performance de sistemas, análise de causa raiz (RCA) e relatórios de incidentes, destilado das metodologias publicadas por Brendan Gregg. Em vez de executar quaisquer comandos que sejam familiares, o agente primeiro faz perguntas e depois encontra métricas para respondê-las: o Método USE (Utilização, Saturação, Erros) varre todos os recursos, o Método TSA (Análise de Estado de Threads) decompõe o tempo de threads, e a análise off-CPU mais os flame graphs aprofundam o que as varreduras encontram. Cada investigação termina em uma nota de triagem estruturada, relatório RCA ou postmortem onde cada afirmação rastreia para um comando e sua saída.

Esta habilidade adapta material do repositório da comunidade thecsdoctor/brendangregg-use-tsa-skill (listas de verificação completas, biblioteca de referência e modelos de relatório estão lá).

Quando Usar Esta Habilidade

• Use quando um servidor, VM ou contêiner está "lento" e a causa é desconhecida
• Use quando a latência ou throughput regrediu após um deploy, mudança de configuração ou alteração de carga
• Use quando métricas de CPU, memória, disco ou rede parecem anormais e precisam de interpretação
• Use quando uma aplicação trava ou threads se acumulam
• Use quando o usuário pede depuração, triagem ou análise de causa raiz de um problema de performance
• Use quando um incidente precisa de um relatório RCA ou um postmortem sem culpa com um rastro de evidências

Como Funciona

Passo 0: Declaração do Problema

Defina o problema antes de medir. Pergunte: O que faz você pensar que há um problema? Já teve uma boa performance antes? O que mudou recentemente (software, hardware, carga)? Pode ser expresso como latência ou tempo de execução — quantifique. Quem mais é afetado? Qual é o ambiente (SO, versões, configuração, limites de contêiner/VM)?

Passo 1: Triagem de 60 Segundos (Linux)

Execute a varredura de dez comandos, verificando erros e saturação primeiro (mais fáceis de interpretar), depois utilização. Registre cada recurso exonerado.

uptime                 # load trend (includes uninterruptible I/O on Linux)
dmesg | tail           # kernel errors: oom-killer, SYN flooding, hardware
vmstat 1               # r > CPU count = CPU saturation; si/so = swapping; wa = disk
mpstat -P ALL 1        # per-CPU imbalance (single hot CPU = single-threaded app)
pidstat 1              # per-process CPU over time
iostat -xz 1           # await (app-suffered latency), avgqu-sz, %util
free -m                # memory; buffers/cache near zero hurts
sar -n DEV 1           # NIC throughput vs link limit
sar -n TCP,ETCP 1      # active/passive connections, retransmits
top                    # spot variable load

Passo 2: Varredura USE (orientada a recursos)

Para cada recurso, verifique Utilização, Saturação e Erros. Itere CPUs, capacidade de memória, interfaces de rede, I/O e capacidade de armazenamento, controladores, interconexões — mais recursos de software (travas mutex, pools de threads, capacidade de processos/descritores de arquivo) e limites impostos (quotas cgroup, limites de hypervisor, ulimits). Verifique erros antes da utilização. Interpretações: 100% de utilização é geralmente um gargalo (confirme via saturação); qualquer saturação não zero pode ser um problema; contadores de erro não zero e em constante aumento valem a pena investigar; e uma varredura limpa é um resultado — ela estreita o espaço de busca.

Passo 3: Varredura TSA (orientada a threads)

Para cada thread de interesse, divida o tempo em: Executando / Executável / Paginação Anônima / Dormindo / Trava / Ocioso. Investigue estados do mais para o menos frequente com ferramentas apropriadas para o estado. Se mais de ~10% do tempo for Executável ou Paginação Anônima, corrija esses primeiro — estados de latência podem ser ajustados para zero. Instrumentos Linux: /proc/PID/schedstat run_delay e perf sched latency (Executável), vmstat si/so e min_flt por processo (Paginação), offcputime/cpudist de bcc (Dormindo), /proc/lock_stat e valgrind --tool=drd (Trava), pidstat/flame graphs (Executando).

Passo 4: Aprofundar

Siga o maior contribuinte: Executando → perfil de CPU + flame graph; Dormindo/Trava → pilhas off-CPU (offcputime -p PID, renderizar com flamegraph.pl --color=io); reclamações de latência → decomposição por divisão de tempo; microsserviços → método RED (Taxa, Erros, Duração). Prefira agregação in-kernel eBPF sobre dumps por evento; comece com traces de sub-segundo em produção.

Passo 5: Confirmar Causa Raiz

…