Troubleshooting de Memória no Ubuntu - Guia de free, top, ps e OOM Killer

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

O Que Você Vai Aprender

• Como determinar se a lentidão/crashes do servidor são causados por problemas de memória
• Como identificar processos que consomem muita memória
• Como verificar se o OOM Killer (SO mata processo por falta de memória) foi acionado
• Ir além de "só reiniciar" para prevenir recorrência

1. Sintomas de Problemas de Memória

Conclusão: Crashes, SSH lento e 502/503 são sintomas de memória — verifique memória primeiro.

"Problemas de memória" podem se manifestar de várias formas:

• Servidor extremamente lento (SSH lento, comandos travam)
• Aplicações crasham repentinamente / aumento de 502/503
• Processos morrem inesperadamente (erros nos logs)
• Mesmo problema recorre após reiniciar

2. free -h para Visão Geral (Primeiro Passo)

Conclusão: No free -h, available baixo ou swap crescente são os sinais de perigo mais claros.

$ free -h

Exemplo de saída:

              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 memória utilizável (pequeno = problema)
• Swap: Se swap está quase cheio, perigo (swap thrashing causa lentidão extrema)

Diretrizes aproximadas:

• available em poucas dezenas de MB -> Muito perigoso (OOM ou lentidão extrema provável)
• Swap continua crescendo -> Causa raiz provavelmente não tratada

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

Conclusão: No top, ordene por M e verifique RES — mostra a memória real usada por processo.

$ top

O que iniciantes devem observar:

• %MEM: Percentual de uso de memória
• RES: Uso real de memória (importante)
• %CPU: Percentual de uso de CPU

Atalhos do top:

• M: Ordenar por memória
• P: Ordenar por CPU
• q: Sair

4. ps para Lista dos Maiores Consumidores (Criar Evidência)

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

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

Verifique também os maiores consumidores de CPU para comparação:

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

Padrões comuns:

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

5. Verificar Atividade do OOM Killer (Frequentemente Decisivo)

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

OOM Killer significa "o SO ficou sem memória e matou um processo à força". 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 Também Funciona

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

Log típico:

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

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

6. Tipos de Problemas de Memória (A Resposta Difere)

Conclusão: Classifique como pico, vazamento ou proliferação — cada tipo requer uma correção diferente.

Tipo A: Pico Temporário (Burst)

• Processamento em lote, agregação pesada, processamento de imagem, etc.
• Correção: Isolar processamento, ajuste de limites de memória/quantidade de workers, adicionar swap, escalar verticalmente

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

• Aplicações Node/Python/Java crescem ao longo de execução prolongada
• Correção: Investigar vazamento de memória da aplicação, design de reinicio de worker/processo, definir limites

Tipo C: Proliferação de Processos (Fork Bomb / Workers Demais)

• Filhos php-fpm crescem demais, fila/tráfego causa explosão de workers
• Correção: Definir limites de processos filhos/workers, teste de carga, rate limiting

7. Passos de Recuperação Rápida (Segurança Primeiro)

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

7-1. Se Você Sabe Qual Serviço Está Pesado: Verifique Logs Primeiro

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

7-2. Reinicio de Serviço (Último Recurso Mas Às Vezes Necessário)

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

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

Conclusão: Swap intenso cria um ciclo vicioso: pouca memória gera I/O de disco, tornando tudo ainda mais lento.

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

$ free -h

Se o swap está muito utilizado, isso é suficiente para saber.

9. Coisas a Evitar

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

Não faça: Reiniciar Repetidamente Sem Olhar a Causa

Reiniciar sem verificar logs e OOM repete o mesmo acidente.

Não faça: Pensar Que Swap é uma "Bala de Prata"

Swap é um alívio temporário, não uma correção de raiz. Também causa degradação de performance.

Não faça: Deixar Configurações de Worker/Processo Ilimitadas

php-fpm e workers de aplicação sem limites vão consumir toda a memória. 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