Por que seu servidor precisa de SWAP mesmo com espaço em disco: mecânica de kernel e setup de 4GB

SWAP não é só para RAM cheia: mecânica de kernel e o caso do setup de 4GB#

Durante uma verificação de rotina em um servidor de produção, analisei a ocupação de armazenamento com df -h:

Sist. Arq.      Tam. Usad Disp Uso% Montado em
/dev/sda5        99G   72G   28G  73% /
/dev/sda2       994M  661M  334M  67% /boot
/dev/sda1        99M  5.8M   94M   6% /boot/efi

A partição raiz possuía 28 GB disponíveis e a memória RAM estava estável. No entanto, um detalhe crítico chamou a atenção: não havia nenhuma área de troca (SWAP) ativa.

Uma dúvida comum surge diante desse cenário: "Se temos 28 GB livres e a memória RAM física não está esgotada, o SWAP é realmente necessário?"

A resposta é: sim. Abaixo, explico a mecânica de memória do kernel Linux por trás dessa decisão e como configurei um swapfile de 4 GB na prática.

1. O mito do SWAP como "apenas um estepe de RAM"#

Muitos enxergam o SWAP exclusivamente como uma extensão lenta para quando a memória física esgota. No kernel Linux, a função do SWAP vai além: ele é essencial para o balanceamento de páginas LRU (Least Recently Used).

Page cache (file-backed) vs. anonymous pages#

O kernel divide a memória principalmente em duas categorias:

1. Páginas apoiadas por arquivos (File-backed / Page Cache): Dados mapeados a partir do disco, como binários de programas, bibliotecas compartilhadas e scripts lidos pelo servidor web.
2. Páginas anônimas (Anonymous Pages): Memória alocada dinamicamente por processos em execução (heap, stack, buffers do banco de dados) que não possuem correspondência direta com um arquivo no disco.

Quando o host opera sem SWAP, o kernel fica impedido de descarregar páginas anônimas frias (inativas) para o disco. Para manter memória livre de trabalho, o sistema é obrigado a descartar agressivamente o Page Cache.

Isso gera um efeito colateral direto: a performance de leitura cai, pois binários e arquivos precisam ser relidos do disco repetidamente via I/O.

A equação de swappiness e o OOM killer#

No código-fonte do kernel (mm/vmscan.c), a rotina get_scan_count utiliza o valor de vm.swappiness (geralmente 60) para calcular a proporção entre escanear o cache de arquivos e as páginas anônimas. Com zero bytes de SWAP, essa fórmula fica desequilibrada.

Sob um pico repentino de conexões (rajadas no servidor web ou processos do banco de dados), o sistema pode acionar prematuramente o OOM Killer (Out Of Memory Killer), derrubando serviços essenciais como SSHD ou MySQL sem aviso prévio. Esse comportamento é especialmente comum em servidores que rodam runtimes como Node.js e Bun gerenciados via PM2 ou instâncias cloud como Oracle Cloud OCI.

2. Diagnóstico de baixo nível via terminal#

Para avaliar a pressão de memória antes de criar o swap:

A. Pressão de memória com PSI (pressure stall information)#

cat /proc/pressure/memory

B. Comportamento de paginação e i/o wait#

vmstat 1 10

Monitore as colunas si (swap-in), so (swap-out) e wa (I/O wait), confirmando se a ausência de SWAP não está elevando a fila de espera do disco.

C. Distribuição de páginas na memória#

grep -E 'AnonPages|Buffers|Cached' /proc/meminfo

3. Dimensionamento e matemática binária (4 gib)#

Para o ambiente, defini um swapfile de 4 GB:

• Base decimal (comercial): $4\text{ GB} = 4.000\text{ MB}$
• Base binária (kernel / MMU): $4\text{ GiB} = 4 \times 1024\text{ MiB} = 4.096\text{ MiB}$ (ou $4.194.304\text{ KB}$)

Como a MMU da arquitetura x86_64 gerencia páginas em blocos de 4 KB, alocar em potência binária garante o alinhamento exato de blocos.

4. Criando e ativando o swapfile#

Passo 1: Alocar o espaço com fallocate#

O comando fallocate aloca os blocos instantaneamente no filesystem (EXT4/XFS):

sudo fallocate -l 4G /swapfile

Passo 2: Ajustar permissões estritas#

Como o arquivo conterá páginas de memória em execução, o acesso deve ser restrito exclusivamente ao root:

sudo chmod 600 /swapfile

Passo 3: Formatar e ativar#

sudo mkswap /swapfile
sudo swapon /swapfile

Valide com:

swapon --show
free -h

Passo 4: Persistir a montagem no boot#

Adicione a entrada ao /etc/fstab:

/swapfile swap swap defaults 0 0

5. Casos de borda e boas práticas#

1. Fragmentação de blocos: Para verificar se o arquivo foi alocado de forma contígua no disco, execute filefrag -v /swapfile.
2. Armazenamento rápido vs. Thrashing: Em discos NVMe ou SSD, a paginação esporádica é quase imperceptível. O SWAP atua estritamente como amortecedor de segurança para manter o Page Cache saudável na memória física.

Lições práticas sobre gerenciamento de memória#

1. SWAP não é apenas para quando a RAM acaba: Ter área de troca permite ao kernel preservar o Page Cache e otimizar a velocidade de I/O em todo o sistema operacional.
2. Use fallocate e chmod 600: A alocação rápida poupa tempo e a restrição de permissão impede que usuários sem privilégios leiam páginas de memória salvas em disco.
3. Persista sempre no /etc/fstab: Certifique-se de registrar o swapfile no arquivo de montagem para garantir resiliência após reinicializações.

Veja também

Linux Desmistificando o tmpfs: reduzir partições temporárias realmente libera RAM no Linux?

Servidores Debugging de baixo nível no CloudLinux: syscalls, LVE e o perigo dos limites ilimitados

DevOps Quando o VS code remote e o antigravity quase derrubaram meu servidor: anatomia de um thrashing de memória

Este post está licenciado sob CC BY-NC.