zram vs zswap: como otimizar a memória RAM no Linux

Ao analisar as estratégias de gestão de memória no Linux moderno, o embate zram vs zswap é uma das discussões mais relevantes para quem busca extrair o máximo de desempenho de um desktop ou servidor. Em cenários de alta carga, quando múltiplas instâncias de compilação, contêineres e navegadores devoram a RAM física, o subsistema de memória do kernel precisa decidir o que fazer com as páginas frias. A resposta tradicional — escrever diretamente no swap em SSD ou NVMe — introduz latências indesejadas e desgasta a vida útil do armazenamento. As duas soluções de compressão em memória resolvem esse problema por caminhos completamente diferentes.

Ambas as tecnologias utilizam ciclos de CPU para comprimir páginas anônimas de memória antes que elas causem pressão no sistema, mas os seus mecanismos internos, integrações com o subsistema de memória virtual (VMM) e comportamentos em falha crítica não poderiam ser mais distintos. Entender essa arquitetura é fundamental para não cair na armadilha de configurar o recurso errado para a sua carga de trabalho.

Por que a compressão de RAM tornou-se indispensável no Linux?

À medida que o consumo de memória das aplicações cresce, depender exclusivamente do swap em disco cria gargalos severos de entrada e saída (I/O). Mesmo em drives NVMe modernos com altas taxas de transferência, a latência de acesso aos blocos de armazenamento é ordens de grandeza superior aos tempos de acesso do barramento de RAM. Quando o kernel Linux precisa fazer o pageout de memória anônima para o disco, o processo solicitante é colocado em estado de espera, gerando travamentos visíveis na interface ou aumento de latência em APIs.

A compressão de páginas aproveita o excesso de poder de processamento das CPUs modernas com muitos núcleos. Algoritmos como o zstd (Zstandard) oferecem taxas de compressão excelentes com uma velocidade de descompressão extremamente alta. Comprimindo páginas anônimas inativas e mantendo-as na própria memória RAM, o sistema consegue acomodar substancialmente mais dados antes de precisar tocar no disco rígido ou no SSD.

Distribuições modernas, como o Ubuntu 26.04.1 e o Debian 13.7, adotam posturas variadas quanto à configuração padrão desses subsistemas. Enquanto o ecossistema desktop migrou fortemente para o uso do zram visando simplificar a instalação sem necessidade de partições dedicadas, ambientes de servidor e sistemas de virtualização demandam uma análise mais criteriosa da arquitetura de swap.

O que é o zram e como ele transforma memória RAM em swap?

O zram é um módulo do kernel Linux que cria um dispositivo de bloco virtual diretamente na RAM. Para o subsistema de armazenamento e para os utilitários de sistema (swapon, mkswap), esse dispositivo se comporta exatamente como um disco físico ou partição de swap tradicional. As páginas enviadas para ele são comprimidas em tempo real pelo kernel e armazenadas no espaço alocado do zram.

A grande característica do zram é ser uma solução autosuficiente (standalone). Ele não requer um dispositivo de swap físico em disco por trás de si. Quando você aloca 8 GB de swap em zram, o módulo reserva uma fatia dinâmica da memória RAM física para armazenar esses dados comprimidos. Se uma página de 4 KB for comprimida para 1 KB, o sistema economizou 3 KB de espaço real.

Em distribuições modernas mantidas com systemd, a criação e inicialização de dispositivos zram é automatizada pelo systemd-zram-generator. A configuração é feita por meio de arquivos declarativos simples localizados no diretório /etc/systemd/.

# /etc/systemd/zram-generator.conf
[zram0]
zram-size = ram / 2
compression-algorithm = zstd
swap-priority = 100

Neste exemplo, o generator cria o dispositivo /dev/zram0 no momento do boot com tamanho equivalente à metade da RAM física, utilizando o algoritmo zstd e prioridade 100 no subsistema de swap. A facilidade de implantação torna o zram imbatível em sistemas sem partição de swap no disco.

Quais são os riscos e a armadilha de inversão LRU no zram?

Apesar da simplicidade, o zram possui uma limitação arquitetural severa: ele é um dispositivo de bloco cego. O kernel trata o zram como um destino final de swap. Quando o zram atinge a sua capacidade máxima alocada, ele não possui um mecanismo nativo para retirar (evict) automaticamente as páginas mais antigas e migrá-las para um swap em SSD secundário.

