Como diagnosticar CPU 100% no Linux - Guia top, ps, load average

2025-12-16 Tempo de leitura: Cerca de 10 min Dificuldade: Intermediário

O que você vai aprender

• Como identificar rapidamente o processo causando CPU 100%
• Como distinguir entre "problema real de CPU" vs "I/O wait" ou "swap thrashing"
• Como salvar evidências (logs/valores) antes de reiniciar para prevenção

1. Dois tipos de "CPU 100%" (ponto cego)

Conclusão: CPU alta é computação real (%us alto) ou I/O wait (%wa alto) -- identifique primeiro.

Quando a CPU está alta, a causa geralmente é uma destas:

Tipo A: Processamento de CPU realmente pesado

• Cálculos/loops/criptografia/conversão/agregação
• top mostra processo específico consumindo CPU
• %us (CPU de usuário) geralmente está alto

Tipo B: Parece CPU mas na verdade é I/O Wait / Falta de Memória

• Disco lento (logs inchados, DB, degradação de EBS, limite de I/O)
• Swap crescendo = extremamente lento (falta de memória)
• %wa (I/O wait) geralmente está alto

2. uptime para load average (Pressão geral)

Conclusão: Execute uptime -- load acima da contagem de cores sinaliza pressão sustentada no sistema.

$ uptime

Exemplo de saída:

 14:05:12 up 10 days,  3:20,  2 users,  load average: 3.52, 3.10, 2.90

O que load average significa (simplificado para iniciantes):

• Se cores de CPU = 4, load por volta de 4 significa "ocupado"
• Load em 10 significa bastante congestionado

3. top para o "Culpado" e "Detalhamento de CPU"

Conclusão: Execute top, pressione P para ordenar, depois leia %us/%sy/%wa para classificar a carga.

$ top

3-1. Atalhos do top (essenciais)

• P: Ordenar por CPU
• M: Ordenar por memória (quando memória é suspeita)
• 1: Mostrar CPU por núcleo (verificar desequilibrio)
• q: Sair

3-2. Lendo o detalhamento de CPU (%us / %sy / %wa)

Mostrado no topo da tela:

• %us: Processamento de aplicação usando CPU
• %sy: Processamento de kernel/sistema (rede/disco/interrupções)
• %wa: I/O wait (disco lento/congestionado)

Interpretação rápida:

• %us alto -> Processamento de aplicação está pesado (Tipo A)
• %wa alto -> I/O está congestionado (Tipo B)
• %sy alto -> Processamento do lado do sistema está pesado

4. ps para lista dos maiores consumidores de CPU (Salvar evidências)

Conclusão: Execute ps aux --sort=-%cpu | head -n 20 e salve a saída antes de qualquer reinicio.

top mostra um momento, mas ps pode capturar um snapshot.

$ ps aux --sort=-%cpu | head -n 20

Colunas principais para observar:

• COMMAND: O que está consumindo CPU
• %CPU: Qual é o outlier

Se muitos do mesmo tipo (proliferação de workers), provavelmente faltam limites ou carga excessiva.

5. Se é um serviço: systemctl / journalctl

Conclusão: Quando um serviço identificado é a causa, verifique systemctl status e journalctl -u.

Se o processo é nginx, apache2, ou uma aplicação (php-fpm, node, gunicorn, etc.), os logs frequentemente mostram a causa.

5-1. Status do serviço

$ sudo systemctl status nginx
$ sudo systemctl status apache2
$ sudo systemctl status php8.1-fpm

5-2. Logs (últimas 200 linhas)

$ sudo journalctl -u nginx -n 200
$ sudo journalctl -u php8.1-fpm -n 200

6. Descartar "Na verdade não é CPU" (Importante)

Conclusão: Execute free -h e verifique %wa no top -- swap alto ou %wa significa I/O, não CPU.

Pule isso e você fará um diagnóstico errado.

6-1. Verificar falta de memória (Swap)

$ free -h

Se swap está crescendo / disponível é pequeno, pode parecer CPU mas a causa raiz é memória.

6-2. Se %wa está alto, suspeite de I/O de disco

• Logs inchados
• DB
• Explosão de camadas Docker
• Problemas de desempenho de armazenamento

$ iostat -x 1 5

7. Padrões de causas comuns (Por frequência)

Conclusão: Processo descontrolado, pico de tráfego, explosão de workers, mascaramento por I/O -- cada um aparece diferente no top.

Padrão 1: Loop infinito / Bug / Processo descontrolado

• Um processo consumindo CPU constantemente (%us alto)
• Correção: Verificar logs, deploys recentes, mudanças recentes

Padrão 2: Bot / Scan / Surto de tráfego

• Logs de acesso do nginx/apache explodindo
• Correção: Verificar logs web, considerar rate limiting/WAF/cache

Padrão 3: Muitos workers (php-fpm, etc.)

• Processos filhos crescendo continuamente, consumindo CPU e memória
• Correção: Definir limites de workers (MaxChildren, etc.)

Padrão 4: I/O está lento, então CPU parece alta

• %wa está alto
• Correção: Investigar I/O de disco

8. O que evitar

Conclusão: Salve uptime, free -h, ps aux antes de reiniciar; verifique %wa antes de escalar.

Não faça: Reiniciar sem salvar evidências

No mínimo, capture estes antes de decidir:

• uptime
• free -h
• ps aux --sort=-%cpu | head
• top (screenshot se possível)

Não faça: Escalar CPU sem verificar %wa

Se I/O wait é a causa, escalar CPU é desperdicio (custo de oportunidade).

Não faça: Deixar configurações de workers sem limite

O sistema vai quebrar no momento em que o tráfego aumentar. Defina limites primeiro.

# 1) Visao geral
uptime

# 2) Tambem verificar memoria (descartar "na verdade nao e CPU")
free -h

# 3) Lista dos maiores de CPU (evidencia)
ps aux --sort=-%cpu | head -n 20

# 4) top para detalhamento (%us/%sy/%wa) e culpado
top

# 5) Se e um servico, verificar logs
sudo systemctl status <service>
sudo journalctl -u <service> -n 200