Cómo configurar swap en Ubuntu: cuánto necesitas

Comprobar el estado

free -h
swapon --show

Si ya hay swap, no crees otra sin entender la configuración.

Elegir tamaño

Para VPS de 1–2 GB, un archivo de 1–2 GB ofrece margen. Con 4–8 GB, 2–4 GB puede bastar para picos moderados. Cargas con memoria muy variable requieren medición. La hibernación no suele aplicarse a VPS.

Crear un archivo de 2 GB

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

Añade a /etc/fstab:

/swapfile none swap sw 0 0

Comprueba la sintaxis antes de reiniciar con sudo mount -a y vuelve a ejecutar swapon --show después del arranque.

Ajustar swappiness

Un valor menor hace que el kernel prefiera RAM, sin prohibir swap. Crea /etc/sysctl.d/99-swap.conf:

vm.swappiness=10

Aplica con sudo sysctl --system. No existe un valor mágico; observa el comportamiento de la carga.

Cuándo ampliar RAM

Si el servidor intercambia memoria constantemente, la latencia sube o aparecen procesos OOM, corrige fugas, limita workers o aumenta RAM. Sigue el diagnóstico de VPS sin RAM y dimensiona el plan.

Qué problema resuelve la swap y qué problema no puede resolver

La swap ofrece al kernel un lugar lento donde mover páginas poco usadas y libera RAM para trabajo activo. Puede suavizar un pico corto, pero no convierte almacenamiento NVMe en memoria con la misma latencia.

• Un proceso puede sobrevivir a una ráfaga moderada que, sin swap, activaría antes el OOM killer.
• La respuesta empeora cuando datos activos entran y salen continuamente del disco: eso es thrashing.
• Una fuga de memoria seguirá creciendo hasta consumir RAM y swap; solo aplaza el fallo.

La comprobación práctica debe acompañar el cambio. Observa MemAvailable, uso de swap y tasas si/so de vmstat 1. Swap ocupada sin intercambio actual no implica un problema; intercambio continuo con latencia sí.

La precaución principal en este punto es clara: usar un archivo enorme para ocultar falta crónica de RAM puede congelar la aplicación durante minutos en vez de fallar rápido y recuperarse de forma controlada.

Cómo elegir el tamaño según la carga del VPS

No existe una fórmula universal. El tamaño depende de memoria física, variación de la carga, comportamiento ante OOM y si necesitas volcados de memoria; la hibernación habitual de portátiles no aplica a un VPS.

• Con 1 o 2 GB de RAM, 1–2 GB de swap suele dar margen para actualizaciones y picos pequeños.
• Con 4–8 GB, empieza con 2 GB si la carga es estable y mide antes de ampliar.
• Bases de datos y JVM requieren límites propios: una swap grande no corrige un buffer pool o heap sobredimensionado.

Para verificar esta parte sin depender de intuiciones, revisa el máximo diario de MemAvailable, swap usada y eventos OOM durante una semana representativa. Dimensiona con datos de tráfico y tareas programadas, no solo con la RAM contratada.

La precaución principal en este punto es clara: duplicar automáticamente la RAM proviene de reglas antiguas para equipos con hibernación. En servidores puede desperdiciar disco o retrasar la detección de una configuración incorrecta.

Crear el archivo con permisos y respaldo correctos

El archivo de swap debe ser propiedad de root y modo 600 porque puede contener fragmentos de datos sensibles que estuvieron en memoria. Ubuntu admite fallocate; si el sistema de archivos no lo soporta, usa dd.

• Verifica espacio con df -h / y reserva margen para logs, actualizaciones y datos.
• Ejecuta mkswap solo sobre la ruta creada; una ruta equivocada puede destruir un archivo válido.
• Activa con swapon y comprueba el tamaño antes de persistir en fstab.

La evidencia que conviene guardar es concreta. sudo swapon --show --bytes debe listar /swapfile, y ls -l /swapfile debe mostrar permisos -rw-------. La activación inmediata permite revertir sin reiniciar.

La precaución principal en este punto es clara: crear swap cuando el disco ya está al límite puede causar un incidente distinto. No consumas el último espacio libre para proteger RAM.

Persistencia segura en fstab y prueba de reinicio

La línea de /etc/fstab hace que systemd active la swap durante cada arranque. Debe añadirse una sola vez y verificarse antes de reiniciar para evitar entradas duplicadas o rutas inexistentes.

• Busca primero /swapfile en fstab y conserva una copia del archivo de configuración.
• Usa swapon -a para probar las entradas de swap; mount -a no valida por sí solo todos sus detalles.
• Reinicia en una ventana segura y confirma que el archivo vuelve a aparecer sin comandos manuales.

