Ubuntu 24.04: Swap en SSD — hazlo de forma segura (y cuándo no deberías) (caso #50)

Qué es el swap (y qué no es)

El swap es memoria virtual respaldada por disco. Es una válvula de alivio: cuando la RAM escasea, el kernel puede expulsar páginas frías de la RAM,
liberando espacio para las páginas calientes. Bien hecho, swap convierte “proceso muerto” en “proceso más lento”.
Mal hecho, swap convierte “lento” en “norespondible”.

En Ubuntu 24.04, normalmente tendrás un swapfile en /swap.img creado por el instalador y gestionado vía systemd.
También puedes tener zram (swap comprimido en RAM) según la edición y la configuración. Cada uno tiene distintos modos de fallo.

El modelo mental que necesitas

• Swap no es RAM adicional. Es una reserva con latencias muy distintas.
• Swap no es solo para emergencias. Puede usarse de forma proactiva para mantener eficiente el comportamiento de la caché, especialmente en cargas mixtas.
• Swap no es la causa de tu fuga de memoria. Es solo donde la fuga muere lentamente.

El SSD cambia el juego porque la E/S de swap se vuelve “menos terrible”, no “rápida”.
NVMe puede ofrecer IOPS impresionantes, pero el swapping suele ser lecturas aleatorias pequeñas durante fallos de página—la latencia importa, el encolamiento importa,
y los límites de cgroup importan. Un SSD rápido puede seguir siendo lo más lento en la sala.

Una frase que la gente de operaciones interioriza pronto:
«La esperanza no es una estrategia.» — General Gordon R. Sullivan

Si tu plan es “activar swap y cruzar los dedos”, recibirás el swap que mereces.

Hechos e historia que importan

1. El swap existe desde antes de Linux. Paginación y estrategias de swap fueron núcleo de los sistemas UNIX de time-sharing mucho antes de que los PCs de consumo tuvieran suficiente RAM.
2. Linux usa swap más inteligentemente de lo que se piensa. Puede expulsar memoria anónima manteniendo caliente la caché de archivos, según la presión y los parámetros.
3. El miedo a que “el swap dañe los SSD” tiene raíces históricas. Los primeros SSD para consumo tenían controladores y resistencia más débiles; los NVMe modernos son mucho más robustos.
4. Ubuntu se inclinó por los swapfiles hace años. Las particiones de swap siguen siendo válidas, pero los swapfiles son más fáciles de redimensionar y desplegar a escala.
5. La hibernación es el caso especial del swap. Hibernar requiere un área de swap lo bastante grande para contener la RAM, y los swapfiles necesitan configuración de arranque adicional.
6. Los cgroups cambiaron el significado de “sin memoria”. Un contenedor puede ser OOM-kill mientras el host tiene RAM libre, y el swap puede estar deshabilitado a nivel de cgroup.
7. zram se popularizó porque la CPU se abarató. Comprimir páginas frías en RAM puede ganarle al ir al disco, especialmente en portátiles y pequeñas VMs.
8. NVMe hizo que el swap sea “posible” en sistemas de alto rendimiento. No vuelve el swap rápido, pero puede evitar que sea catastróficamente lento como los discos giratorios.

Broma #1: El swap es como una pasarela de aeropuerto—útil si ya estás caminando, vergonzoso si lo usas para transportar un piano.

¿Deberías poner swap en SSD?

Mi valor por defecto, con opinión

En Ubuntu 24.04 con un SSD, generalmente deberías mantener algo de swap activado—a menos que tengas una razón concreta para no hacerlo.
“Algo” significa unos pocos gigabytes para la mayoría de servidores, y suficiente para hibernar si realmente usas hibernación.

Swap en SSD es bueno para

• Prevenir OOM kills repentinos en cargas con picos (construcciones de paquetes, indexado de logs, calentamiento de JVM).
• Mantener el sistema estable bajo presión de memoria para que puedas iniciar sesión, inspeccionar y arreglar el problema real.
• Reducir riesgo extremo cuando ejecutas muchos servicios y uno se comporta mal.
• Dar sentido al overcommit en hosts que usan overcommit de memoria responsablemente (y tienen monitorización).

Swap en SSD es malo para

• Servicios sensibles a la latencia, casi en tiempo real donde fallos de página ocasionales son inaceptables.
• Sistemas ya limitados por I/O (discos de base de datos saturados, colas NVMe llenas, nodos de almacenamiento haciendo trabajo real).
• Culturas que “se niegan a dimensionar RAM correctamente”. El swap se convertirá en una muleta, y luego en una factura.

La pregunta clave

¿Estás intentando sobrevivir a un mal día, o intentando ahorrar dinero subdimensionando la memoria permanentemente?
El swap es decente para lo primero y terrible para lo segundo.

Guía rápida de diagnóstico

Cuando un host se siente “congelado”, no tienes tiempo para filosofía. Necesitas un camino corto hacia el cuello de botella.
Aquí está el orden que suele funcionar en producción real.

1) Confirma que estás intercambiando (y qué tanto)