Se você tentar combinar o zram (com prioridade alta) com um swap em disco físico (com prioridade baixa), enfrentará o fenômeno conhecido como inversão LRU (Least Recently Used). No início, o zram será preenchido com páginas frias (pouco acessadas). Quando o zram encher completamente, o kernel começará a enviar as novas páginas para o swap em disco. O resultado é desastroso: as páginas mais antigas e frias permanecem ocupando a valiosa RAM comprimida no zram, enquanto as páginas de uso recente terminam gravadas no SSD lento. Se a memória estourar de vez, o mecanismo de Out-Of-Memory (OOM Killer) será disparado.

O que é o zswap e como ele atua como cache do swap físico?

Diferente do zram, o zswap não é um dispositivo de bloco virtual. O zswap é uma camada de cache comprimido que se posiciona diretamente na frente do subsistema de swap físico do kernel. Ele intercepta as páginas de memória anônima que o kernel decidiu gravar no swap e tenta comprimi-las antes que cheguem ao disco.

Quando o kernel Linux decide enviar uma página para o swap, o zswap intercepta essa chamada. Se a página for compressível, ela é armazenada em uma piscina de memória dinâmica (zpool) mantida na RAM. Se o zswap ficar cheio ou se a página não for facilmente compressível, o zswap faz o writeback: ele desprime ou simplesmente repassa a página diretamente para o dispositivo de swap físico configurado no sistema (seja uma partição NVMe ou um arquivo de swapfile).

Essa integração profunda com a gestão de memória do kernel garante que o zswap respeite o ciclo de vida LRU de ponta a ponta. Páginas verdadeiramente inativas são eventualmente gravadas no disco pelo mecanismo de eviction, liberando espaço na RAM comprimida para dados que estão em uso mais frequente.

O zswap é configurado via parâmetros do kernel na inicialização ou em tempo de execução inspecionando e alterando os arquivos em /sys/module/zswap/parameters/.

# Verificar se o zswap está ativo no kernel
cat /sys/module/zswap/parameters/enabled

# Alterar o compressor padrão para zstd em tempo de execução
echo zstd | sudo tee /sys/module/zswap/parameters/compressor

# Definir o limite máximo de RAM que o zswap pode ocupar (ex: 20%)
echo 20 | sudo tee /sys/module/zswap/parameters/max_pool_percent

Essa dinâmica faz do zswap a escolha predileta para servidores e estações de trabalho que possuem partições de swap dedicadas e SSDs de altíssimo desempenho.

Como comparar zram vs zswap na arquitetura do kernel Linux?

Para tomar uma decisão técnica embasada, é preciso analisar como cada tecnologia se comporta em diferentes critérios de infraestrutura e gestão de recursos. A tabela abaixo resume as principais divergências estruturais entre o zram e o zswap.

A análise técnica revela que o zram isola o gerenciamento dentro de um dispositivo de bloco montado pelo usuário ou sistema. Já o zswap atua como uma extensão direta da camada de paginação anônima. Em ambientes de contêineres e servidores sob gerenciamento rígido do cgroups v2, o zswap se destaca por permitir que a contabilidade de memória por contêiner acompanhe com exatidão o uso real, enquanto o zram aloca memória de bloco que é contabilizada de forma genérica no kernel.

Além disso, a alocação de CPU varia conforme a taxa de churn de memória. O zram tende a apresentar menor overhead de escrita inicial por não possuir a lógica de decisão de writeback, enquanto o zswap protege o sistema contra cenários onde a RAM fica totalmente esgotada por páginas frias inamovíveis.

Qual tecnologia escolher para desktop, servidores e containers?

A escolha da tecnologia ideal depende diretamente da topologia de hardware e do perfil das cargas de trabalho operadas na máquina.

Caso 1: Estações de Trabalho e Laptops de Uso Geral

Para desktops de desenvolvimento, laptops com SSDs limitados ou dispositivos embarcados (como placas single-board e mini PCs), o zram é quase sempre a escolha superior. Em máquinas sem partição de swap dedicada, o zram provê uma rede de segurança instantânea contra travamentos por estouro de memória sem ocupar espaço precioso no armazenamento secundário.

