Porque o Linux OOM Killer Matou a Tua Base de Dados: Memória RAM, Page Cache, ZRAM e Swap Explicados

A Morte Súbita de uma Base de Dados em Produção

Se geres servidores Linux, mais cedo ou mais tarde vais deparar-te com este cenário de terror: às 14:22, o teu PostgreSQL desaparece subitamente com o código de erro 137. Não há registos de erros no log da base de dados nem falhas na aplicação. Quando corres o comando dmesg -T no terminal, descobres a causa:

[Mon Oct 19 14:22:15 2026] Out of memory: Killed process 41829 (postgres) total-vm:18492040kB, anon-rss:8192000kB, file-rss:1024kB, shmem-rss:4096000kB
[Mon Oct 19 14:22:15 2026] oom_reaper: reaped process 41829 (postgres), now anon-rss:0kB

O infame Out-Of-Memory (OOM) Killer do kernel do Linux executou a tua base de dados sumariamente com um sinal SIGKILL. Porque é que o sistema operativo decidiu assassinar o serviço mais crítico da tua empresa em vez de fechar um script secundário de relatórios ou um agente de métricas?

COMO O LINUX OOM KILLER ESCOLHE A VÍTIMA

• A Memória RAM Esgota-se (O Kernel Falha ao Alocar Novas Páginas)
• O Kernel Executa o Algoritmo select_bad_process()
• Calcula a Pontuação: (anon-rss + shmem-rss) * oom_score_adj
• Script Secundário de Python: 300MB: Pontuação de Risco: 18
• PostgreSQL: 12GB de Cache: Pontuação de Risco: 750
• MAIOR PONTUAÇÃO!
• MORTO COM SINAL SIGKILL 9

Na Webxtek, desenhamos sistemas com profunda consideração pela gestão de memória no kernel. Com o nosso serviço de alojamento gerido e apoio em consultoria técnica, ajustamos os parâmetros do sistema operativo para impedir paragens catastróficas.

Como o Linux Gere a Memória: Páginas Anónimas vs. Page Cache

Para compreenderes as decisões do kernel, precisas de saber como o Debian organiza a memória física. O Linux divide a memória em dois grupos principais:

1. Memória Anónima (anon): É a memória alocada pelas tuas aplicações (variáveis, objetos em PHP/Node.js, estruturas de dados). Chama-se anónima porque não tem nenhum ficheiro no disco que lhe corresponda. Para libertar esta memória, o kernel tem obrigatoriamente de a escrever no Swap.
2. Page Cache (file): É a memória que o kernel usa para guardar cópias de ficheiros lidos do disco (código, tabelas de bases de dados, imagens). Como estes dados já existem no disco, o kernel pode simplesmente deitá-los fora (evicção) em frações de microssegundo para dar espaço a outros processos.

DIVISÃO REAL DA MEMÓRIA RAM NO LINUX TOTAL DA TUA MEMÓRIA RAM

• MEMÓRIA ANÓNIMA (Heap): Variáveis e Sessões Web • Buffers Partilhados da DB • Não pode ser apagada! Exige SWAP
• PAGE CACHE (Ficheiros): Cópia de Ficheiros Lidos do Disco • Ficheiros Estáticos do Nginx • Pode ser descartada no instante!

Quando um painel de monitorização te diz que o teu servidor só tem “5% de RAM livre”, na maioria dos casos está a interpretar mal a Page Cache. O Linux aproveita toda a RAM desocupada para acelerar leituras de ficheiros. O perigo só surge quando a Memória Anónima cresce tanto que esmaga a Page Cache contra a parede.

O Mito de Desligar o Swap: Porque Precisas do vm.swappiness

Existe um mito muito espalhado entre programadores que recomenda desligar o swap (swapoff -a) com a ideia de que “o swap é lento, por isso sem swap o servidor fica mais rápido”.