• Si el uso de swap está cerca de cero, esto no es un incidente de swap. Pasa a CPU, I/O o bloqueos.
• Si el uso de swap es alto y creciente, estás en presión de memoria y probablemente acercándote al thrash.
• Si el uso de swap es estable pero la máquina está lenta, podrías tener tormentas de swap-in (fallos de página) en lugar de swap-out continuo.

2) Decide si el cuello de botella es I/O de disco o CPU

• Alto wa (espera por I/O) y altas tasas de swap-in/out normalmente significan que el camino de almacenamiento es el limitador.
• Baja espera de I/O pero CPU cargada con compresión zram puede indicar que estás pagando CPU para evitar E/S a disco.

3) Identifica la clase de procesos que causa la presión

• Busca un proceso descontrolado (fuga de memoria) frente a muchos procesos normales combinados (RAM subdimensionada).
• En servidores, revisa límites de cgroup primero; el host puede estar bien.

4) Actúa: estabiliza, luego arregla

• Si hay thrashing: reduce la carga, detén al culpable, o añade temporalmente swap/zram solo si restaura el control.
• Si es crónico: añade RAM o reduce el conjunto de trabajo. Afinar swappiness no sustituye la planificación de capacidad.

Tareas prácticas (comandos, salidas, decisiones)

Estas son las comprobaciones e intervenciones exactas que ejecuto en hosts Ubuntu 24.04. Cada tarea incluye un fragmento de salida realista,
lo que significa y la decisión que tomas.

Task 1: Ver qué swap existe y si está activo

cr0x@server:~$ swapon --show --bytes
NAME       TYPE SIZE        USED PRIO
/swap.img  file 8589934592  0    -2

Significado: Tienes un swapfile de 8 GiB y está habilitado, actualmente sin uso.

Decisión: Si estás solucionando lentitud y USED está cerca de SIZE, probablemente estás en presión de memoria. Si USED es 0, el swap no es el culpable.

Task 2: Instantánea rápida de RAM + swap

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        25Gi       1.2Gi       1.0Gi       5.0Gi       3.0Gi
Swap:          8.0Gi       6.5Gi       1.5Gi

Significado: El swap está muy usado y la RAM disponible es baja. Esta es una postura de “lento ahora, peor después”.

Decisión: Comprueba si el sistema está intercambiando activamente (Task 3). Si no está intercambiando activamente, esto podría ser uso histórico de swap que no se ha recuperado.

Task 3: Detectar swap activo vs páginas antiguas en swap

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0 6815744  93248  90112 2840000 120  240   300   600  800 1200 12  5 70 13  0
 3  1 6897664  84520  89400 2815000 800 1200  2100  3300 1400 2100 10  6 55 29  0
 1  1 7012352  70212  88000 2780000 600  900  1600  2400 1300 1900  9  5 58 28  0
 1  0 7012352  76000  88500 2779000   0    0   200   300  900 1400  8  4 84  4  0
 1  0 7012352  77000  88500 2778000   0    0   150   250  850 1300  7  4 85  4  0

Significado: Los picos en si/so (swap-in/swap-out) muestran thrash activo durante los primeros segundos, luego calma.

Decisión: Si los picos se correlacionan con latencia, necesitas reducir la presión de memoria o la contención de I/O. Si es consistentemente alto, estás en thrash sostenido.

Task 4: Comprobar swappiness del kernel y los knobs de presión de caché

cr0x@server:~$ sysctl vm.swappiness vm.vfs_cache_pressure
vm.swappiness = 60
vm.vfs_cache_pressure = 100

Significado: Comportamiento más o menos por defecto: se permite swap a medida que aumenta la presión.

Decisión: Para muchos servidores, considera vm.swappiness=10 o 20 si quieres preferir mantener páginas anónimas en RAM—pero solo después de confirmar que no estás enmascarando un problema de RAM insuficiente.

