Dominando top e htop: Identificando Gargalos do Sistema

Dominando top e htop: Identificando Gargalos do Sistema
Tempo de leitura: Cerca de 14 min Dificuldade: Intermediário+

O Que Você Vai Aprender

  • Como julgar gargalo de CPU, memória ou I/O em 30 segundos a partir das linhas de resumo do top
  • O significado e os limites de decisão para %us, %sy, %wa, %si
  • Como usar o tree view, filtros e teclas F do htop para caçar processos problemáticos interativamente
  • Como ir além de "load average está alto" até a verdadeira camada raiz

Triagem Rápida (padrão de 30 segundos)

  1. Olhe a linha 3 do top -> %us alto = CPU-bound, %wa alto = espera I/O, %sy alto = overhead de kernel/troca de contexto
  2. Olhe as linhas 4-5 -> avail Mem mínimo e swap used crescendo = pressão de memória
  3. Use htop para o suspeito: tree view + ordenação (teclas P / M / T)

Pré-requisitos

  • SO: Ubuntu / família RHEL Linux
  • htop pode não estar pré-instalado (sudo apt install htop / sudo dnf install htop)
  • Exemplos de saída assumem procps-ng top (BSD top exibe de forma diferente)

Por Que Usar Tanto top Quanto htop?

top é garantido existir em todo lugar (procps-ng acompanha praticamente toda distribuição Linux). htop se destaca em interatividade e visual: tree view, cores, suporte a mouse, ordenação multi-coluna. top é sua última linha de defesa durante incidentes; htop é o investigador do dia a dia. Eles se complementam.

Quando usar qual

  • Resposta a incidentes / container mínimo / apenas SSH -> top (o binário quase sempre está lá)
  • Monitoramento diário / análise pai-filho / kill de processos em lote -> htop

Como Ler a Tela do top

O resumo de 5 linhas no topo é o que importa. A lista de processos vem em segundo lugar.

top - 14:32:11 up 12 days,  3:45,  2 users,  load average: 4.21, 3.85, 2.10
Tasks: 234 total,   2 running, 232 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.3 us,  3.2 sy,  0.0 ni, 78.5 id,  5.8 wa,  0.0 hi,  0.2 si,  0.0 st
MiB Mem :  16004.0 total,    412.5 free,  12890.3 used,   2701.2 buff/cache
MiB Swap:   2048.0 total,    102.3 free,   1945.7 used,   1893.4 avail Mem

Linha 1: uptime + load average

load average: 4.21, 3.85, 2.10 é a contagem média de processos em estado R (executável) ou D (sleep ininterruptível) nos últimos 1 / 5 / 15 minutos. Compare com a contagem de núcleos de CPU.

  • Exemplo: máquina de 4 núcleos em 4.21 -> quase saturada
  • Exemplo: máquina de 4 núcleos em 8.50 -> cronicamente sobrecarregada
  • 1-min > 15-min -> carga subindo; 1-min < 15-min -> carga diminuindo

O load average inclui processos em estado D (I/O ininterruptível), não apenas contenção de CPU. %wa alto também infla o load - "load alto = precisa de mais CPU" é uma interpretação errada comum.

Linha 3: Detalhamento de CPU (Mais Importante)

Campo Significado Limite
us CPU espaço de usuário Sustentado 80%+ = CPU-bound
sy CPU espaço do kernel 30%+ = syscalls excessivos
ni Processos com nice (prioridade) Normalmente ignorável
id Ocioso Menor = mais ocupado
wa Espera I/O (disco / rede) 20%+ = gargalo de I/O
hi Interrupções de hardware Normalmente menor que 1%
si Interrupções de software 5%+ = churn de rede/timer
st Tempo roubado (virtualização) 10%+ = impacto de vizinho ruidoso

Linhas 4-5: Memória e Swap

  • free pequeno + buff/cache grande -> saudável (kernel usando cache)
  • free pequeno + buff/cache pequeno + swap used crescendo -> pressão real de memória
  • avail Mem é o orçamento realista para novos processos. Confie nele mais do que em free.

Onde Você Identifica um Gargalo de CPU?

Quando o %us da linha 3 fica acima de ~80% sustentado e a carga se concentra em um ou dois processos, você tem uma carga de trabalho CPU-bound.

Passos de Investigação

# 1. Snapshot
$ top

# 2. Ordenar por CPU (pressione Shift + P enquanto top roda)
# Coluna %CPU agora ordenada decrescente

# 3. Um unico processo > 100% (= 1 nucleo completo) -> esse e o culpado
# Carga espalhada entre muitos processos -> sobrecarga geral; escale horizontalmente

A tecla 1 no top: alterna para detalhamento por núcleo. Identifique um processo single-threaded saturando um núcleo instantaneamente.

%us Alto mas Nenhum Culpado Obvio?

  • Processos de curta duração podem não aparecer na janela de atualização de 3 segundos do top
  • Tente top -d 0.5 para atualização a cada meio segundo, ou pidstat 1 para granularidade por segundo

Como Você Detecta Pressão de Memória?

free baixo não é igual a pressão de memória. O Linux usa RAM livre como cache de página, então free é sempre pequeno em um sistema ocupado.

Critérios Reais de Pressão de Memória

  1. avail Mem do MiB Mem cai abaixo de 5% do total
  2. used do MiB Swap está aumentando continuamente
  3. No top, pressione Shift + M para ordenar por RES (memória residente) -> um processo anormalmente grande
  4. dmesg | grep -i "killed process" mostra atividade do OOM Killer