A recomendação prática para esse cenário é ativar o systemd-zram-generator configurado com 50% da memória RAM física e algoritmo zstd, desativando arquivos de swap em disco para evitar conflitos de LRU.

Caso 2: Servidores de Produção e Workstations de Alta Performance

Em servidores bare-metal, nós de virtualização e máquinas de trabalho pesadas dotadas de drives NVMe rápidos, o zswap é o vencedor claro. Como esses ambientes geralmente já contam com arquivos ou partições de swap dedicadas para garantir a estabilidade do sistema sob estresse contínuo, colocar o zswap na frente desse armazenamento reduz dramaticamente a taxa de gravação no SSD sem perder a capacidade de escoar dados em picos de consumo extremos.

O zswap garante que a máquina sobreviva a surtos imprevistos de tráfego ou vazamentos de memória temporários sem travar o barramento I/O nem causar desalocação abrupta de contêineres.

Ajustes de Kernel Importantes: O Valor do Swappiness

Independentemente de escolher zram ou zswap, o parâmetro vm.swappiness no kernel Linux deve ser ajustado para refletir a presença da compressão ultra-rápida. O valor padrão histórico (vm.swappiness = 60) foi desenhado para discos mecânicos lentos.

Ao utilizar compressão de RAM, é recomendável elevar o valor de swappiness para incentivar o kernel a descarregar páginas anônimas inativas antecipadamente, liberando RAM não comprimida para o cache de arquivos (page cache).

# Aplicar swappiness agressivo adequado para RAM comprimida
sudo sysctl vm.swappiness=100

# Tornar a configuração permanente em /etc/sysctl.d/99-memory-tuning.conf
echo "vm.swappiness=100" | sudo tee /etc/sysctl.d/99-memory-tuning.conf

# Recarregar os parâmetros sem precisar reiniciar a máquina
sudo sysctl --system

Vale lembrar que o teto do vm.swappiness deixou de ser 100. Desde o kernel 5.8 o valor aceito vai até 200, e faixas entre 100 e 180 são comuns em sistemas com zram, justamente porque o custo de "gravar" uma página comprimida na RAM é irrisório perto de uma escrita real no armazenamento. Acima de 100, o kernel passa a favorecer explicitamente o descarte de páginas anônimas em vez do descarte do cache de arquivos.

Há um segundo parâmetro que costuma passar despercebido e que pesa tanto quanto o swappiness:

# Desliga o readahead do swap: com compressão, ler oito páginas para usar uma é desperdício
sudo sysctl vm.page-cluster=0

O vm.page-cluster define quantas páginas o kernel traz de uma vez ao fazer swap-in, em potência de dois — o padrão 3 significa oito páginas por leitura. Essa antecipação faz sentido em disco rotativo, onde o custo está no deslocamento da cabeça e trazer o vizinho sai praticamente de graça. Com zram ou zswap não existe deslocamento nenhum, e cada página trazida a mais consome ciclos de CPU em descompressão para nada. Zerar o parâmetro elimina esse desperdício.

Conclusão

A disputa zram vs zswap não tem vencedor absoluto, e é por isso que a escolha errada costuma passar despercebida por meses, até aparecer como travamento inexplicável sob carga. O zram entrega compressão sem depender de nada no disco e é a resposta certa para desktops, laptops e máquinas sem partição de swap — desde que seja usado sozinho, sem um swap em disco de prioridade menor atrás dele, sob pena da inversão LRU descrita acima. O zswap exige que um swap físico exista, e é justamente essa dependência que lhe dá a vantagem: por ser um cache na frente do armazenamento, ele mantém o ciclo LRU íntegro de ponta a ponta e escoa para o disco as páginas realmente frias, em vez de segurá-las ocupando RAM.

Na prática, a decisão cabe em uma pergunta: existe swap em disco nesta máquina? Se não existe e não vai existir, zram. Se existe — e mais ainda se for NVMe em um servidor sob cgroups v2 —, zswap. Feita a escolha, ajuste o vm.swappiness, zere o vm.page-cluster e meça o resultado com zramctl, vmstat e a pressão de memória exposta em /proc/pressure/memory. E resista à tentação de ligar os dois ao mesmo tempo esperando somar benefícios: o que se soma, nesse arranjo, são as limitações de cada um.