Troubleshooting de Memoria no Ubuntu - Guia de free, top, ps e OOM Killer

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

O Que Voce Vai Aprender

• Como determinar se a lentidao/crashes do servidor sao causados por problemas de memoria
• Como identificar processos que consomem muita memoria
• Como verificar se o OOM Killer (SO mata processo por falta de memoria) foi acionado
• Ir alem de "so reiniciar" para prevenir recorrencia

1. Sintomas de Problemas de Memoria

Conclusao: Crashes, SSH lento e 502/503 sao sintomas de memoria — verifique memoria primeiro.

"Problemas de memoria" podem se manifestar de varias formas:

• Servidor extremamente lento (SSH lento, comandos travam)
• Aplicacoes crasham repentinamente / aumento de 502/503
• Processos morrem inesperadamente (erros nos logs)
• Mesmo problema recorre apos reiniciar

2. free -h para Visao Geral (Primeiro Passo)

Conclusao: No free -h, available baixo ou swap crescente sao os sinais de perigo mais claros.

$ free -h

Exemplo de saida:

              total        used        free      shared  buff/cache   available
Mem:           2.0Gi       1.9Gi        30Mi       120Mi        70Mi        80Mi
Swap:          1.0Gi       1.0Gi         0Mi

Pontos chave:

• available: Estimativa real de memoria utilizavel (pequeno = problema)
• Swap: Se swap esta quase cheio, perigo (swap thrashing causa lentidao extrema)

Diretrizes aproximadas:

• available em poucas dezenas de MB -> Muito perigoso (OOM ou lentidao extrema provavel)
• Swap continua crescendo -> Causa raiz provavelmente nao tratada

3. top para Encontrar o "Culpado Atual" (Olhe o RES)

Conclusao: No top, ordene por M e verifique RES — mostra a memoria real usada por processo.

$ top

O que iniciantes devem observar:

• %MEM: Percentual de uso de memoria
• RES: Uso real de memoria (importante)
• %CPU: Percentual de uso de CPU

Atalhos do top:

• M: Ordenar por memoria
• P: Ordenar por CPU
• q: Sair

4. ps para Lista dos Maiores Consumidores (Criar Evidencia)

Conclusao: Execute ps aux --sort=-%mem | head -n 20 e salve a saida antes de qualquer reinicio.

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

Verifique tambem os maiores consumidores de CPU para comparacao:

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

Padroes comuns:

• Um processo gigante (ex: java, node, php-fpm, python, db)
• Muitos do mesmo tipo (worker descontrolado, proliferacao de processos)
• Containers Docker se multiplicando

5. Verificar Atividade do OOM Killer (Frequentemente Decisivo)

Conclusao: Execute journalctl -k | grep -i oom — o log do OOM Killer nomeia o processo morto.

OOM Killer significa "o SO ficou sem memoria e matou um processo a forca". Causa muito comum de morte subita de processos.

5-1. Pesquisar Logs do Kernel (Recomendado)

$ sudo journalctl -k | grep -i oom | tail -n 50

5-2. Pesquisar por "killed process"

$ sudo journalctl -k | grep -i "killed process" | tail -n 50

5-3. dmesg Tambem Funciona

$ dmesg | grep -i oom | tail -n 50

Log tipico:

Out of memory: Killed process 1234 (node) total-vm:... anon-rss:...

O nome do processo morto aparece aqui. Esse e o principal suspeito.

6. Tipos de Problemas de Memoria (A Resposta Difere)

Conclusao: Classifique como pico, vazamento ou proliferacao — cada tipo requer uma correcao diferente.

Tipo A: Pico Temporario (Burst)

• Processamento em lote, agregacao pesada, processamento de imagem, etc.
• Correcao: Isolar processamento, ajuste de limites de memoria/quantidade de workers, adicionar swap, escalar verticalmente

Tipo B: Vazamento / Continua Crescendo (Piora com o Tempo)

• Aplicacoes Node/Python/Java crescem ao longo de execucao prolongada
• Correcao: Investigar vazamento de memoria da aplicacao, design de reinicio de worker/processo, definir limites

Tipo C: Proliferacao de Processos (Fork Bomb / Workers Demais)

• Filhos php-fpm crescem demais, fila/trafego causa explosao de workers
• Correcao: Definir limites de processos filhos/workers, teste de carga, rate limiting

7. Passos de Recuperacao Rapida (Seguranca Primeiro)

Conclusao: Verifique logs antes de reiniciar — um reinicio que ajuda confirma que o problema recorre.

7-1. Se Voce Sabe Qual Servico Esta Pesado: Verifique Logs Primeiro

$ sudo journalctl -u nginx -n 200
$ sudo journalctl -u app -n 200

7-2. Reinicio de Servico (Ultimo Recurso Mas As Vezes Necessario)

$ sudo systemctl restart <service>
$ sudo systemctl status <service>

8. Swap Torna Tudo Extremamente Lento (Inferno de Swap)

Conclusao: Swap intenso cria um ciclo vicioso: pouca memoria gera I/O de disco, tornando tudo ainda mais lento.

Quando o swap cresce, falta de memoria -> I/O de disco -> ainda mais lento - um ciclo infernal.

$ free -h

Se o swap esta muito utilizado, isso e suficiente para saber.

9. Coisas a Evitar

Conclusao: Evite reiniciar-sem-log-de-OOM, tratar swap como permanente ou workers ilimitados.

Nao faca: Reiniciar Repetidamente Sem Olhar a Causa

Reiniciar sem verificar logs e OOM repete o mesmo acidente.

Nao faca: Pensar Que Swap e uma "Bala de Prata"

Swap e um alivio temporario, nao uma correcao de raiz. Tambem causa degradacao de performance.

Nao faca: Deixar Configuracoes de Worker/Processo Ilimitadas

php-fpm e workers de aplicacao sem limites vao consumir toda a memoria. Sempre defina limites.

# 1) Visao geral
free -h

# 2) Culpado atual (por memoria)
top

# 3) Lista dos maiores consumidores (evidencia)
ps aux --sort=-%mem | head -n 20

# 4) Evidencia de OOM (decisivo)
sudo journalctl -k | grep -i oom | tail -n 50
sudo journalctl -k | grep -i "killed process" | tail -n 50