Task 5: Ver si el sistema está matando por OOM

cr0x@server:~$ journalctl -k -g "Out of memory" -n 5
Dec 30 09:12:21 server kernel: Out of memory: Killed process 21877 (java) total-vm:18233400kB, anon-rss:12984320kB, file-rss:12288kB, shmem-rss:0kB, UID:1001 pgtables:36244kB oom_score_adj:0

Significado: No solo estás intercambiando; sigues alcanzando OOM. El swap no es lo bastante grande o la demanda de memoria está subiendo más rápido de lo que el sistema puede recuperar.

Decisión: Arregla el servicio problemático o aumenta la memoria. Aumentar swap puede comprar tiempo, pero si el conjunto de trabajo excede realmente la RAM, el rendimiento sufrirá.

Task 6: Identificar rápidamente los mayores consumidores de memoria

cr0x@server:~$ ps -eo pid,comm,rss,vsz,pmem --sort=-rss | head
  PID COMMAND           RSS      VSZ %MEM
21877 java          12984320 18233400 41.2
 8421 postgres       2845120  5120000  9.0
 3112 node            980000  1600000  3.1
 1991 snapd            210000   980000  0.6

Significado: Una JVM domina la memoria residente. Probablemente esa sea la fuente de presión.

Decisión: Valida si es esperada (cache) o una fuga/crecimiento. Para Java, inspecciona los ajustes de heap; para cualquier proceso, revisa despliegues recientes.

Task 7: Comprobar uso de swap por proceso (quién está efectivamente en swap)

cr0x@server:~$ sudo smem -rs swap | head
  PID User     Command                         Swap      USS      PSS      RSS
 8421 postgres /usr/lib/postgresql/16/bin/...  2200M    850M    910M   1200M
 3112 www-data node /srv/app/server.js         1100M    420M    480M    600M
 1991 root     /usr/lib/snapd/snapd             210M     80M     90M    140M

Significado: Postgres y node tienen grandes huellas en swap. Eso normalmente implica que estuvieron inactivos en algún momento o el kernel los eligió como candidatos de expulsión.

Decisión: Si esos procesos son críticos en latencia, considera ajustar swappiness, límites de memoria o asegurar suficiente RAM. Si son por lotes, esto puede ser aceptable.

Task 8: Medir la presión real de almacenamiento y el encolamiento

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0-41-generic (server) 	12/30/2025 	_x86_64_	(8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.12    0.00    4.50   28.20    0.00   57.18

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await wareq-sz aqu-sz  %util
nvme0n1         980.0   18000.0     0.0   0.00    7.20    18.37   420.0   12000.0   12.40    28.57   8.10  98.50

Significado: El NVMe está casi saturado (%util ~ 98%) y las esperas aumentan. Si el swap está activo, compite con todo lo demás.

Decisión: Si tu swap está en el mismo dispositivo que tu base de datos, eso es una pelea de cuchillos en una cabina telefónica. Considera mover el swap a un dispositivo menos contestado o arreglar el dimensionamiento de memoria.

Task 9: Confirmar si el swap es un archivo y dónde vive

cr0x@server:~$ ls -lh /swap.img
-rw------- 1 root root 8.0G Dec 30 08:52 /swap.img

Significado: Es un swapfile en el sistema de ficheros raíz.

Decisión: Asegura que el sistema de ficheros soporte swapfiles de forma segura (ext4 sí; btrfs requiere manejo especial). Si root está en cifrado/LVM, eso está bien, pero entiende las implicaciones para hibernar.

Task 10: Verificar tipo de sistema de ficheros (comprobación de seguridad para swapfile)

cr0x@server:~$ findmnt -no FSTYPE /
ext4

Significado: ext4 es compatible con swapfile.

Decisión: Procede normalmente. Si ves btrfs, detente y sigue las reglas específicas para swapfile en btrfs (sin CoW, extents contiguos).

Task 11: Comprobar estado de TRIM/discard (mantenimiento del SSD)

cr0x@server:~$ systemctl status fstrim.timer --no-pager
● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; preset: enabled)
     Active: active (waiting) since Mon 2025-12-29 10:00:00 UTC; 23h ago
    Trigger: Mon 2026-01-05 10:00:00 UTC; 5 days left

Significado: TRIM semanal está habilitado. Bien: ayuda a la consistencia del rendimiento del SSD con el tiempo.