Uso de swap não é igual a pressão instantânea de memória. O Linux fazendo paging out de páginas frias é normal. O sinal de alerta é swap used crescendo continuamente enquanto %wa também sobe (thrashing).

Como Você Identifica Espera I/O?

Quando %wa fica em 20%+, a CPU está ociosa mas as tarefas não progridem - estão esperando por disco ou rede.

Comandos de Detalhamento

# Quais processos estao em estado D (sleep ininterruptivel)?
$ ps -eo state,pid,cmd | grep "^D"

# Taxas de I/O por dispositivo
$ iostat -xz 1

# I/O por processo (iotop precisa de root)
$ sudo iotop -o

Tabela de decisão rápida

%us %wa Interpretação
Alto Baixo CPU-bound (computação pesada)
Baixo Alto I/O-bound (latência de disco/rede)
Alto Alto Misto (ex., query de banco pesada)
Baixo Baixo Contenção de lock / API externa / dormindo

Quais São os Recursos Principais do htop?

htop parece um top mais bonito, mas as vantagens reais são o tree view, filtros e operações de seleção múltipla.

Visualização Padrão

  0[||||||||||||||||                       45.2%]   Tasks: 87, 234 thr; 3 running
  1[|||||||||                              22.1%]   Load average: 1.85 1.42 1.05
  2[|||||||||||||||||||||||||||||||||||||  98.7%]   Uptime: 12 days, 03:45:11
  3[|||                                     5.3%]
  Mem[|||||||||||||||||||||              12.5G/16.0G]
  Swp[|||||                                  1.9G/2.0G]

A utilização por núcleo é visível como barras. O núcleo 2 em 98.7% grita "gargalo single-threaded" em um relance.

Teclas F e Atalhos Comuns

Tecla Função
F2 Configurações (cores, colunas, modos de exibição)
F3 / / Busca incremental por nome de processo
F4 / \ Filtrar por nome de processo (oculta não-coincidentes)
F5 / t Alternar tree view (relações pai-filho)
F6 Escolher coluna de ordenação
F9 / k Enviar sinal (SIGTERM / SIGKILL / etc.)
Space Marcar um processo (seleção múltipla)
Shift + P Ordenar por %CPU
Shift + M Ordenar por %MEM
Shift + T Ordenar por hora de início
u Filtrar por usuário

Quando o Tree View Faz Valer a Pena

|-- nginx: master process
   |-- nginx: worker process
   |-- nginx: worker process
   |-- nginx: cache manager process

O tree view F5 é imbatível quando você precisa encontrar o pai problemático de filhos descontrolados. Se apenas um worker nginx está consumindo CPU, o problema é específico da requisição, não da configuração geral.

Matando Múltiplos Processos de Uma Vez

  1. Reduza a lista com / (busca) ou F4 (filtro)
  2. Pressione Space em cada alvo para marcar (seleção múltipla)
  3. Pressione F9 para escolher um sinal -> ele é enviado para todos os processos marcados

SIGKILL (9) é último recurso. Tente SIGTERM (15) primeiro, depois escale. SIGKILL em bancos de dados ou processos no meio de escrita pode corromper dados.

Fluxo de Diagnóstico Prático de Gargalos

O fluxo de 3 passos que executo durante incidentes reais.

Passo 1: Estreitar a Camada com top (10 seg)

$ top -b -n 1 | head -5

-b (batch) + -n 1 (uma iteração) também torna registrável em logs.

  • Pico de %wa -> suspeitar camada I/O (próximo: iostat)
  • Pico de %us -> suspeitar camada de aplicação (próximo: htop para encontrar PID)
  • Pico de %sy -> suspeitar camada de kernel (próximo: strace, perf)
  • Swap used subindo -> suspeitar camada de memória (próximo: ordenar com Shift + M)

Passo 2: Encontrar o Processo Suspeito com htop (30 seg)

$ htop
# Shift + P / M / T para ordenar pelo seu eixo de interesse
# F5 para tree view para inspecionar relacoes pai-filho

Passo 3: Investigar a Causa Raiz

  • Camada de aplicação -> strace -p PID -f, logs da aplicação
  • Camada I/O -> iotop -o, iostat -x 1
  • Camada de kernel -> dmesg -T, journalctl -k
  • Camada de memória -> dmesg | grep -i oom, profiling de vazamento da app

Template de campo: triagem de 30 segundos

# 1. Visao geral
top -b -n 1 | head -20

# 2. Tendencia de carga
uptime

# 3. Estado real da memoria
free -h

# 4. Detalhe de espera I/O
iostat -xz 1 3

# 5. Encontrar o culpado (interativo)
htop

Erros Comuns a Evitar

Armadilhas ao usar top / htop

  • Tratar load average sozinho como "falta de CPU" (pode ser causado por %wa)
  • Tratar free baixo como "falta de memória" (olhe avail Mem)
  • Confiar em um único snapshot (observe por pelo menos 10 segundos para filtrar picos transitórios)
  • Recorrer a SIGKILL primeiro (nega ao processo a chance de fazer flush)
  • Matar processos pai sem verificar o tree view (risco de processos órfãos)

Resumo

  • A linha 3 do top (detalhamento de CPU) e as linhas 4-5 (memória) são os pontos de entrada diagnósticos
  • Qual de %us / %sy / %wa está alto indica em qual camada investigar
  • O tree view, filtros e marcação do htop tornam a caca de processos eficiente
  • O padrão do mundo real: triagem de 30 segundos -> identificar camada -> ferramentas especialistas (iostat / strace / etc.) para investigação profunda

Próximas Leituras