zram e zswap em produção
Spoiler honesto: podem salvar um servidor pequeno ou matar a performance de um servidor grande, dependendo do cenário.
Tecnologias como zRAM e zswap podem melhorar o uso de memória em servidores Linux, mas também podem alterar o comportamento de performance do sistema em determinadas condições. Quando sintomas aparecem apenas em momentos específicos de carga, é fundamental investigar o ambiente com cuidado. No guia sobre como diagnosticar problemas intermitentes capturando evidências no servidor, mostramos uma metodologia prática para esse tipo de análise.
O que é ZRAM (sem romantizar)
ZRAM cria um dispositivo de swap comprimido na RAM.
Ou seja: você “troca” CPU por memória.
📌 Em vez de escrever páginas de memória no disco (SSD/NVMe), o kernel:
- comprime os dados
- guarda na própria RAM
- descomprime quando precisa
👉 Resultado:
Você ganha memória aparente, mas perde CPU.
Impacto real do ZRAM em produção
✅ Onde ZRAM funciona bem
✔ VPS pequena (1–4 GB RAM)
✔ Servidores sem swap em disco
✔ Workloads leves ou intermitentes
✔ Containers leves (Docker, LXC)
✔ Ambientes edge / embedded
📈 Benefícios reais:
- Evita OOM Killer
- Reduz travamentos bruscos
- Swap MUITO mais rápido que disco
- Pode aumentar a “RAM útil” em ~30–60%
👉 Em VPS de 2 GB, ZRAM muitas vezes salva o servidor.
❌ Onde ZRAM vira problema
✘ Servidores com CPU já no limite
✘ Bancos de dados (MariaDB, PostgreSQL)
✘ WordPress de alto tráfego
✘ Sistemas com carga constante
✘ Servidores com SSD/NVMe rápido
📉 Impactos negativos reais:
- Aumento de load average
- Latência imprevisível
- Picos de CPU sem explicação
- MySQL/MariaDB ficando lento “do nada”
- PHP-FPM demorando a responder
👉 Em produção pesada, ZRAM mascara falta de RAM e cobra com juros em CPU.
O que é ZSWAP (e por que é mais perigoso)
ZSWAP é um cache comprimido de swap em RAM, mas:
- NÃO substitui o swap em disco
- Atua antes do swap real
Fluxo:
RAM → ZSWAP (comprimido) → SWAP em disco
Impacto real do ZSWAP em produção
⚠ Onde ZSWAP pode ajudar
✔ Máquinas com swap lento
✔ Workloads com picos raros
✔ Ambientes de desktop ou dev
✔ VPS pequenas com SSD ruim
📈 Benefício:
- Menos I/O em disco
- Swap “menos doloroso”
🚨 Onde ZSWAP dá dor de cabeça
✘ Produção crítica
✘ Bancos de dados
✘ Aplicações sensíveis à latência
✘ Servidores com swap NVMe rápido
✘ Ambientes já no limite de CPU
📉 Problemas comuns:
- CPU extra para compressão
- Latência inconsistente
- Difícil de diagnosticar
- Pode piorar mais do que ajudar
👉 Em produção, ZSWAP é imprevisível.
ZRAM vs ZSWAP: comparação realista
| Cenário | ZRAM | ZSWAP |
|---|---|---|
| VPS pequena | ✅ Excelente | ⚠ Ok |
| WordPress alto tráfego | ❌ Não | ❌ Não |
| Banco de dados | ❌ Nunca | ❌ Nunca |
| Desktop / dev | ✅ Bom | ✅ Bom |
| Servidor com NVMe | ❌ Desnecessário | ❌ Desnecessário |
| CPU sobrando | ✅ Ajuda | ⚠ Talvez |
Verdade que poucos falam
🔴 Swap comprimido não cria memória
Ele compra tempo, não resolve gargalo estrutural.
Se o servidor precisa constantemente de swap:
- falta RAM
- não falta “configuração”
Em alguns cenários, mudanças na estratégia de gerenciamento de memória podem gerar sintomas difíceis de reproduzir, como latência inesperada ou degradação de performance sob carga. Nessas situações, aplicar uma abordagem estruturada de investigação de problemas intermitentes em servidores Linux ajuda a evitar diagnósticos incorretos.
Boas práticas em produção (sem ilusão)
✔ Quando usar ZRAM
- VPS até 4 GB
- Sem banco pesado
- CPU com folga
- Swap em disco inexistente ou muito lento
👉 Use como proteção contra OOM, não como solução definitiva.
❌ Quando NÃO usar
- WordPress com tráfego constante
- MariaDB > 1–2 GB buffer pool
- Servidores monitorados por SLA
- Ambientes onde latência importa
👉 Melhor:
- Mais RAM
- Ajustar
innodb_buffer_pool_size - Ajustar PHP-FPM
- Swap tradicional bem configurado (ou zero swap)
Minha recomendação direta (produção séria)
Se você precisa de ZRAM ou ZSWAP para sobreviver, o servidor está subdimensionado.
Eles são:
- 🩹 paliativos
- 🔧 ferramentas de contenção
- 🚫 não soluções estruturais
Antes de alterar parâmetros críticos de memória ou aplicar otimizações no kernel, é importante confirmar o comportamento real do sistema. Seguir uma metodologia adequada de captura de evidências em problemas intermitentes de servidores ajuda a entender a causa raiz antes de qualquer intervenção.
FAQ
Não necessariamente. O ZRAM reduz uso de disco ao usar memória comprimida, mas aumenta o consumo de CPU. Em produção com carga constante, pode piorar a performance
Na maioria dos casos, não. O ZSWAP adiciona uma camada extra de compressão que pode causar latência imprevisível e dificultar o diagnóstico de problemas.
Não. ZRAM não cria memória real. Ele apenas comprime dados na RAM existente, funcionando como paliativo contra OOM Killer.
Sim, em VPS de até 4 GB de RAM, sem banco de dados pesado, o ZRAM pode ajudar a evitar travamentos em picos de uso.
Não. WordPress com tráfego constante e banco ativo tende a sofrer com aumento de latência e consumo excessivo de CPU ao usar swap comprimido.
Veja Mais:
Problemas Intermitentes em Servidores: Como Capturar Evidências Reais
Firewall no Linux com firewalld e nftables: Guia Prático para Produção
Exemplo real: VPS 4 cores x tráfego WordPress
Redis vs Memcached: qual cache usar em servidores Linux