Decisión: Manténlo. No añadas la opción discard en el montaje solo para sentir que haces algo; TRIM programado suele ser la opción correcta y aburrida.

Task 12: Ver señales de presión de memoria (PSI) y actuar como adulto

cr0x@server:~$ cat /proc/pressure/memory
some avg10=0.85 avg60=0.40 avg300=0.15 total=23840219
full avg10=0.20 avg60=0.08 avg300=0.02 total=4022191

Significado: El sistema se queda regularmente esperando por reclaim de memoria (some) y ocasionalmente queda completamente bloqueado (full).

Decisión: Esto no es teórico. Estás pagando latencia real. O reduces el conjunto de trabajo, añades memoria, o añades swap/zram rápido como mitigación mientras arreglas la causa raíz.

Task 13: Comprobar si zram está habilitado (y de qué tamaño)

cr0x@server:~$ swapon --show
NAME       TYPE      SIZE   USED PRIO
/swap.img  file      8G     2.1G   -2
/dev/zram0 partition 4G     1.3G  100

Significado: zram está presente con mayor prioridad (100). El kernel usará zram antes que el swapfile en SSD.

Decisión: A menudo esto es bueno en sistemas de propósito general. Si la CPU está apretada y el coste de compresión perjudica, considera ajustar o deshabilitar zram—pero solo con evidencia.

Task 14: Validar prioridad de swap y ajustar intencionalmente

cr0x@server:~$ cat /proc/swaps
Filename				Type		Size		Used		Priority
/dev/zram0                               partition	4194300	1365000		100
/swap.img                                file		8388604	2200000		-2

Significado: zram será preferido; el swapfile es reserva.

Decisión: Buen valor por defecto: mantener el swap SSD como “segunda línea de defensa”. Si dependes del swap SSD para hibernar, asegura prioridades y tamaños que no impidan ese plan.

Task 15: Deshabilitar temporalmente swap para demostrar que es el cuello de botella (con cuidado)

cr0x@server:~$ sudo swapoff -a
swapoff: /swap.img: swapoff failed: Cannot allocate memory

Significado: No tienes suficiente RAM libre para traer las páginas de swap de vuelta. El swap está sosteniendo la construcción.

Decisión: No lo fuerces. Reduce el uso de memoria primero (detén servicios, baja la carga) o añade RAM. Deshabilitar swap en este estado hace que el OOM killer sea tu nuevo SRE.

Task 16: Comprobar salud y señales de resistencia del NVMe (sensatez, no superstición)

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | egrep -i "data units written|percentage used|critical_warning"
critical_warning                    : 0x00
percentage_used                     : 3%
data_units_written                  : 1,234,567 [632 TB]

Significado: La salud del disco parece bien; el uso de resistencia es bajo. La E/S de swap no es automáticamente un veredicto de muerte.

Decisión: Enfócate en rendimiento y estabilidad. No prohibas el swap basándote en folklore antiguo sobre SSD; valida con métricas de salud y escrituras.

Patrones de configuración seguros en Ubuntu 24.04

Patrón A: Mantén el swapfile por defecto, pero ajusta el comportamiento

Para la mayoría de sistemas, el enfoque seguro más simple es: mantener /swap.img, confirmar que esté en ext4/xfs,
asegurar que TRIM esté activo y ajustar swappiness de forma conservadora.

Establecer swappiness de forma persistente

cr0x@server:~$ echo 'vm.swappiness=20' | sudo tee /etc/sysctl.d/99-swappiness.conf
vm.swappiness=20

cr0x@server:~$ sudo sysctl --system | tail -n 3
* Applying /etc/sysctl.d/99-swappiness.conf ...
vm.swappiness = 20

Significado: El kernel intentará con más fuerza mantener la memoria anónima en RAM y recuperar la caché primero.

Decisión: Usa 10–30 para muchas cargas de servidor. Evita poner 0 como bandera de “sin swap”; no es lo mismo y puede llevar a patrones de reclaim sorprendentes bajo presión.

Patrón B: Usar zram como primera línea y swap SSD como segunda

Si ejecutas cargas mixtas y quieres degradación controlada, zram te compra tiempo sin martillar el SSD inmediatamente.
En CPUs modernas, esto suele ser una ganancia neta. En CPUs pequeñas o ya saturadas, puede ser contraproducente.