Antes de dar el paso por terminado, compara la salida de swapon --show antes y después del reinicio. Revisa journalctl -b | grep -i swap si no se activa.

La precaución principal en este punto es clara: pegar la misma línea varias veces no suma capacidad de forma sana; añade ruido y puede ocultar que existen varios archivos antiguos.

Swappiness: una preferencia, no un porcentaje de uso

vm.swappiness orienta al kernel sobre el equilibrio entre reclamar caché de archivos y mover memoria anónima. No significa «empieza a usar swap al llegar al 10 % de RAM».

• Un valor bajo como 10 suele ser un punto inicial razonable para servidores interactivos, no una ley.
• Bases de datos pueden preferir valores muy bajos, pero primero ajusta sus límites de memoria y caché.
• Guarda el ajuste en /etc/sysctl.d/ para no mezclarlo con configuraciones de paquetes.

En producción, la validación útil es la que reproduce la ruta real. Consulta el valor con sysctl vm.swappiness y registra latencia, si/so y caché antes y después. Cambiarlo sin una carga comparable no produce evidencia.

La precaución principal en este punto es clara: poner cero no desactiva totalmente swap en todos los kernels y puede hacer que el sistema retenga páginas inactivas mientras descarta caché útil.

Una revisión compacta para esta fase puede ejecutarse así:

free -h
swapon --show
vmstat 1 10
sysctl vm.swappiness
journalctl -k -g 'Out of memory|Killed process'

Lee la salida completa y conserva la hora de la prueba. Estos comandos no corrigen nada por sí solos: sirven para confirmar el estado antes de decidir el siguiente cambio.

Cómo leer vmstat para saber si la swap está dañando el rendimiento

El dato decisivo no es cuántos megabytes aparecen usados, sino si el servidor intercambia páginas continuamente. vmstat muestra si y so: entrada desde swap y salida hacia swap por segundo.

• Picos breves durante una tarea pesada pueden ser tolerables si la latencia vuelve a la normalidad.
• Valores sostenidos junto con CPU en espera de E/S indican presión y posible thrashing.
• CPU ociosa con disco ocupado puede parecer falta de procesador cuando la causa es memoria.

La comprobación práctica debe acompañar el cambio. Ejecuta vmstat 1 60 durante el problema y correlaciona la hora con latencia y procesos. Complementa con pidstat -r 1 para localizar crecimiento.

La precaución principal en este punto es clara: mirar free -h una vez después del incidente no muestra el pico. Instala histórico o captura métricas para poder comparar.

Swap, contenedores y límites de memoria

Docker y otros runtimes pueden limitar RAM y swap por contenedor, pero los valores dependen de cgroups y de cómo se inició el servicio. Sin límites, un contenedor puede presionar a todo el host.

• Define memoria y comportamiento de reinicio para workers propensos a picos.
• Comprueba límites efectivos con docker inspect, no solo con el archivo Compose.
• Reserva memoria para kernel, SSH, proxy y monitoreo; no asignes el 100 % a contenedores.

Para verificar esta parte sin depender de intuiciones, provoca una carga controlada en staging y observa docker stats, eventos OOM y swap del host. El contenedor debe fallar o limitarse según lo planeado sin tumbar SSH.

La precaución principal en este punto es clara: una restricción demasiado baja genera reinicios repetidos; ninguna restricción permite que una sola aplicación degrade todas las demás.

Investigar al OOM killer antes de aumentar la swap

Cuando Linux no puede satisfacer memoria, el OOM killer termina un proceso para salvar el sistema. Sus registros indican proceso, consumo y cgroup; esa evidencia debe revisarse antes de comprar recursos.

• Busca eventos con journalctl -k -g 'Out of memory|Killed process'.
• Distingue pico puntual, fuga creciente, demasiados workers y caché configurada por encima de la RAM.
• Corrige límites o concurrencia y repite la carga que provocó el evento.

La evidencia que conviene guardar es concreta. Una solución válida elimina nuevos eventos OOM y mantiene latencia aceptable durante el mismo periodo. Aumentar swap sin repetir la prueba solo mueve el momento del fallo.

La precaución principal en este punto es clara: reiniciar borra parte del contexto operativo y resetea el consumo, pero no arregla la causa. Captura procesos y logs antes si todavía puedes entrar.

Cuándo quitar o redimensionar el archivo de swap

Puedes ampliar, reducir o retirar swap sin reinstalar, pero primero asegúrate de que la RAM disponible puede recibir las páginas que están fuera. swapoff puede fallar o provocar OOM en un host presionado.

