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

2025-12-16 Tempo de leitura: Cerca de 10 min Dificuldade: Intermediario

O que voce 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 evidencias (logs/valores) antes de reiniciar para prevencao

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

Conclusao: CPU alta e computacao real (%us alto) ou I/O wait (%wa alto) -- identifique primeiro.

Quando a CPU esta alta, a causa geralmente e uma destas:

Tipo A: Processamento de CPU realmente pesado

• Calculos/loops/criptografia/conversao/agregacao
• top mostra processo especifico consumindo CPU
• %us (CPU de usuario) geralmente esta alto

Tipo B: Parece CPU mas na verdade e I/O Wait / Falta de Memoria

• Disco lento (logs inchados, DB, degradacao de EBS, limite de I/O)
• Swap crescendo = extremamente lento (falta de memoria)
• %wa (I/O wait) geralmente esta alto

2. uptime para load average (Pressao geral)

Conclusao: Execute uptime -- load acima da contagem de cores sinaliza pressao sustentada no sistema.

$ uptime

Exemplo de saida:

 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"

Conclusao: 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 memoria (quando memoria e suspeita)
• 1: Mostrar CPU por nucleo (verificar desequilibrio)
• q: Sair

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

Mostrado no topo da tela:

• %us: Processamento de aplicacao usando CPU
• %sy: Processamento de kernel/sistema (rede/disco/interrupcoes)
• %wa: I/O wait (disco lento/congestionado)

Interpretacao rapida:

• %us alto -> Processamento de aplicacao esta pesado (Tipo A)
• %wa alto -> I/O esta congestionado (Tipo B)
• %sy alto -> Processamento do lado do sistema esta pesado

4. ps para lista dos maiores consumidores de CPU (Salvar evidencias)

Conclusao: Execute ps aux --sort=-%cpu | head -n 20 e salve a saida 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 esta consumindo CPU
• %CPU: Qual e o outlier

Se muitos do mesmo tipo (proliferacao de workers), provavelmente faltam limites ou carga excessiva.

5. Se e um servico: systemctl / journalctl

Conclusao: Quando um servico identificado e a causa, verifique systemctl status e journalctl -u.

Se o processo e nginx, apache2, ou uma aplicacao (php-fpm, node, gunicorn, etc.), os logs frequentemente mostram a causa.

5-1. Status do servico

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

5-2. Logs (ultimas 200 linhas)

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

6. Descartar "Na verdade nao e CPU" (Importante)

Conclusao: Execute free -h e verifique %wa no top -- swap alto ou %wa significa I/O, nao CPU.

Pule isso e voce fara um diagnostico errado.

6-1. Verificar falta de memoria (Swap)

$ free -h

Se swap esta crescendo / disponivel e pequeno, pode parecer CPU mas a causa raiz e memoria.

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

• Logs inchados
• DB
• Explosao de camadas Docker
• Problemas de desempenho de armazenamento

$ iostat -x 1 5

7. Padroes de causas comuns (Por frequencia)

Conclusao: Processo descontrolado, pico de trafego, explosao de workers, mascaramento por I/O -- cada um aparece diferente no top.

Padrao 1: Loop infinito / Bug / Processo descontrolado

• Um processo consumindo CPU constantemente (%us alto)
• Correcao: Verificar logs, deploys recentes, mudancas recentes

Padrao 2: Bot / Scan / Surto de trafego

• Logs de acesso do nginx/apache explodindo
• Correcao: Verificar logs web, considerar rate limiting/WAF/cache

Padrao 3: Muitos workers (php-fpm, etc.)

• Processos filhos crescendo continuamente, consumindo CPU e memoria
• Correcao: Definir limites de workers (MaxChildren, etc.)

Padrao 4: I/O esta lento, entao CPU parece alta

• %wa esta alto
• Correcao: Investigar I/O de disco

8. O que evitar

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

Nao faca: Reiniciar sem salvar evidencias

No minimo, capture estes antes de decidir:

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

Nao faca: Escalar CPU sem verificar %wa

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

Nao faca: Deixar configuracoes de workers sem limite

O sistema vai quebrar no momento em que o trafego 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