Dominando top e htop: Identificando Gargalos do Sistema

Dominando top e htop: Identificando Gargalos do Sistema
Tempo de leitura: Cerca de 14 min Dificuldade: Intermediate

O Que Voce Vai Aprender

  • Como julgar gargalo de CPU, memoria ou I/O em 30 segundos a partir das linhas de resumo do top
  • O significado e os limites de decisao para %us, %sy, %wa, %si
  • Como usar o tree view, filtros e teclas F do htop para cacar processos problemáticos interativamente
  • Como ir alem de "load average esta alto" ate a verdadeira camada raiz

Triagem Rapida (padrao 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 minimo e swap used crescendo = pressao de memoria
  3. Use htop para o suspeito: tree view + ordenacao (teclas P / M / T)

Pre-requisitos

  • SO: Ubuntu / familia RHEL Linux
  • htop pode nao estar pre-instalado (sudo apt install htop / sudo dnf install htop)
  • Exemplos de saida assumem procps-ng top (BSD top exibe de forma diferente)

Por Que Usar Tanto top Quanto htop?

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

Quando usar qual

  • Resposta a incidentes / container minimo / apenas SSH -> top (o binario quase sempre esta la)
  • Monitoramento diario / analise pai-filho / kill de processos em lote -> htop

Como Ler a Tela do top

O resumo de 5 linhas no topo e 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 e a contagem media de processos em estado R (executavel) ou D (sleep ininterruptivel) nos ultimos 1 / 5 / 15 minutos. Compare com a contagem de nucleos de CPU.

  • Exemplo: maquina de 4 nucleos em 4.21 -> quase saturada
  • Exemplo: maquina de 4 nucleos 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 ininterruptivel), nao apenas contencao de CPU. %wa alto tambem infla o load - "load alto = precisa de mais CPU" e uma interpretacao errada comum.

Linha 3: Detalhamento de CPU (Mais Importante)

Campo Significado Limite
us CPU espaco de usuario Sustentado 80%+ = CPU-bound
sy CPU espaco do kernel 30%+ = syscalls excessivos
ni Processos com nice (prioridade) Normalmente ignoravel
id Ocioso Menor = mais ocupado
wa Espera I/O (disco / rede) 20%+ = gargalo de I/O
hi Interrupcoes de hardware Normalmente menor que 1%
si Interrupcoes de software 5%+ = churn de rede/timer
st Tempo roubado (virtualizacao) 10%+ = impacto de vizinho ruidoso

Linhas 4-5: Memoria e Swap

  • free pequeno + buff/cache grande -> saudavel (kernel usando cache)
  • free pequeno + buff/cache pequeno + swap used crescendo -> pressao real de memoria
  • avail Mem e o orcamento realista para novos processos. Confie nele mais do que em free.

Onde Voce 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, voce tem uma carga de trabalho CPU-bound.

Passos de Investigacao

# 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 nucleo. Identifique um processo single-threaded saturando um nucleo instantaneamente.

%us Alto mas Nenhum Culpado Obvio?

  • Processos de curta duracao podem nao aparecer na janela de atualizacao de 3 segundos do top
  • Tente top -d 0.5 para atualizacao a cada meio segundo, ou pidstat 1 para granularidade por segundo

Como Voce Detecta Pressao de Memoria?

free baixo nao e igual a pressao de memoria. O Linux usa RAM livre como cache de pagina, entao free e sempre pequeno em um sistema ocupado.

Criterios Reais de Pressao de Memoria

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

Uso de swap nao e igual a pressao instantanea de memoria. O Linux fazendo paging out de paginas frias e normal. O sinal de alerta e swap used crescendo continuamente enquanto %wa tambem sobe (thrashing).

Como Voce Identifica Espera I/O?

Quando %wa fica em 20%+, a CPU esta ociosa mas as tarefas nao progridem - estao 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 decisao rapida

%us %wa Interpretacao
Alto Baixo CPU-bound (computacao pesada)
Baixo Alto I/O-bound (latencia de disco/rede)
Alto Alto Misto (ex., query de banco pesada)
Baixo Baixo Contencao de lock / API externa / dormindo

Quais Sao os Recursos Principais do htop?

htop parece um top mais bonito, mas as vantagens reais sao o tree view, filtros e operacoes de selecao multipla.

Visualizacao Padrao

  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 utilizacao por nucleo e visivel como barras. O nucleo 2 em 98.7% grita "gargalo single-threaded" em um relance.

Teclas F e Atalhos Comuns

Tecla Funcao
F2 Configuracoes (cores, colunas, modos de exibicao)
F3 / / Busca incremental por nome de processo
F4 / \ Filtrar por nome de processo (oculta nao-coincidentes)
F5 / t Alternar tree view (relacoes pai-filho)
F6 Escolher coluna de ordenacao
F9 / k Enviar sinal (SIGTERM / SIGKILL / etc.)
Space Marcar um processo (selecao multipla)
Shift + P Ordenar por %CPU
Shift + M Ordenar por %MEM
Shift + T Ordenar por hora de inicio
u Filtrar por usuario

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 e imbativel quando voce precisa encontrar o pai problemático de filhos descontrolados. Se apenas um worker nginx esta consumindo CPU, o problema e especifico da requisicao, nao da configuracao geral.

Matando Multiplos Processos de Uma Vez

  1. Reduza a lista com / (busca) ou F4 (filtro)
  2. Pressione Space em cada alvo para marcar (selecao multipla)
  3. Pressione F9 para escolher um sinal -> ele e enviado para todos os processos marcados

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

Fluxo de Diagnostico Pratico 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 iteracao) tambem torna registravel em logs.

  • Pico de %wa -> suspeitar camada I/O (proximo: iostat)
  • Pico de %us -> suspeitar camada de aplicacao (proximo: htop para encontrar PID)
  • Pico de %sy -> suspeitar camada de kernel (proximo: strace, perf)
  • Swap used subindo -> suspeitar camada de memoria (proximo: 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 aplicacao -> strace -p PID -f, logs da aplicacao
  • Camada I/O -> iotop -o, iostat -x 1
  • Camada de kernel -> dmesg -T, journalctl -k
  • Camada de memoria -> 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 memoria" (olhe avail Mem)
  • Confiar em um unico 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 orfaos)

Resumo

  • A linha 3 do top (detalhamento de CPU) e as linhas 4-5 (memoria) sao os pontos de entrada diagnosticos
  • Qual de %us / %sy / %wa esta alto indica em qual camada investigar
  • O tree view, filtros e marcacao do htop tornam a caca de processos eficiente
  • O padrao do mundo real: triagem de 30 segundos -> identificar camada -> ferramentas especialistas (iostat / strace / etc.) para investigacao profunda

Proximas Leituras