Isto é um erro grave. Quando desligas o swap, o kernel perde a capacidade de empurrar dados frios da memória anónima (como processos de arranque que já não fazem nada) para fora da RAM. Com a memória apertada, o kernel é obrigado a apagar toda a Page Cache. Qualquer leitura ao disco passa a demorar milissegundos e, se a memória sofrer um pico de apenas 20MB, o sistema entra em pânico e chama o OOM Killer imediatamente.

Em vez de desligares o swap, deves afinar a agressividade com o parâmetro vm.swappiness:

# /etc/sysctl.d/99-ajustes-memoria.conf

# Reduz a agressividade de swap para preservar a Page Cache (padrão é 60)
vm.swappiness = 10

# Impede o kernel de aceitar mais memória do que a máquina aguenta
vm.overcommit_memory = 2
vm.overcommit_ratio = 80

# Controla a frequência de gravação de dados sujos no disco
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

Aplica os ajustes no terminal: sysctl -p /etc/sysctl.d/99-ajustes-memoria.conf.

ZRAM: Memória Comprimida em RAM sem Lentidão de Disco

A forma mais moderna e eficiente de proteger servidores Linux contra esgotamento de memória é ativar o ZRAM. Em vez de enviares páginas de memória para um ficheiro lento no disco SSD, o ZRAM cria um dispositivo de bloco comprimido diretamente dentro da tua memória RAM.

Quando a máquina sente pressão de memória, o kernel comprime as páginas frias com algoritmos ultra-rápidos como LZ4 ou ZSTD numa razão média de 3 para 1 em menos de dois microssegundos. Um bloco de 4GB em ZRAM consegue guardar até 12GB de dados reais sem gastar ciclos de I/O em discos físicos.

CICLO DE COMPRESSÃO ULTRA-RÁPIDO COM ZRAM

• Aplicação Precisa de RAM → Memória Física Apertada!
• O Kernel Envia Páginas Frias para o /dev/zram0
• O Algoritmo ZSTD Comprime a Página: 4KB → 1.3KB (Dentro da Própria RAM!)
• Memória Limpa Libertada Imediatamente com ZERO Lentidão de Disco!

Configura o ZRAM no teu servidor Debian:

# Instala o pacote de gestão do ZRAM
apt-get install -y zram-tools

# Configura o ficheiro /etc/default/zramswap
cat <<EOF > /etc/default/zramswap
ALGO=zstd
PERCENT=50
PRIORITY=100
EOF

# Reinicia o serviço do zram
systemctl restart zramswap

# Confirma o estado do dispositivo comprimido
zramctl

Proteger Serviços Críticos com o OOMScoreAdjust do systemd

Para garantires que o teu PostgreSQL ou Nginx nunca são escolhidos como vítimas sacrificiais pelo OOM Killer, podes ajustar manualmente a pontuação de prioridade através do systemd. A escala varia entre -1000 (imune à morte) e +1000 (primeiro a ser morto).

Cria uma regra de sobreposição para a tua base de dados:

# /etc/systemd/system/postgresql.service.d/override.conf
[Service]
# Dá imunidade quase total ao PostgreSQL contra o OOM Killer
OOMScoreAdjust=-900

Aplica a nova regra:

systemctl daemon-reload
systemctl restart postgresql

Em contrapartida, se tiveres scripts pesados de recolha de dados ou rotinas de teste, deves configurá-los com OOMScoreAdjust=500. Desta forma, se a memória do servidor chegar ao limite, o kernel encerra os processos não essenciais, mantendo a tua loja online e a tua base de dados a funcionar com total tranquilidade.

Aliando esta parametrização cirúrgica aos nossos contratos contínuos de manutenção de servidores, garantes que a tua infraestrutura Linux opera estável, rápida e imune a falhas de memória imprevistas.

Na prática, aplicas exatamente estes padrões operacionais em setores exigentes como provedores de cloud computing e iaas e especialistas em devops e arquitetura cloud. Quando alinhas a tua estrutura através de alojamento gerido para websites e aplicações e consultoria técnica antes de construir, transformas boas práticas técnicas numa vantagem competitiva real e mensurável para o teu negócio.