Cómo duplicar la RAM de tu Linux con zram y swap comprimida (sin comprar nada)
TL;DR: Configuré zram + swap en disco + systemd-oomd en mi Linux y pasé de 32 GB a 64 GB de memoria efectiva. Lo probé con stress-ng allocando 22 GB extra hasta verificar que funciona. No compré nada.
¿Es esto para ti?
| Tu RAM | ¿Te ayuda? | Por qué |
|---|---|---|
| 4 GB | ✅ Mucho | zram puede darte el equivalente a 6-8 GB. Cambia la experiencia por completo. |
| 8-16 GB | ✅ Bastante | Ideal para esta configuración. Firefox, IDEs y Docker notan la diferencia. |
| 32 GB | ✅ Sí | Mi caso. Docker + IDEs + Firefox = se llena. Con 64 GB efectivos va sobrado. |
| 64+ GB | ⚠️ Poco | Probablemente no necesitas esto. A menos que uses VMs pesadas o compilación masiva. |
¿Cómo saber si ya tienes zram?
swapon --show
Si ves una línea con /dev/zram0, tu distro ya lo tiene habilitado. Pero probablemente esté mal configurado. Sigue leyendo.
Lo que conseguí
Mi sistema tiene 32 GB de RAM. Después de configurar zram, sysctl y un swapfile en disco:
RAM física: 32 GB → instantánea
zram: 16 GB → swap comprimido en RAM (~2x más lento)
swap disco: 16 GB → swapfile en NVMe (~100x más lento)
Total: ~64 GB de memoria efectiva
¿Cómo funciona? La RAM se llena → el kernel mueve lo inactivo a zram (comprimido, rápido) → si zram se llena, desborda al disco → si todo falla, systemd-oomd mata solo el proceso problemático.
Lo más importante: lo probé. Ejecuté stress-ng para allocar 22 GB extra. zram absorbió 15.3 GB y el swapfile del disco entró como respaldo. El sistema volvió a la normalidad sin reiniciar.
El problema que me motivó
Mi flujo de trabajo es pesado. Firefox con 50 pestañas, containers Docker, una IDE basada en Electron, servidores locales. Un día, la IDE creció hasta 9.8 GB por una fuga de memoria. El OOM killer del kernel entró en acción, y como la IDE corría dentro del cgroup de gnome-shell, GNOME murió con ella. La sesión entera se reinició.
Esto pasó 5 veces en una sola noche.
La causa: mi distribución tenía zram al 100% de la RAM y swappiness a 10. El kernel “creía” tener 63 GB, pero zram comprime en la misma RAM física. Cuando un proceso se descontrola, la RAM física se agota antes de que el kernel reaccione.
Los 5 cambios que necesitas
1. Configurar zram al 50% de RAM (requiere reboot)
El cambio más importante. La mayoría de distros ponen zram al 100% — demasiado agresivo.
# /etc/systemd/zram-generator.conf
[zram0]
zram-size = ram / 2
zram-resident-limit = ram / 2
compression-algorithm = zstd
swap-priority = 100
fs-type = swap
→ zram: mitad de RAM, algoritmo zstd y por qué tu distro lo tiene mal configurado
2. Ajustar sysctl para zram (requiere reboot, junto con #1)
Sin esto, zram apenas se usa. swappiness=180 hace que el kernel mueva páginas a zram ANTES de que la RAM esté llena.
# /etc/sysctl.d/99-vm-zram-parameters.conf
vm.swappiness = 180
vm.watermark_boost_factor = 0
vm.watermark_scale_factor = 125
vm.page-cluster = 0
Ojo: hay una trampa. Tu distro puede tener una regla udev oculta que reescribe swappiness cada vez que zram cambia de estado. Te explico cómo encontrarla y corregirla.
→ Swappiness 180: el valor que hace funcionar zram (y la regla udev que te lo estaba impidiendo)
3. Crear swapfile en disco (sin reboot)
Un colchón extra. Cuando zram se llena, el kernel desborda al disco. No es rápido, pero evita que algo muera.
# Btrfs: desactivar CoW obligatoriamente
sudo truncate -s 0 /swapfile
sudo chattr +C /swapfile
sudo fallocate -l 16G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
En /etc/fstab: /swapfile none swap defaults,pri=50 0 0
→ RAM → zram → swap en disco: cómo montar un sistema de swap por capas y probarlo con stress-ng
4. Habilitar systemd-oomd (sin reboot)
Si un proceso se descontrola a pesar de todo, systemd-oomd lo mata selectivamente sin tumbar GNOME.
→ systemd-oomd y Docker limits: lo que nadie te cuenta para proteger tu sistema
5. Poner límites de memoria a Docker (sin reboot, solo si usas Docker)
Tus containers probablemente no tienen límite. Un container con fuga puede comerse toda la RAM del host.
→ systemd-oomd y Docker limits: lo que nadie te cuenta para proteger tu sistema
Importante: el orden de aplicación
| Cambio | Requiere reboot | ¿Junto con otro? |
|---|---|---|
| zram al 50% | Sí | Junto con sysctl |
| sysctl swappiness=180 | Sí | Junto con zram |
| swapfile en disco | No | Independiente |
| systemd-oomd | No | Independiente |
| Docker limits | No | Independiente |
Los cambios de zram y sysctl deben aplicarse juntos en el mismo reboot. Son interdependientes: swappiness=180 solo es seguro si zram es ram / 2 o menos.
Artículos de esta serie
- Cómo duplicar la RAM de tu Linux con zram y swap comprimida (sin comprar nada) ← estás aquí
- zram: mitad de RAM, algoritmo zstd y por qué tu distro lo tiene mal configurado
- Swappiness 180: el valor que hace funcionar zram (y la regla udev que te lo estaba impidiendo)
- RAM → zram → swap en disco: cómo montar un sistema de swap por capas y probarlo con stress-ng
- systemd-oomd y Docker limits: lo que nadie te cuenta para proteger tu sistema
Referencias
- ArchWiki — zram — la referencia canónica
- Pop!_OS zram tuning — los valores que usan y por qué
- Chris Down — Debunking zswap and zram myths — la crítica más fundamentada contra zram+disco swap
- linuxblog.io — Running Out of RAM on Linux? Add Zram — buena guía práctica con test real