Ubuntu puede ya ofrecer zram mediante paquetes y presets según la instalación. Si lo activas tú, mantenlo moderado.
Sobredimensionar zram es la forma de convertir “compresión” en “¿por qué suena el ventilador de la CPU en un rack?”.

Patrón C: Partición de swap dedicada en SSD (rara vez necesaria)

Las particiones de swap siguen siendo válidas. Pueden ser más simples para hibernación y evitan algunos casos límite del sistema de ficheros.
Pero para la mayoría de flotas de producción, los swapfiles son más fáciles de redimensionar y gestionar con herramientas de configuración.

Redimensionar un swapfile de forma segura

La secuencia segura es: deshabilitar el swapfile, redimensionar, ajustar permisos, formatear la firma de swap, reactivar y validar.
La secuencia insegura es “truncar un swapfile en vivo y rezar”.

cr0x@server:~$ sudo swapon --show
NAME      TYPE SIZE USED PRIO
/swap.img file 8G   0B   -2

cr0x@server:~$ sudo swapoff /swap.img

cr0x@server:~$ sudo fallocate -l 16G /swap.img

cr0x@server:~$ sudo chmod 600 /swap.img

cr0x@server:~$ sudo mkswap /swap.img
Setting up swapspace version 1, size = 16 GiB (17179865088 bytes)
no label, UUID=2b4b2b0a-3baf-4c5d-9b7e-8e8d7d0f5b43

cr0x@server:~$ sudo swapon /swap.img

cr0x@server:~$ swapon --show
NAME      TYPE SIZE  USED PRIO
/swap.img file 16G   0B   -2

Significado: El swap fue redimensionado y está activo.

Decisión: Elige un tamaño que coincida con tu objetivo: supervivencia ante fallos y control operativo, no reemplazo permanente de RAM.

Higiene específica para SSD que realmente importa

• Evita dispositivos con contención: no coloques swap en el mismo NVMe muy utilizado que tu almacenamiento principal si puedes evitarlo.
• Mantén TRIM funcionando: fstrim.timer semanal es suficiente para la mayoría.
• No te obsesiones con el desgaste sin evidencia: revisa métricas SMART/NVMe y supuestos de amplificación de escritura antes de declarar que el swap es “inseguro”.
• Usa prioridades: si tienes múltiples backends de swap (zram + swapfile en SSD), fija prioridades intencionalmente.

Cuándo no deberías usar swap en SSD

Hay casos reales donde swap en SSD es la decisión equivocada. No porque los SSD sean flores delicadas,
sino porque la E/S de swap en el lugar inapropiado se convierte en un amplificador de fallos a nivel de sistema.

1) Nodos de almacenamiento y servidores de base de datos con discos saturados

Si tu NVMe ya está ocupado sirviendo lecturas/escrituras de base de datos o replicación de almacenamiento, el swap compite en las mismas colas.
Bajo presión de memoria, los picos de latencia causan más timeouts, más reintentos, más carga, más swap. Obtienes la espiral.

En estos sistemas, la respuesta más correcta es: dimensionar la RAM para el conjunto de trabajo, fijar límites de memoria y mantener el swap mínimo—a veces incluso deshabilitado—si puedes garantizar que no lo necesitarás.
Esa última cláusula es donde la mayoría de equipos se mienten a sí mismos.

2) Servicios ultra-baja latencia

Si ejecutas servicios con SLOs de latencia estrictos y patrones de acceso con picos, los fallos de página por swap pueden violar SLOs de formas difíciles de reproducir.
Tus métricas mostrarán “un pico raro” que arruina el día.

3) Expectativas de hibernación mal configuradas

Si “necesitas hibernación” pero no configuras resume para swapfiles, terminarás probando hibernación en el peor momento.
Y no volverá.

4) Root cifrado con restricciones de arranque temprano complejas (casos límite)

El swap en root cifrado está bien para swapping normal. Resume de hibernación es donde aparece la complejidad: initramfs necesita encontrar el área de swap temprano.
Si no quieres asumir esa complejidad, no digas que necesitas hibernación.

Broma #2: Nada dice “viernes por la tarde” como descubrir que tu “tweak temporal de swap” fue horneado en la imagen dorada hace seis meses.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: el host está “arriba” pero SSH tarda 20–60 segundos

Causa raíz: thrash de swap (alta latencia de fallo de página) y la CPU queda bloqueada en reclaim; shells interactivos fallan de página constantemente.