• Para cambiar tamaño: detén carga, ejecuta swapoff, recrea el archivo y vuelve a activar.
• Para retirar: comenta la entrada de fstab, desactiva y confirma después de reiniciar.
• Mantén consola disponible si la memoria está justa y evita hacerlo durante backups o compilaciones.

Antes de dar el paso por terminado, antes de swapoff, compara swap usada con MemAvailable. Después, verifica swapon --show, free -h y la ausencia de errores en el journal.

La precaución principal en este punto es clara: no borres /swapfile mientras sigue activo. El espacio puede no liberarse como esperas y dejas una referencia rota para el próximo arranque.

Decidir entre optimizar, añadir RAM o conservar swap

Swap es adecuada como cinturón de seguridad cuando el uso normal cabe en RAM. Si la carga cruza el límite todos los días, debes reducir consumo o ampliar el plan.

• Optimiza consultas y cachés si la presión coincide con una operación concreta.
• Reduce workers cuando cada proceso replica mucha memoria y la concurrencia real no los necesita.
• Aumenta RAM cuando el conjunto de trabajo legítimo supera de forma sostenida la capacidad disponible.

En producción, la validación útil es la que reproduce la ruta real. Define un umbral operativo: MemAvailable mínimo, máximo de swap y latencia aceptable. Si se incumple con carga normal durante varios días, escala con evidencia.

La precaución principal en este punto es clara: comprar RAM sin revisar una fuga solo encarece el tiempo hasta el próximo incidente; perseguir optimizaciones cuando el negocio creció puede costar más que ampliar.

Caso práctico: un VPS de 2 GB durante una tarea nocturna

Una forma útil de consolidar el procedimiento es recorrer un incidente de principio a fin. En este caso, el objetivo no es acumular comandos, sino dejar memoria de intercambio en un estado que otra persona pueda entender, verificar y recuperar.

Primero registra el estado anterior y la hora. La swap ofrece al kernel un lugar lento donde mover páginas poco usadas y libera RAM para trabajo activo. Puede suavizar un pico corto, pero no convierte almacenamiento NVMe en memoria con la misma latencia. Por eso la primera decisión debe quedar escrita junto con el resultado esperado. Si el cambio afecta acceso o datos, abre una ruta de recuperación independiente antes de continuar.

Después aplica una sola modificación y observa su efecto. No existe una fórmula universal. El tamaño depende de memoria física, variación de la carga, comportamiento ante OOM y si necesitas volcados de memoria; la hibernación habitual de portátiles no aplica a un VPS. La evidencia mínima incluye la orden ejecutada, su salida relevante y una comprobación desde el lugar real del usuario. Ejecutar la prueba únicamente dentro del VPS puede ocultar reglas de red, DNS o proxy que forman parte del servicio.

En el tercer paso revisa privilegios y exposición. El archivo de swap debe ser propiedad de root y modo 600 porque puede contener fragmentos de datos sensibles que estuvieron en memoria. Ubuntu admite fallocate; si el sistema de archivos no lo soporta, usa dd. Pregunta qué identidad ejecuta el proceso, qué archivos puede leer y desde qué redes se alcanza. Si la respuesta es «cualquiera» o «todo», detente y reduce el alcance antes de añadir otra capa.

A continuación prueba la condición de fallo. La línea de /etc/fstab hace que systemd active la swap durante cada arranque. Debe añadirse una sola vez y verificarse antes de reiniciar para evitar entradas duplicadas o rutas inexistentes. Una buena validación incluye el camino positivo y el negativo: lo autorizado funciona y lo que decidiste bloquear deja de funcionar. Guarda la salida y no cierres el acceso de emergencia hasta completar ambos lados.

Luego simula recuperación. vm.swappiness orienta al kernel sobre el equilibrio entre reclamar caché de archivos y mover memoria anónima. No significa «empieza a usar swap al llegar al 10 % de RAM». Revertir en una ventana tranquila revela dependencias ausentes, permisos que solo existían en la sesión del administrador y pasos que nunca se documentaron. El rollback debe indicar qué se restaura, desde dónde y cómo sabes que terminó bien.

Finalmente observa el servidor durante una ventana comparable a la carga habitual. El dato decisivo no es cuántos megabytes aparecen usados, sino si el servidor intercambia páginas continuamente. vmstat muestra si y so: entrada desde swap y salida hacia swap por segundo. Si aparecen errores nuevos, crecimiento sostenido o reintentos, el cambio todavía no está terminado. Si la ruta funciona y las métricas permanecen dentro de lo previsto, registra versión, fecha y responsable. Ese registro convierte una solución individual en una operación repetible.

