Entenda o uso de RAM no Linux, descubra se o OOM killer encerrou processos, configure swap e swappiness e proteja serviços críticos e VMs no Proxmox.

Para que serve

Quando a memória RAM acaba, o kernel do Linux aciona o OOM killer (out of memory), que encerra à força o processo que considera mais "pesado". Em servidores, a vítima costuma ser justamente o banco de dados, a aplicação principal ou, no Proxmox, uma VM inteira. Este artigo explica como ler o uso de memória sem se assustar com números enganosos, como configurar a swap e como descobrir e evitar encerramentos por falta de memória.

Pré-requisitos

  • Acesso root.
  • Debian 12/13, Ubuntu 24.04 ou Proxmox VE 8/9.

Passo a passo para evitar o OOM killer

1. Ler o uso de memória corretamente

free -h

A coluna que importa é available: é quanto ainda pode ser usado por novos processos. O valor de free costuma ser baixo e isso é normal, porque o Linux usa a RAM sobrando como cache de disco (buff/cache) e a devolve quando alguém precisa.

Para ver quem consome mais:

ps aux --sort=-rss | head -15
top -o %MEM

Em hosts Proxmox, considere também:

  • ZFS ARC: o cache do ZFS aparece como memória "usada", não como cache. Veja o tamanho com arc_summary | head -40 ou arcstat. Desde o Proxmox VE 8.1, instalações novas limitam o ARC a 10% da RAM (até 16 GiB). Em instalações mais antigas ou sem esse limite, o padrão do OpenZFS deixa o ARC ocupar metade da RAM ou mais, conforme a versão; confira o valor atual em /sys/module/zfs/parameters/zfs_arc_max (0 significa padrão) e ajuste em /etc/modprobe.d/zfs.conf com options zfs zfs_arc_max=VALOR_EM_BYTES e rode update-initramfs -u.
  • Soma da RAM das VMs: se a memória configurada das VMs, mais o ARC, mais o próprio host passar da RAM física, o OOM killer vai agir. Deixe folga de alguns GB para o host.

No Debian 13, o diretório /tmp passou a ficar em memória (tmpfs), podendo usar até metade da RAM. Aplicações que gravam arquivos grandes em /tmp passam a consumir memória. Para limitar o tamanho, use systemctl edit tmp.mount; para voltar ao /tmp em disco, systemctl mask tmp.mount e reinicie.

2. Descobrir se o OOM killer agiu

journalctl -k | grep -iE 'out of memory|oom-kill|killed process'
dmesg -T | grep -i oom

A mensagem mostra o processo encerrado e quanta memória ele usava. Serviços gerenciados pelo systemd também registram status=9/KILL ou oom-kill em systemctl status nome. Em hosts Proxmox, a VM vítima simplesmente aparece desligada, e o log mostra o processo kvm encerrado.

3. Verificar e criar swap

swapon --show

A swap não substitui RAM: um servidor que usa muita swap fica lento. Ela serve como margem de segurança para picos e para tirar da RAM páginas que quase nunca são usadas. Para servidores com 128–192 GB de RAM, uma swap de 4 a 8 GB costuma ser suficiente.

Para criar um arquivo de swap em ext4 ou XFS:

fallocate -l 8G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
Não crie swap dentro de ZFS (nem em arquivo, nem em zvol). Isso pode travar o servidor sob pressão de memória. Em hosts Proxmox com ZFS, use uma partição dedicada fora do pool ou fique sem swap e dimensione bem a RAM e o ARC.

4. Ajustar a swappiness

O parâmetro vm.swappiness (padrão 60) define o quanto o kernel prefere usar swap em vez de descartar cache. Em servidores, um valor baixo mantém as aplicações na RAM:

echo 'vm.swappiness = 10' > /etc/sysctl.d/99-swappiness.conf
sysctl --system

No Debian 13, o arquivo /etc/sysctl.conf não é mais lido; use sempre arquivos em /etc/sysctl.d/.

5. Proteger serviços críticos

O OOM killer escolhe a vítima com base em uma pontuação (/proc/PID/oom_score). Você pode reduzir a chance de um serviço importante ser escolhido, ou aumentar a de um serviço secundário, com um override do systemd:

systemctl edit postgresql
[Service]
OOMScoreAdjust=-500

Valores vão de −1000 (nunca encerrar) a 1000. Não use −1000 em tudo: se nenhum processo puder ser encerrado, o servidor pode travar por completo. Para conter um serviço que vaza memória, limite-o:

[Service]
MemoryMax=4G

Com isso, quem é encerrado ao atingir o limite é o próprio serviço, e não o resto do servidor.

6. Ajustar a aplicação

Na maioria dos casos, a solução definitiva está na configuração da aplicação: innodb_buffer_pool_size do MySQL/MariaDB, shared_buffers e work_mem do PostgreSQL, -Xmx do Java, número de workers do PHP-FPM. Some os máximos de tudo o que roda no servidor e compare com a RAM disponível. Para os bancos, veja também os artigos «Tuning PostgreSQL: como ajustar shared_buffers, work_mem e effective_cache_size» e «Tuning MySQL e MariaDB: como ajustar o my.cnf e o innodb_buffer_pool_size para sites».

Como saber se funcionou

  • swapon --show lista a swap ativa e cat /proc/sys/vm/swappiness mostra o valor novo.
  • systemctl show postgresql -p OOMScoreAdjust -p MemoryMax mostra os valores aplicados.
  • Acompanhe por alguns dias: journalctl -k --since "7 days ago" | grep -i oom deve vir vazio.

Problemas comuns

  • swapon: /swapfile: insecure permissions: rode chmod 600 /swapfile.
  • swapon: Invalid argument com fallocate: alguns sistemas de arquivos não aceitam arquivos criados assim. Crie com dd if=/dev/zero of=/swapfile bs=1M count=8192.
  • Swap sempre cheia, mas available alto: são páginas pouco usadas que foram para a swap e não precisaram voltar. Não é problema se o servidor não estiver lento.
  • Servidor lento com muita atividade de swap (si/so altos em vmstat 1): falta RAM de verdade. Reduza o consumo ou redistribua as VMs.
  • VM do Proxmox desligando sozinha: quase sempre é OOM no host. Reduza a RAM das VMs, limite o ARC ou ative o ballooning nas VMs que suportam.

Perguntas frequentes

Como saber se o OOM killer encerrou um processo?

Procure no log do kernel com journalctl -k | grep -iE 'out of memory|oom-kill'. A mensagem mostra o processo encerrado e quanta memória ele usava.

Por que o Linux mostra quase toda a RAM em uso?

Porque usa a memória livre como cache de disco e a devolve quando precisa. Olhe a coluna available do free -h, não a free.

Quanto de swap colocar em um servidor com muita RAM?

Em servidores com 128 a 192 GB de RAM, 4 a 8 GB de swap costumam bastar como margem para picos. Swap não substitui RAM.

Dá para desativar o OOM killer?

Não é recomendado. O caminho é proteger serviços críticos com OOMScoreAdjust, limitar os que vazam memória com MemoryMax e ajustar a configuração das aplicações.

Por que uma VM do Proxmox desliga sozinha?

Quase sempre é o OOM killer do host encerrando o processo kvm da VM. Reduza a RAM das VMs, limite o ARC do ZFS ou ative o ballooning.

Leitura complementar

Precisa de ajuda?

Se processos estão sendo encerrados e você não identifica a causa, abra um ticket com a saída de free -h, ps aux --sort=-rss | head -15 e as mensagens de OOM do journalctl -k.

Esta resposta lhe foi útil? 0 Usuários acharam útil (0 Votos)

Leia também