Solución: Confirma con vmstat (si/so) y PSI. Reduce la carga inmediatamente (detén al culpable), luego añade RAM o limita el uso de memoria. Considera zram como mitigación.

2) Síntoma: swap está lleno, pero si/so está cerca de cero

Causa raíz: uso histórico de swap; las páginas en swap están frías y no son referenciadas. No es un incidente activo por sí mismo.

Solución: Si el rendimiento está bien, no hagas nada. Si quieres recuperar swap, puedes swapoff/swapon durante una ventana de mantenimiento solo si hay suficiente RAM libre.

3) Síntoma: ocurren OOM kills incluso con mucho swap

Causa raíz: límites de memoria de cgroup (contenedores), o ráfagas rápidas de asignación donde el reclaim no puede seguir el ritmo, o políticas de oom_score_adj que apuntan al proceso equivocado.

Solución: Revisa límites de cgroup, configuración de swap del runtime de contenedores y logs del kernel. Arregla el consumidor de memoria o sube el límite; no solo crezcas el swap.

4) Síntoma: %util de NVMe pegado en ~100% y todo se ralentiza

Causa raíz: E/S de swap compitiendo con la carga principal, a menudo en el mismo dispositivo.

Solución: Mueve el swap a un dispositivo menos contestado o reduce el swapping añadiendo RAM / reduciendo el conjunto de trabajo. Si es posible, aísla clases de I/O con cgroups y controladores de I/O, pero no esperes milagros.

5) Síntoma: habilitar zram hace el sistema más lento

Causa raíz: carga ligada a CPU; la sobrecarga de compresión roba ciclos a la aplicación. O zram está sobredimensionado y causa churn.

Solución: Mide tiempo de CPU y carga. Reduce el tamaño de zram o desactívalo en esa clase de host; confía en swap en SSD como reserva si es apropiado.

6) Síntoma: existe un swapfile pero no se usa en absoluto

Causa raíz: swap está deshabilitado, entrada incorrecta en /etc/fstab, o la unidad systemd no está activa.

Solución: Ejecuta swapon --show. Asegura que /etc/fstab incluya el swapfile y que los permisos sean correctos (0600), luego habilita el swap.

7) Síntoma: hibernación falla o reanuda en un reinicio

Causa raíz: offset de resume no configurado para el swapfile, o swap no lo bastante grande, o arranque temprano no puede acceder al dispositivo de backing del swap.

Solución: Si debes hibernar, usa una partición de swap o configura resume correctamente para swapfile y reconstruye initramfs. Si no, deja de fingir que la hibernación es un requisito.

Listas de verificación / plan paso a paso

Checklist A: Decidir si swap en SSD es aceptable para este host

1. ¿La carga es crítica en latencia con SLOs estrictos? Si sí, mantén swap mínimo y céntrate en dimensionar RAM y límites.
2. ¿El SSD está muy usado por la E/S principal? Si sí, el swap compite y puede amplificar incidentes.
3. ¿Necesitas hibernación? Si sí, planifica el tamaño de swap y la configuración de resume intencionalmente.
4. ¿Ejecutas contenedores con límites de memoria estrictos? Si sí, valida la configuración de swap de cgroup; el swap del host no salvará a un contenedor que esté configurado para no usarlo.
5. ¿Tienes monitorización de presión de memoria (PSI), actividad de swap y latencia de disco? Si no, vas a ciegas con instrumentos que no instalaste.

Checklist B: Desplegar un swapfile seguro en Ubuntu 24.04 (root ext4)

1. Confirma tipo de sistema de ficheros: findmnt -no FSTYPE / debería ser ext4/xfs.
2. Revisa swap actual: swapon --show.
3. Si redimensionas, asegura que el uso de swap sea bajo y que la RAM tenga margen; entonces swapoff el archivo.
4. Crea/redimensiona con fallocate o dd (fallocate está bien en ext4).
5. Establece permisos: chmod 600.
6. Formatea swap: mkswap.
7. Habilita: swapon.
8. Persiste en /etc/fstab (o confía en la configuración existente de Ubuntu si está presente).
9. Valida con free -h y swapon --show.

Checklist C: Estabilizar un host en thrash (recuperar el control)