El resultado esperado no es «se ejecutaron los comandos», sino una evidencia breve: configuración válida, servicio accesible solo por la ruta prevista, prueba negativa correcta, datos persistentes cuando corresponda y un camino de recuperación ensayado. Con esa disciplina, memoria de intercambio deja de depender de memoria o improvisación.

Swap en disco frente a zram

Un archivo de swap y zram no resuelven exactamente el mismo problema. La swap tradicional escribe páginas en el almacenamiento del VPS: ofrece más margen cuando falta memoria, pero cada lectura posterior depende de la latencia del disco. zram crea un dispositivo comprimido dentro de la RAM; consume CPU para comprimir, pero puede guardar más páginas en la misma memoria física sin esperar al almacenamiento. No añade RAM real y tampoco garantiza que una carga demasiado grande vaya a sobrevivir.

zram resulta interesante en VPS pequeños con picos breves, datos de memoria que se comprimen bien y CPU disponible. Una swap sobre NVMe suele ser más predecible cuando necesitas un colchón mayor o cuando la CPU ya es el recurso limitado. También pueden coexistir: zram recibe una prioridad superior para absorber primero las páginas comprimibles y el archivo en disco queda como último recurso. Esa combinación requiere medición; instalar ambos y olvidar sus límites solo mueve el punto en el que aparece el problema.

Comprueba los dispositivos y sus prioridades con:

swapon --show --output=NAME,TYPE,SIZE,USED,PRIO
zramctl

Si Ubuntu no tiene un dispositivo zram configurado, zramctl no mostrará filas. No copies una receta de otra distribución sin revisar cómo integra el servicio con systemd, porque dos mecanismos intentando crear el mismo dispositivo pueden producir un arranque inconsistente. Antes de adoptar zram registra RAM disponible, CPU, si/so de vmstat y latencia de la aplicación durante el pico; repite exactamente la misma prueba después.

Medir presión de memoria con PSI antes de aumentar la swap

free describe cantidades, pero no cuánto tiempo pierden las tareas esperando memoria. Linux expone Pressure Stall Information (PSI) en /proc/pressure/memory. Es una señal especialmente útil cuando el servidor parece tener swap disponible y, aun así, las solicitudes se vuelven lentas:

cat /proc/pressure/memory
vmstat 1 60
grep -E 'MemAvailable|SwapTotal|SwapFree' /proc/meminfo

En PSI, la línea some indica periodos en los que al menos una tarea estuvo detenida por presión de memoria; full refleja momentos en los que todas las tareas no ociosas estuvieron detenidas simultáneamente. Los promedios avg10, avg60 y avg300 permiten distinguir un golpe breve de una degradación sostenida. No existe un umbral universal: crea una línea base cuando el servicio responde bien y alerta por una desviación que coincida con aumento de latencia, swap de entrada o salida y caída de MemAvailable.

Relaciona la hora con el proceso responsable. ps ofrece una foto; systemd-cgtop ayuda cuando la carga está separada en servicios y docker stats --no-stream cuando vive en contenedores. Una base de datos puede conservar mucha memoria como caché útil, mientras una aplicación con fuga crece sin estabilizarse. Reducir caché y matar una fuga producen el mismo alivio inmediato, pero exigen decisiones opuestas para evitar que el incidente vuelva.

Cómo afecta la swap a bases de datos y workers

PostgreSQL, MySQL, Redis, PHP-FPM y los workers de colas mantienen conjuntos de trabajo con perfiles distintos. Si las páginas activas de una base terminan en swap, una consulta que normalmente toca RAM empieza a esperar almacenamiento y su latencia puede crecer de forma irregular. Redis merece especial cuidado: su valor está en responder desde memoria, y una instancia que intercambia páginas continuamente contradice su propio diseño.

Los workers suelen ofrecer una palanca más directa. Cada proceso PHP, Node o Python tiene un costo base; multiplicarlo por una concurrencia copiada de una máquina mayor puede agotar un VPS aunque el tráfico sea modesto. Mide el RSS de un worker bajo una tarea real, reserva memoria para sistema y base de datos y calcula cuántos caben sin depender de swap durante el uso normal. Para trabajos nocturnos, escalona importaciones, backups y tareas de cola para que no compitan en el mismo minuto.

La conclusión operativa cambia según el patrón. Si la swap se usa una vez durante un despliegue y luego el servidor recupera su latencia, cumplió como amortiguador. Si si y so permanecen activos durante las horas de negocio, reduce concurrencia, corrige la carga o amplía RAM. Aumentar el archivo solo prolongaría una fase de thrashing y haría menos evidente la falta de capacidad.