zram mais swapfile: duas camadas de swap num Debian com 8 GB

Duas camadas de memória — zram e swapfile — empilhadas e ligadas por fluxos de dados

Este blog tem o nome que tem porque quase tudo aqui nasce com um café ao lado. Este artigo nasceu de um problema mais mundoso: um portátil com 8 GB de RAM, o Debian, e a pergunta de sempre — preciso de swap? Com quanto? Em disco ou em RAM?

O problema do swap clássico

Swap em disco é lenta por definição. Num SSD NVMe até engana, mas apanha dez páginas de RAM por segundo no pior momento possível: quando o sistema já está a sufocar. O truque clássico é baixar a swappiness para o kernel quase ignorar o swap. Funciona, mas é um esforço para evitar uma coisa que, bem feita, até ajuda.

zram: swap comprimida em RAM

O zram faz o contrário: cria um dispositivo de bloco na RAM que funciona como swap, comprimindo tudo o que lá entra. A memória “perdida” pelo swap passa a ser comprimida em vez de escrita em disco, e o acesso é ordens de magnitude mais rápido que qualquer SSD.

No Debian, o pacote é systemd-zram-generator, e a configuração é um único ficheiro:

# /etc/systemd/zram-generator.conf
[zram0]
zram-size = min(min(ram, 4096) + max(ram - 4096, 0) / 2, 32 * 1024)
zram-resident-limit = ram / 4
compression-algorithm = zstd
swap-priority = 100

A fórmula do zram-size vem do upstream: os primeiros 4 GB de RAM contam a 100%, o resto a 50%, com tecto de 32 GB. Neste host de 7,7 GB dá um dispositivo de 5,8 GB.

Duas linhas merecem explicação:

• zram-resident-limit = ram / 4 é o travão de segurança: a swap comprimida nunca ocupa mais de 25% da RAM física. Sem ele, uma carga com dados pouco comprimíveis (vídeos, dados já comprimidos) pode encher o dispositivo e competir com a própria carga por memória — espiral de morte por falta de RAM.
• swap-priority = 100 dá a prioridade do dispositivo: o kernel usa sempre o swap de prioridade mais alta primeiro. O zram fica à frente de tudo.

O zramctl mostra o efeito real no meu caso:

NAME       ALGORITHM DISKSIZE   DATA COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd          5.8G 549.4M  120M 124.9M         [SWAP]

549 MB de dados ocupam 125 MB de RAM. Razão de compressão de ~4,4:1. Isso significa que o zram está a dar-me ~4,4 GB de espaço de swap a custo de 125 MB de RAM. Nenhum SSD faz isso.

A segunda camada: swapfile em disco

O zram tem um limite físico óbvio: só tem 5,8 GB, e a memória comprimida ocupa RAM. Se a carga passar o dispositivo, sem segunda camada o OOM killer entra. A solução barata é um swapfile em disco com prioridade baixa:

# /etc/fstab — camada lenta (segunda linha de defesa)
/swapfile none swap sw,pri=10 0 0

Criar o swapfile é o ritual de sempre:

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

O swapon –show mostra as duas camadas e quem estão a ser usadas:

NAME       TYPE      SIZE   USED PRIO
/swapfile  file        4G     0B   10
/dev/zram0 partition 5.8G  633.3M  100

O zram tem 633 MB em uso; o swapfile está a 0. É exatamente o comportamento desejado: o kernel esgota a camada rápida antes de tocar no lenta.

swappiness=100 (sim, a subir)

Aqui entra a parte contraintuitiva. Todos os guias dizem: swappiness=10, o kernel evita swap. Mas esses guias assumem que swap é lenta. Com zram, swap é rápida — e deixar as páginas menos usadas irem dormir comprimidas em RAM liberta memória para cache de ficheiros, que é onde os sistemas Linux ganham desempenho.

Neste host a swappiness está em 100, e o sistema está vivo e agradável:

cat /proc/sys/vm/swappiness   # 100

A regra prática: zram com swappiness alta funciona bem. Swap em disco com swappiness alta, não. O valor 100 empurra as páginas frias para o zram cedo, o que é bom quando o destino é comprimido e rápido.

Quando não fazer isto

O zram não é magia universal. Se o teu consumo real ultrapassa sistematicamente o que a compressão consegue, vai acabar no swapfile tão ou mais vezes que no zram, e o disco torna-se o gargalo outra vez. Nesse caso o problema é a RAM, e o zram só adia a conversa com o orçamento.

Também vale atenção em sistemas muito curtos de RAM (raspberries antigos, VPS pequenos): o zram-generator é elegante mas não contorna pouca RAM — só a usa melhor.

Resumo

• zram-generator + fórmula de upstream: dispositivo de ~6 GB num sistema de 8 GB
• zram-resident-limit como travão físico (25% da RAM)
• swapfile em disco como segunda camada, com prioridade baixa (pri=10)
• swappiness=100 quando a camada principal é zram
• compressão medida: 549 MB de dados em 125 MB de RAM (~4,4:1)

Tudo isto numa máquina que já se habituou a viver com menos RAM do que as aplicações querem. Funciona.