1. Confirma thrash: vmstat 1 y cat /proc/pressure/memory.
2. Identifica al culpable: ps/smem, luego métricas a nivel de aplicación.
3. Reduce la carga: detén workers no esenciales, pausa jobs por lotes, baja la concurrencia.
4. Libera memoria de forma segura: reinicia al culpable si tiene fuga, o vacía caches solo si entiendes el impacto (generalmente no deberías).
5. Solo entonces considera cambiar swap/zram como mitigación a corto plazo.
6. Tras la estabilidad: arregla la causa raíz (fuga de memoria, límites erróneos, subdimensionamiento o vecino ruidoso).

Tres historias corporativas (anonimizadas, plausibles, técnicamente dolorosas)

Incidente causado por una suposición errónea: “El swap está deshabilitado en contenedores, así que el host no importa.”

Un equipo ejecutaba un conjunto de servicios Java y Node en hosts Ubuntu bajo un runtime de contenedores. Creían que el swap era “un asunto de contenedor”,
y que deshabilitar el swap a nivel host era inofensivo porque “los contenedores ya tienen límites de memoria”.
Deshabilitaron el swap en todo el entorno para “hacer el rendimiento más predecible”.

El primer signo de problemas no fue el rendimiento. Fue la disponibilidad. Picos periódicos—olas de despliegues, calentamientos de caché, algunos jobs por lotes de clientes—
comenzaron a causar OOM kills. No reinicios limpios, tampoco. El kernel mataba lo más grande que encontraba en el cgroup en ese momento,
que ocasionalmente era un sidecar de logging y otras veces el proceso principal de la API.

La suposición errónea fue sutil: los límites de cgroup estaban fijados, pero los picos eran legítimos.
Sin swap, no había un buffer para absorber picos transitorios. El equipo había tuneado los heaps de JVM cerca de los límites y asumió que el resto de memoria
(asignaciones nativas, mmap, overhead de JIT) se comportaría.

Una vez reintroducido el swap—con moderación y swappiness conservadora—los eventos OOM cayeron drásticamente. El rendimiento no se volvió “impredictible”.
Se volvió supervivible. La solución real, después, fue más RAM disponible y límites de contenedor más realistas.
El swap no fue la solución definitiva. Fue el cinturón de seguridad.

Optimización que salió mal: “Poner swap en el NVMe más rápido y subir swappiness para mejorar la caché.”

Otra organización tenía NVMe brillantes en todas partes y una cultura que valoraba el tuning ingenioso. Alguien propuso: poner swap en NVMe,
fijar swappiness alto y dejar que el kernel expulse páginas frías para que crezca la caché de archivos. Durante un tiempo, parecía funcionar en benchmarks.

Luego llegó la realidad: un host de carga mixta ejecutando una base de datos, una pila de métricas y algunos jobs por lotes. Durante una ejecución diaria por lotes,
la presión de memoria subió y el kernel empezó a intercambiar. El NVMe, ya ocupado con escrituras de base de datos y compactaciones, llegó a la saturación.
La latencia subió. Las consultas de la base de datos se ralentizaron. Los reintentos aumentaron la carga. El sistema empezó a swapear más porque más procesos esperaban más tiempo,
manteniendo la memoria ocupada. Bucle de feedback clásico.

Lo peor: los gráficos eran confusos. La CPU no estaba al límite. La red estaba bien. El equipo miraba métricas de aplicación
mientras el host en silencio encolaba E/S como si coleccionara estampillas.

La solución final fue poco sexy: bajar swappiness, aislar el job por lotes en otra clase de nodo y dejar de poner swap en el mismo radio de blast de I/O que la base de datos.
La lección no fue “swap es malo”. La lección fue “swap es I/O”, y la E/S es un recurso compartido tanto si lo reconoces como si no.

Práctica aburrida pero correcta que salvó el día: “Mantuvimos swap pequeño, zram y alertas de presión.”

Un equipo de plataforma operaba una flota de VMs Ubuntu 24.04 con RAM modesta. Tenían un estándar simple:
un pequeño swapfile en SSD, zram habilitado en tamaño conservador y alertas en PSI y tasas de swap-in.
Sin heroísmos. Sin argumentos de “swap siempre es malvado”. Solo valores por defecto con guardarraíles.

Un día, una actualización de un agente de un proveedor introdujo una fuga de memoria. El agente no era crítico, pero se ejecutaba en todas partes.
A lo largo de varias horas, la presión de memoria fue subiendo. En hosts sin swap, este tipo de fuga suele producir OOMs súbitos y reinicios en cascada.

En esa flota, los hosts degradaron lentamente: PSI empezó a subir, las tasas de swap-in aumentaron y la alerta saltó mientras los sistemas todavía eran accesibles.
Los ingenieros iniciaron sesión, vieron al culpable y revertieron el paquete del agente.
La “solución” fue directa porque el incidente era observable y los sistemas permanecieron interactivos el tiempo suficiente para actuar.

El swap no previno la fuga. La monitorización no previno la fuga. La combinación evitó que un mal despliegue se convirtiera en una caída de flota.
Esto es a lo que se parece la confiabilidad la mayoría de los días: aburrida, medible y silenciosamente efectiva.

Preguntas frecuentes (FAQ)

1) ¿El swap en SSD es seguro para el disco?

Usualmente sí. Los SSD modernos tienen wear-leveling y resistencia muy superiores a los primeros discos de consumo. Revisa métricas SMART del NVMe y tus volúmenes de escritura.
Si estás haciendo swap constantemente, tienes un problema de capacidad, no un “problema de swap”.

2) ¿Cuánto swap debería usar en Ubuntu 24.04?

Para servidores: a menudo 2–8 GiB como búfer de seguridad, más si tienes picos ocasionales y toleras ralentizaciones. Para escritorios/portátiles: suficiente para suavizar picos,
y suficiente para hibernación si la usas. Si necesitas hibernar, dimensiona swap aproximadamente a la RAM (las necesidades exactas varían con la compresión y la carga).

3) ¿Swapfile o partición de swap?

Swapfile es más fácil de redimensionar y automatizar. Una partición de swap puede ser más simple para hibernación y evita restricciones específicas de sistemas de ficheros.
En ext4, swapfile es una buena opción por defecto.

4) ¿Debería poner swappiness a 1 o 0?

No por reflejo. Valores como 10–30 son razonables en muchos servidores para preferir la RAM. Poner 0 puede comportarse diferente a “casi nunca swap”
y puede causar patrones de reclaim desagradables bajo presión.

5) ¿Por qué se usa swap incluso cuando tengo RAM “libre”?

Porque “libre” no es el único objetivo. El kernel equilibra memoria anónima y caché de archivos, y puede mantener la caché caliente empujando páginas anónimas frías.
Fíjate en available en free -h, no solo en free.

6) ¿zram sustituye al swap en SSD?

Lo complementa. zram es relativamente rápido y evita I/O a disco, pero usa CPU y aún consume RAM (comprimida). El swap en SSD es más lento pero ofrece mayor respaldo.
Un patrón común es zram con alta prioridad, swap SSD con menor prioridad.

7) ¿Puedo desactivar el swap por completo?

Sí, pero hazlo solo si has probado picos de memoria, tienes límites de memoria correctos y aceptas que los OOM kills ocurrirán antes y de forma más abrupta.
Desactivar swap no arregla fugas de memoria ni nodos subdimensionados. Solo cambia el modo de fallo.

8) ¿Cómo sé si el swap está causando mi latencia?

Busca actividad activa de swap-in/out en vmstat, PSI de memoria elevado y latencia/encolamiento de disco en iostat.
Un alto uso de swap por sí solo no es prueba; la actividad de swap alta correlacionada con stalls sí lo es.

9) ¿Mover el swap a otro SSD ayudará?

Puede hacerlo, si el dispositivo actual está contestado. El rendimiento del swap es sobre todo latencia bajo encolamiento.
Poner swap en el mismo dispositivo ocupado por la base de datos puede magnificar los peores momentos.

Próximos pasos que puedes hacer hoy

Si ejecutas Ubuntu 24.04 en SSD, la línea base sensata es: mantén un swapfile modesto, asegura que TRIM esté habilitado,
y ajusta swappiness solo después de haber medido la presión real de memoria. Añade zram si ayuda a tu clase de host, no porque sea tendencia.

Haz estas tres cosas a continuación:

1. Mide: ejecuta swapon --show, vmstat 1, iostat -xz 1 y revisa /proc/pressure/memory durante un periodo de lentitud.
2. Decide: si estás en thrash, arregla el conjunto de trabajo (límites, fugas, capacidad). Si solo llevas páginas frías, no reacciones en exceso.
3. Endurece: mantiene swap modesto, establece un swappiness conservador (a menudo 10–30 en servidores) y alerta sobre presión de memoria antes de que los usuarios te alerten.

El swap en SSD no es un pecado. Es una herramienta. Úsala como tal: con mediciones, con objetivos claros y con un plan para cuando no sea suficiente.