Errores comunes con swapfile en Debian 13: Crearlo correctamente (permisos, fstab, prioridad)

Hechos y contexto (por qué los swapfiles siguen dando problemas)

Los swapfiles no son nuevos. Lo nuevo es cuántas capas pueden interferir: sistemas de archivos copy-on-write, cifrado, límites de memoria de cgroups, zram y el orden de unidades de systemd. Un swapfile puede existir, estar “habilitado” y aun así ser inútil (o perjudicial) si es lento, está fragmentado, está en el sistema de archivos equivocado o compite con otro dispositivo de swap con prioridad más alta.

8 hechos breves y un poco de historia

1. El swap precede a Linux: los sistemas tipo UNIX han usado paginación desde los años 70; Linux heredó el concepto pronto y ha iterado mucho el comportamiento del VM desde entonces.
2. Las particiones de swap solían ser la respuesta por defecto porque eran predecibles: bloques contiguos, sin sorpresas de metadatos del sistema de archivos.
3. Los swapfiles históricamente fueron “de segunda clase” en algunos sistemas de archivos porque el mapeo de bloques era más difícil, la fragmentación afectaba más y los requisitos de hibernación eran estrictos.
4. Los kernels modernos pueden usar swapfiles eficientemente en sistemas de archivos tradicionales (ext4/XFS) si el archivo está correctamente asignado y no es sparse—pero la gente todavía crea swapfiles sparse por accidente.
5. Btrfs complicó los swapfiles: copy-on-write y compresión chocan con las expectativas del swap. Los kernels modernos lo soportan con restricciones (nocow, sin compresión, asignación correcta), pero sigue siendo fácil hacerlo mal.
6. La prioridad existe desde hace mucho: Linux puede repartir E/S de swap entre áreas de igual prioridad; no es simplemente “elegir una”. Prioridades mal configuradas crean comportamientos sorprendentes.
7. Swappiness no es una “perilla de velocidad”; es una perilla de política. Muchos equipos la usan mal como arreglo de rendimiento y luego se preguntan por qué la latencia empeora bajo presión.
8. La hibernación es otra bestia: requiere que la ruta de resume encuentre el área de swap exacta donde vive la imagen; los swapfiles pueden funcionar, pero solo si la configuración de resume coincide con la realidad.

Una cita que vale la pena tener sobre tu terminal:

«La esperanza no es una estrategia.» — Gen. Gordon R. Sullivan

La configuración de swap es el lugar perfecto para dejar de esperar y empezar a actuar.

Cómo debería verse “bien” en Debian 13

Una configuración correcta de swapfile en Debian 13 tiene estas propiedades:

• El swapfile es no-sparse (bloques reales asignados).
• Los permisos son 0600, propiedad de root.
• Vive en un sistema de archivos que soporta swapfiles de forma segura para tu caso (ext4 y XFS son la opción segura; Btrfs requiere cuidado extra; ZFS es una conversación aparte).
• Está habilitado al arrancar vía /etc/fstab (o una unidad de systemd), y puedes probarlo con swapon --show.
• La prioridad es deliberada: sabes qué área de swap debe usarse primero y por qué.
• Hay monitorización: puedes ver la presión de memoria, uso de swap y fallos de página mayores antes de que los usuarios reporten timeouts.

Dos verdades sobre swap que puedes colgar en la pared:

• Swap no es un sustituto de la planificación de capacidad. Es una red de seguridad, no un colchón permanente.
• Si dependes del swap para rendimiento en estado estable, estás construyendo un generador de latencia.

Broma #1: El swap es como la cafeína: útil en emergencias, pero si forma parte de tu dieta diaria, algo upstream está roto.

Guion de diagnóstico rápido

Cuando un sistema Debian se siente lento y sospechas del swap, quieres identificar el cuello de botella en minutos, no en horas. Aquí está el orden que consistentemente llega a la causa raíz.

Primero: confirma que el swap existe y está activo

• Comprueba las áreas de swap habilitadas y sus prioridades.
• Confirma que el swapfile no está siendo ignorado silenciosamente por permisos o restricciones del sistema de archivos.

Segundo: confirma que hay presión de memoria (no solo CPU o I/O)

• Revisa MemAvailable, la tasa de swap in/out y los fallos de página mayores.
• Busca OOM kills: son el síntoma más ruidoso de “swap ausente o inefectivo”.

Tercero: determina si el swap está ayudando o perjudicando

• Si la E/S de swap es alta y la latencia del disco aumenta, estás en territorio de thrash.
• Si el uso de swap es moderado y estable y la máquina sigue respondiendo, el swap está haciendo su trabajo.

Cuarto: aisla la carga culpable

• Identifica qué procesos aumentan el RSS o causan fallos de página.
• Comprueba límites de cgroup y ajustes de memoria de contenedores si aplica.

Quinto: decide la acción

• Corto plazo: añade RAM, añade swap, reduce concurrencia o mata procesos fuera de control.
• Medio plazo: arregla fugas de memoria, ajusta tamaños y asegura que la configuración de swap sea sensata.

Tareas prácticas: comandos, salidas, decisiones

A continuación hay tareas prácticas que puedes ejecutar en Debian 13. Cada una incluye: el comando, qué significa la salida típica y qué decisión tomar a partir de ella. Este es el kit para dejar de adivinar.

Task 1 — Ver si el swap está habilitado (y su prioridad)

cr0x@server:~$ swapon --show --output=NAME,TYPE,SIZE,USED,PRIO
NAME      TYPE  SIZE  USED PRIO
/swapfile file   8G  256M   -2

Significado: El swap está habilitado y en uso (256M). La prioridad es -2; las prioridades negativas son normales para swapfiles a menos que la definas.

Decisión: Si no aparece nada, no tienes swap activo. Arréglalo antes de tocar cualquier ajuste.

Task 2 — Verifica que el kernel reconoce el swap

cr0x@server:~$ cat /proc/swaps
Filename                                Type            Size            Used            Priority
/swapfile                               file            8388604         262144          -2

Significado: El kernel ve el swapfile; size y used están en KiB.

Decisión: Si el swapfile falta aquí pero existe en disco, la activación falló—revisa permisos, fstab y restricciones del sistema de archivos.

Task 3 — Comprueba la presión de memoria de un vistazo

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        27Gi       1.2Gi       412Mi       3.0Gi       2.8Gi
Swap:          8.0Gi       256Mi       7.8Gi

Significado: “available” es el mejor indicador rápido; 2.8Gi disponible sugiere que hay presión pero no es catastrófico. El swap está ligeramente usado.

Decisión: Si “available” es ínfimo y el uso de swap sube rápidamente, te diriges a thrash o OOM.

Task 4 — Determina si está ocurriendo swapping ahora mismo

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 262144 1248932 212344 2912456    0    0    12    45  241  512  9  3 87  1  0
 1  0 262144 1251120 212352 2911988    0    0     0    16  198  430  7  2 90  1  0
 3  1 270336  312144 212360 3014332  512 1024   800  1200  412  980 18  7 52 23  0
 2  1 285696  140512 212368 3040012  768 2048   900  1500  430 1100 20  8 41 31  0
 1  0 285696  210224 212376 3038008    0    0   110   220  260  600 11  4 83  2  0

Significado: Las columnas si/so muestran swap-in/out por segundo. Picos (512/1024, etc.) indican swapping activo.

Decisión: Si si/so sostenidos son distintos de cero y wa sube, probablemente tienes presión de memoria más contención de I/O. Identifica la carga y considera añadir RAM o reducir huella de memoria.

Task 5 — Busca OOM kills (el “recibo de que no tuviste plan”)

cr0x@server:~$ journalctl -k -g "Out of memory" -n 10 --no-pager
Dec 30 10:12:44 server kernel: Out of memory: Killed process 24891 (java) total-vm:14688208kB, anon-rss:12710492kB, file-rss:1420kB, shmem-rss:0kB, UID:1000 pgtables:27820kB oom_score_adj:0

Significado: El kernel mató un proceso porque no pudo recuperar memoria lo bastante rápido.

Decisión: Si ocurre OOM y el swap está ausente o es pequeño, añade swap como red de seguridad—pero también corrige la demanda de memoria. Si el swap existe y aun así ocurre OOM, puede que el swap sea inutilizable (problema del sistema de archivos) o haya límites en memcg.

Task 6 — Confirma permisos del swapfile (seguridad y corrección)

cr0x@server:~$ ls -lh /swapfile
-rw------- 1 root root 8.0G Dec 30 09:58 /swapfile

Significado: -rw------- es 0600. Eso es lo que quieres. El swap puede contener datos sensibles.

Decisión: Si ves 0644 o cualquier cosa distinta a 0600, corrígelo inmediatamente y vuelve a habilitar swap si hace falta.

Task 7 — Detectar un swapfile sparse (problemas silenciosos de rendimiento y activación)

cr0x@server:~$ filefrag -v /swapfile | head
Filesystem type is: ef53
File size of /swapfile is 8589934592 (2097152 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..  65535:   532480..  598015:  65536:
   1:    65536.. 131071:   598016..  663551:  65536:
   2:   131072.. 196607:   663552..  729087:  65536:
 /swapfile: 3 extents found

Significado: Pocos extentes es bueno: probablemente lo bastante contiguo. Un archivo sparse mostraría huecos, y algunas herramientas advertirán en la activación.

Decisión: Si ves muchos extentes (cientos/miles) en discos giratorios, espera que la E/S de swap sea dolorosa. Recrea el swapfile con un método que asigne contiguamente y guárdalo en almacenamiento rápido.

Task 8 — Confirma el tipo de sistema de archivos bajo el swapfile

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

Significado: El swapfile está en ext4: generalmente seguro y sencillo.

Decisión: Si está en btrfs o zfs, lee la sección de peculiaridades del sistema de archivos antes de declarar victoria.

Task 9 — Comprueba que la entrada de fstab se usa (y no se ignora)

cr0x@server:~$ grep -nE 'swap|swapfile' /etc/fstab
12:/swapfile none swap sw,pri=10 0 0

Significado: Tienes una entrada explícita de swapfile con prioridad 10.

Decisión: Si no hay línea de swap, dependes de swapon manual o de un ayudante de la distro. Para servidores, haz que el comportamiento de arranque sea determinista vía fstab o systemd.

Task 10 — Prueba la activación ahora (captura errores de inmediato)

cr0x@server:~$ sudo swapoff /swapfile
cr0x@server:~$ sudo swapon /swapfile
cr0x@server:~$ swapon --show
NAME      TYPE  SIZE USED PRIO
/swapfile file   8G   0B   10

Significado: La reactivación tuvo éxito y la prioridad se aplicó.

Decisión: Si swapon da errores (permisos, huecos, no soportado), arregla el problema subyacente en lugar de forzarlo.

Task 11 — Mide síntomas de latencia de I/O del dispositivo de swap

cr0x@server:~$ iostat -xz 1 3
Linux 6.12.0-amd64 (server) 	12/30/25 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          14.21    0.00    5.10   18.33    0.00   62.36

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz aqu-sz  %util
nvme0n1          8.00    512.0     0.00   0.00   0.45    64.0     65.00   8192.0     0.00   0.00   4.80   126.0   0.32  12.00

Significado: Iowait elevado junto con altas tasas de escritura podría ser swap-out. En NVMe, unos pocos ms pueden estar bien; en HDD, aquí es donde los sistemas mueren lentamente.

Decisión: Si %iowait y await suben durante presión de memoria, el swap contribuye; mueve el swap a almacenamiento más rápido o reduce el swapping.

Task 12 — Inspecciona swappiness y decide si tocarlo

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

Significado: Comportamiento por defecto: el kernel intercambiará páginas bajo presión con una política equilibrada.

Decisión: No apliques vm.swappiness=1 por copia. Ajústalo solo con un objetivo claro: p. ej., cargas sensibles a latencia que deben evitar el swap, o sistemas con memoria limitada donde prefieres reclamar cache antes.

Task 13 — Confirma si zram está presente (y compitiendo)

cr0x@server:~$ swapon --show --output=NAME,TYPE,SIZE,USED,PRIO
/dev/zram0 partition  2G  0B   100
/swapfile  file       8G  0B    10

Significado: zram tiene prioridad mucho mayor, por lo que se usará primero.

Decisión: Esto suele estar bien (swap comprimido en RAM es rápido), pero debes saber que existe o interpretarás mal resultados de rendimiento. Si zram es demasiado pequeño, aún puedes llegar a usar swap en disco bajo presión sostenida.

Task 14 — Si te importa la hibernación: localiza el offset del swap (solo swapfile)

cr0x@server:~$ sudo filefrag -v /swapfile | awk '/^ *0:/{print $4}' | tr -d '.'
532480

Significado: Este es el offset físico del primer extent (en unidades de bloques del sistema de archivos), usado por algunas configuraciones de hibernación para calcular resume_offset.

Decisión: Si hibernas, necesitas un mapeo estable del swapfile y la configuración de resume correcta. Si no hibernas, no adaptes el sistema a un caso de uso que no tienes.

Crear un swapfile de la forma aburrida y correcta

Hay dos enfoques generales: asignar bloques con fallocate, o escribir ceros con dd. En ext4/XFS modernos, fallocate suele ser rápido y correcto. En algunos sistemas de archivos o configuraciones, fallocate puede crear extentes de formas indeseadas o incluso fallar. El punto no es la ideología; es el comportamiento predecible.

Recomendado: swapfile en ext4/XFS usando fallocate

Este es el camino limpio para la mayoría de servidores Debian 13 en ext4/XFS.

cr0x@server:~$ sudo swapoff -a
cr0x@server:~$ sudo rm -f /swapfile
cr0x@server:~$ sudo fallocate -l 8G /swapfile
cr0x@server:~$ sudo chmod 600 /swapfile
cr0x@server:~$ sudo mkswap /swapfile
Setting up swapspace version 1, size = 8 GiB (8589930496 bytes)
no label, UUID=8b0a9a2e-35e6-4f1a-bf94-7a843e62c2e6
cr0x@server:~$ sudo swapon /swapfile
cr0x@server:~$ swapon --show
NAME      TYPE  SIZE USED PRIO
/swapfile file   8G   0B   -2

Por qué estos pasos, en este orden:

• swapoff -a asegura que no estás modificando un área de swap activa (sí, la gente lo hace).
• Recrear evita rarezas heredadas (huecos, banderas de compresión, CoW). El swap no es un copo de nieve; trátalo como reemplazable.
• chmod 600 previene filtraciones y evita que swapon se queje o rechace en entornos estrictos.
• mkswap escribe el encabezado de swap. Sin él, el kernel no sabe qué es el archivo.

Cuándo usar dd en su lugar

Si estás en un sistema de archivos donde fallocate produce un archivo algo sparse, falla o genera extentes raros, usa dd para forzar la asignación. Es más lento, pero suele ser honesto.

cr0x@server:~$ sudo rm -f /swapfile
cr0x@server:~$ sudo dd if=/dev/zero of=/swapfile bs=1M count=8192 status=progress
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 9 s, 954 MB/s
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 9.00726 s, 953 MB/s
cr0x@server:~$ sudo chmod 600 /swapfile
cr0x@server:~$ sudo mkswap /swapfile
Setting up swapspace version 1, size = 8 GiB (8589930496 bytes)
no label, UUID=52b75f13-10bd-4b0a-89c7-92b9c2aa9916
cr0x@server:~$ sudo swapon /swapfile

Regla de decisión: Si filefrag muestra un número ridículo de extentes, o la activación se queja de huecos, recréalo con dd o mueve el swapfile a un sistema de archivos más apropiado.

Broma #2: Un swapfile sparse es como un cable de alimentación “inalámbrico”: técnicamente existe, pero no es lo que querías.

Seguridad: permisos y a dónde van los datos de swap

El swap puede contener fragmentos de cualquier cosa: material privado de TLS en memoria, tokens de sesión, credenciales en texto plano que vivieron en un buffer por un milisegundo de más. Tu swapfile debe ser root-owned y modo 0600. Eso no es paranoia. Es lunes.

Si tu disco está cifrado (LUKS), el swap hereda esa protección cuando vive dentro del volumen cifrado. Si no está cifrado y manejas datos sensibles, replantea el modelo de amenazas. “Es solo swap” es cómo terminas explicando a cumplimiento por qué el contenido de memoria era recuperable de un disco desmantelado.

fstab: entradas, orden y trampas

El swap que no se levanta al arrancar es swap que no tienes. Para servidores, me gusta /etc/fstab porque es explícito y revisable. También puedes usar unidades de swap de systemd, pero acabarás depurándolo con los mismos primitivas.

Una buena entrada de fstab para swapfile

cr0x@server:~$ sudo sh -c 'printf "%s\n" "/swapfile none swap sw,pri=10 0 0" >> /etc/fstab'
cr0x@server:~$ tail -n 3 /etc/fstab
# swap was on /dev/sda3 during installation
/swapfile none swap sw,pri=10 0 0

Significado: El sistema activará /swapfile al arrancar con prioridad 10.

Decisión: Elige una prioridad intencionalmente. Si tienes múltiples áreas de swap, la prioridad decide cuál se usa primero (y si el kernel hace striping).

Trampas comunes en fstab que te hacen perder horas

• Ruta equivocada: creaste /swapfile pero escribiste /swap.img.
• Espacios en blanco o caracteres ocultos: copiar/pegar desde un chat puede agregar espacios no separables. Sí, lo he visto.
• Swapfile en un montaje que aparece tarde: si /swapfile vive en un sistema de archivos separado que falla al montarse, el swap no se activará. Esa falla puede ser silenciosa a menos que leas los logs de arranque.
• Asumir que fstab implica éxito: implica un intento. Verifica con swapon --show después del arranque.

Comprueba si systemd realmente lo activó

cr0x@server:~$ systemctl status swapfile.swap --no-pager
Unit swapfile.swap could not be found.

Significado: No tienes una unidad explícita llamada swapfile.swap. Con fstab, systemd genera unidades dinámicamente; el nombre varía según el encoding de la ruta.

Decisión: No persigas nombres de unidades primero. Confirma la activación vía swapon, luego inspecciona las unidades generadas si hace falta:

cr0x@server:~$ systemctl list-units --type=swap --all --no-pager
  UNIT           LOAD   ACTIVE SUB    DESCRIPTION
  dev-zram0.swap loaded active active /dev/zram0
  swapfile.swap  loaded active active /swapfile

LOAD   = Reflects whether the unit definition was loaded.
ACTIVE = The high-level unit activation state.
SUB    = The low-level unit activation state.

Decisión: Si la unidad de swap falta o falló, inspecciona los logs de arranque y las propiedades del swapfile en lugar de ajustar swappiness como mecanismo de afrontamiento.

Prioridad de swap: qué hace y cómo usarla

La prioridad es donde el “funciona en mi portátil” se vuelve comportamiento confuso en servidores. Linux usa la prioridad de swap para decidir de qué áreas de swap asignar. La prioridad más alta se usa primero. Áreas con la misma prioridad pueden usarse de forma balanceada (piensa: repartir I/O), lo cual puede ser bueno si tienes múltiples dispositivos igualmente rápidos, y muy malo si accidentalmente haces striping entre un NVMe rápido y un HDD viejo y triste.

Patrones prácticos de prioridad

• zram primero (alta prioridad): usa swap comprimido en RAM para manejar presiones breves sin tocar disco.
• swap en disco rápido segundo: swapfile/partición NVMe como siguiente nivel.
• swap en disco lento al final (o nunca): el swap en HDD puede mantener vivo al kernel, pero castigará la latencia.

Configurar prioridad en fstab

Ejemplo: preferir zram y luego swapfile.

cr0x@server:~$ sudo sed -i 's#^/swapfile .*#\/swapfile none swap sw,pri=10 0 0#' /etc/fstab
cr0x@server:~$ sudo swapoff /swapfile
cr0x@server:~$ sudo swapon /swapfile
cr0x@server:~$ swapon --show --output=NAME,SIZE,PRIO
NAME      SIZE PRIO
/dev/zram0   2G  100
/swapfile    8G   10

Decisión: Si ves prioridades iguales en medios desiguales, arréglalo. La previsibilidad vence al striping accidental.

Saber qué significa “priority -2”

Cuando ejecutas swapon sin especificar prioridad, el kernel asigna un valor por defecto. Las particiones de swap a menudo reciben prioridad por defecto más alta que los swapfiles dependiendo de cómo se activan. Esto importa cuando tienes ambos y asumes que “el nuevo swapfile” está tomando efecto, mientras el sistema sigue machacando la partición de swap antigua.

cr0x@server:~$ swapon --show --output=NAME,TYPE,SIZE,USED,PRIO
/dev/sda2 partition  4G  1.2G   -1
/swapfile  file       8G  128M   -2

Decisión: Si quieres que el swapfile sea preferido, establece pri más alto que la partición (o deshabilita la partición). No asumas.

Peculiaridades según el sistema de archivos (ext4, XFS, Btrfs, ZFS)

Aquí es donde viven la mayoría de las “trampas” de swapfile. El subsistema de swap necesita mapeo de bloques estable. Algunos sistemas de archivos adoran mover bloques por buenas razones (copy-on-write, defrag, reflinks). El swap no comparte ese entusiasmo.

ext4: la opción por defecto por una razón

Los swapfiles en ext4 suelen ser seguros. Tus riesgos principales:

• Crear un archivo sparse (común al usar truncate o ciertos comportamientos de fallocate en configuraciones raras).
• Poner swap en un sistema de archivos muy fragmentado (más doloroso en HDD que en SSD).
• Permisos erróneos u olvidar mkswap.

XFS: también seguro

Los swapfiles en XFS son generalmente correctos. Como en ext4, asegúrate de que el archivo esté correctamente asignado y los permisos sean correctos. XFS se usa ampliamente en producción y los swapfiles no son exóticos allí.

Btrfs: posible, pero deja de improvisar

Btrfs tiene características que entran en conflicto con el swap: copy-on-write, compresión y mapeo dinámico de extentes. Los kernels modernos pueden soportar swapfiles en Btrfs, pero solo si el swapfile cumple restricciones (sin CoW, sin compresión y correctamente asignado). Si no entiendes esas restricciones, crearás un swapfile que se activa hoy y falla después de un defrag o un balance.

Comprobaciones de cordura que deberías ejecutar si el swapfile está en Btrfs:

cr0x@server:~$ findmnt -no FSTYPE,TARGET /swapfile
btrfs /
cr0x@server:~$ lsattr /swapfile
---------------------- /swapfile

Significado: Los atributos del archivo aquí no muestran NOCOW (C). Eso es sospechoso en Btrfs.

Decisión: Para swapfile en Btrfs, generalmente quieres NOCOW. Un método común es establecerlo en el archivo y luego asignarlo. Si ya escribiste datos, puede que necesites recrearlo. Flujo de ejemplo:

cr0x@server:~$ sudo swapoff /swapfile
cr0x@server:~$ sudo rm -f /swapfile
cr0x@server:~$ sudo truncate -s 0 /swapfile
cr0x@server:~$ sudo chattr +C /swapfile
cr0x@server:~$ sudo fallocate -l 8G /swapfile
cr0x@server:~$ sudo chmod 600 /swapfile
cr0x@server:~$ sudo mkswap /swapfile
Setting up swapspace version 1, size = 8 GiB (8589930496 bytes)
no label, UUID=0e1c4a2d-5d8d-4c08-a5c8-40db51b4dfc3
cr0x@server:~$ sudo swapon /swapfile

Qué vigilar: Si swapon falla con “Invalid argument” o se queja de huecos, los extentes del archivo no son aceptables. No lo forces; mueve el swap a una partición de swap o a un sistema de archivos no CoW.

ZFS: swapfile suele ser la herramienta equivocada

En ZFS, los swapfiles son notoriamente complicados porque ZFS es copy-on-write y no ofrece las mismas garantías que espera el swap. Muchos operadores usan una partición de swap o un zvol para swap. Si estás ejecutando Debian en ZFS root, tu plan de “swapfile en dataset ZFS” puede convertirse en una trampa de rendimiento y fiabilidad.

Guía pragmática:

• Si estás en ZFS y quieres swap, prefiere una partición de swap dedicada o un zvol configurado apropiadamente.
• Si debes usar un swapfile, prueba exhaustivamente bajo presión de memoria, confirma que snapshots/recordsize/compresión no te perjudican y espera sorpresas desagradables.

Ajustes de rendimiento y fiabilidad (qué importa, qué no)

El rendimiento del swap trata principalmente de la latencia del almacenamiento y evitar swapping patológico. Un swapfile perfectamente ajustado en almacenamiento lento sigue siendo almacenamiento lento. Tu objetivo no es “nunca hacer swap”. Tu objetivo es “mantenerse vivo y respondiendo bajo la presión esperada”.

Swappiness: política, no magia

El swappiness por defecto (a menudo 60) está bien para sistemas de propósito general. Bajarlo puede reducir el swapping pero puede aumentar la presión sobre la cache de página y causar modos de fallo diferentes (como OOMs más tempranos en ciertos patrones). Aumentarlo puede mantener más cache fuera de RAM, pero puede expulsar páginas anónimas antes y perjudicar la latencia interactiva.

cr0x@server:~$ sudo sysctl -w vm.swappiness=20
vm.swappiness = 20
cr0x@server:~$ sudo sh -c 'printf "%s\n" "vm.swappiness=20" > /etc/sysctl.d/99-swappiness.conf'
cr0x@server:~$ sysctl vm.swappiness
vm.swappiness = 20

Decisión: Cambia swappiness solo después de verificar que el swap está correctamente configurado y puedes reproducir el patrón de la carga. De lo contrario solo cambias cómo falla el sistema.

Cómo se ve el “swap thrash”

El thrash ocurre cuando el sistema pasa más tiempo moviendo páginas dentro y fuera que haciendo trabajo útil. Síntomas:

• La carga promedio sube mientras la CPU idle permanece no nula pero iowait se dispara.
• La respuesta interactiva pasa a segundos o minutos.
• vmstat muestra swap-in/out sostenido.
• La latencia del disco sube; la profundidad de cola aumenta.

cr0x@server:~$ cat /proc/pressure/memory
some avg10=0.25 avg60=0.18 avg300=0.10 total=48239210
full avg10=0.07 avg60=0.05 avg300=0.02 total=10293829

Significado: PSI (Pressure Stall Information) muestra el tiempo que las tareas se quedan bloqueadas esperando memoria. “full” indica bloqueos lo bastante severos como para que no se pueda avanzar.

Decisión: Si “full” es no trivial durante operación normal, estás infra-provisionado o mal configurado. Trátalo como un problema de capacidad o carga, no como un problema de formato de swapfile.

Prioridades y medios mixtos: no hagas striping entre NVMe y HDD

Si asignas la misma prioridad a un swap rápido y a uno lento, el kernel puede repartir la E/S de swap entre ambos. Eso arrastra el almacenamiento rápido al ritmo del lento e introduce jitter. Establece prioridades para que el dispositivo lento sea el último recurso, o desactívalo a menos que lo necesites solo como buffer contra OOM.

Tamaño: “¿cuánto swap necesito?”

Las reglas empíricas son peligrosas porque las cargas varían. Aun así, en producción uso tamaños prácticos:

• Servidores generales: 2–8 GiB de swap suele ser suficiente como red de seguridad si tienes RAM adecuada.
• Runners de build/test y hosts con JVM pesada: swap más grande puede comprar tiempo durante picos, pero debes monitorizar la latencia.
• Hibernación: el swap debe acomodar la imagen de hibernación (a menudo cercano al tamaño de RAM, a veces menos con compresión, pero no juegues con eso).

En caso de duda: dimensiona el swap para manejar un pico corto y mantener al kernel lejos del pánico/OOM, no para que un sistema con poca RAM “funcione bien”.

Tres mini-historias corporativas desde las trincheras del swapfile

Mini-historia 1: El incidente causado por una suposición errónea

Una empresa mediana ejecutaba Debian en una flota de trabajadores de CI. Estandarizaron un paso de “8G swapfile en todas partes”. Alguien escribió un snippet de automatización que hacía: crear archivo, ejecutar mkswap, añadir a fstab, listo. Funcionó en staging. Funcionó mayormente en producción. “Mayormente” es donde vienen los incidentes.

Los workers tenían una mezcla de sistemas de archivos porque procurement tenía personalidad: nodos antiguos eran ext4; nodos nuevos eran Btrfs porque alguien quería snapshots. La automatización no detectó el tipo de sistema de archivos. En nodos Btrfs, el swapfile existía pero la activación fallaba en algunos arranques y tenía éxito en otros después de operaciones de mantenimiento. Los síntomas eran inconsistentes: algunos nodos estaban bien, otros mataban procesos por OOM durante horas punta.

La suposición errónea fue simple: “un swapfile es un swapfile”. No lo es. El comportamiento del sistema de archivos importa, especialmente copy-on-write y la semántica de defrag. El equipo perdió un día persiguiendo “comportamiento aleatorio del kernel” y “fugas de memoria de JDK” antes de que alguien comparara swapon --show entre nodos y notara que la mitad de la flota no tenía swap activo.

La solución fue aburrida y decisiva: detectar Btrfs, crear swap en una partición dedicada para esos hosts (o configurar Btrfs swap correctamente con NOCOW y recrear), y añadir una comprobación al arranque que alerte si el swap no está activo. El incidente no fue por el tamaño del swap; fue por una red de seguridad ausente.

Mini-historia 2: La optimización que se volvió en contra

Un equipo fintech tenía una API sensible a la latencia. Alguien leyó que el swap causa latencia, lo cual es cierto en el mismo sentido en que el fuego causa calor. Establecieron vm.swappiness=1 en toda la flota y redujeron el swap a casi cero. Las métricas se veían bien—hasta que un despliegue introdujo un aumento modesto de memoria.

Bajo carga normal, los servicios funcionaban. Bajo carga pico, la presión de memoria subió, la cache de archivos no se pudo recuperar suficiente y el kernel empezó a matar procesos por OOM en lugar de intercambiar páginas frías. La “optimización” convirtió una degradación gradual en un precipicio: las peticiones se detuvieron, los pods se reiniciaron y el equipo sufrió una clásica falla en cascada mientras los reintentos amplificaban el problema.

Habían optimizado para la vía feliz y eliminado el amortiguador para la vía infeliz. Lo más frustrante: el incidente ni siquiera fue una fuga enorme de memoria. Fue una nueva característica más un pico de tráfico más la ausencia de una red de seguridad.

Revirtieron swappiness a un valor sensato, restauraron la capacidad de swap e introdujeron una política: reducir el swapping arreglando el uso de memoria, no deshabilitando swap. El swap volvió a ser lo que debe ser: algo que te compra tiempo para intervenir en lugar de algo que oculta un infra-dimensionamiento crónico.

Mini-historia 3: La práctica aburrida y correcta que salvó el día

Un equipo de plataforma interno ejecutaba Debian 13 en un conjunto de workers stateful. Hicieron una cosa aburrida que pocos equipos priorizan: un script de verificación al arranque que comprobaba la activación del swap y registraba un error claro si no estaba presente. Era parte de su “readiness” del nodo, justo al lado del espacio en disco y la sanidad de NTP.

Durante un ciclo rutinario de actualización de kernel, un subconjunto de nodos dejó de habilitar swap después del reinicio. La razón no fue glamorosa: un cambio de almacenamiento alteró el orden de montaje y la ruta del swapfile quedó temporalmente indisponible en el momento en que systemd intentó activarlo. Nadie lo notó de inmediato—excepto la comprobación de readiness, que marcó los nodos como no saludables y evitó que se programaran cargas allí.

Eso previno un incidente desordenado. El equipo tuvo tiempo para inspeccionar journalctl, ajustar el orden (y en un par de casos reubicar el swap) y reintroducir nodos gradualmente. Los usuarios no se enteraron. La dirección nunca preguntó por qué los gráficos de latencia parecían un sismógrafo. Fue el tipo de éxito silencioso que solo obtienes con controles aburridos.

La lección: el swap no es solo rendimiento; es operabilidad. Un sistema predecible vence a uno ingenioso.

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

Esta sección es el mapa de “solo quiero que lo arreglen”. Cada error es específico, reproducible y lo bastante común como para merecer una cicatriz.

1) El swapfile existe pero no aparece listado en swapon

Síntoma: ls /swapfile muestra el archivo, pero swapon --show está vacío o no lo lista.

Causa raíz: Swap no activado (fstab ausente/incorrecto) o la activación falló al arrancar.

Solución: Ejecuta sudo mkswap /swapfile (si hace falta) y luego sudo swapon /swapfile. Añade la entrada correcta en fstab y confirma tras reiniciar.

2) swapon falla con “Operation not permitted” o “permission denied”

Síntoma: sudo swapon /swapfile da error.

Causa raíz: Permisos no 0600, propietario equivocado o políticas de seguridad aplicadas.

Solución: sudo chown root:root /swapfile && sudo chmod 600 /swapfile, luego reintenta.

3) swapon falla con “Invalid argument” en Btrfs

Síntoma: La activación falla a pesar de permisos correctos.

Causa raíz: Swapfile en Btrfs con CoW/compresión o extentes/huecos no soportados.

Solución: Recrea el swapfile con NOCOW (chattr +C antes de asignar), asegura que no esté comprimido, o usa una partición/zvol de swap.

4) El sistema arranca, pero el swap a veces falta tras reinicios

Síntoma: Swap presente en algunos arranques, faltante en otros.

Causa raíz: Carrera/orden: swapfile en un sistema de archivos que no está montado cuando se ejecuta la activación; o mantenimiento del FS cambió el mapeo de extentes de forma que el swap no lo tolera.

Solución: Pon el swap en el sistema de archivos raíz o asegura que el montaje subyacente esté disponible temprano; verifica dependencias de la unidad de systemd; considera una partición de swap para fiabilidad.

5) Un swapping intenso causa latencias 10x y timeouts

Síntoma: El tiempo de respuesta se dispara; vmstat muestra si/so sostenido; iowait se dispara.

Causa raíz: El working set no cabe en RAM; swap en almacenamiento lento; o sobrecommit de memoria por exceso de concurrencia.

Solución: Reduce la huella de memoria o la concurrencia, añade RAM, mueve swap a medios más rápidos y trata el swap como buffer de emergencia, no como sustituto de RAM.

6) Se usa swap, pero se usa primero la zona equivocada

Síntoma: Añadiste un swapfile NVMe rápido pero el sistema sigue usando una partición en HDD.

Causa raíz: Las prioridades favorecen la partición, o prioridades iguales causan striping a través de ambos.

Solución: Establece pri= explícitamente en fstab o usa swapon -p para preferir el swap más rápido, y degrada/deshabilita el swap lento.

7) La hibernación falla tras cambiar a swapfile

Síntoma: El resume falla; el sistema arranca en frío en lugar de reanudar.

Causa raíz: La configuración de resume no se actualizó para el offset del swapfile; el swapfile se movió/cambió de extentes.

Solución: Calcula el resume offset correcto y actualiza la configuración del initramfs apropiadamente, o usa una partición de swap dedicada para estabilidad en hibernación.

8) “Sin swap” fue intencional, y ahora recibes OOM kills

Síntoma: Procesos son asesinados durante picos; el sistema es inestable.

Causa raíz: Quitar el swap quitó tu amortiguador; los picos de memoria ahora son fatales.

Solución: Reintroduce un swap moderado (y monitoriza), luego arregla el uso de memoria y dimensiona correctamente los hosts.

Listas de verificación / plan paso a paso

Plan A: Servidor Debian 13 estándar en ext4/XFS (swapfile)

1. Confirma el sistema de archivos: findmnt -no FSTYPE,TARGET /swapfile. Si es ext4/XFS, procede.
2. Elige tamaño: empieza con 4–8 GiB salvo que tengas una necesidad conocida (hibernación o picos enormes).
3. Crea el swapfile: fallocate -l 8G /swapfile.
4. Establece permisos: chmod 600 /swapfile; verifica con ls -l.
5. Inicializa: mkswap /swapfile.
6. Habilita ahora: swapon /swapfile; verifica con swapon --show.
7. Hazlo persistente: añade /swapfile none swap sw,pri=10 0 0 a /etc/fstab.
8. Prueba de reinicio: reinicia en una ventana de mantenimiento; verifica swap activo tras el arranque.
9. Monitoriza: sigue el uso de swap, PSI de memoria y eventos OOM; alerta cuando el uso de swap sube o la presión “full” sea no cero por periodos prolongados.

Plan B: Root en Btrfs (usar swapfile solo si conoces las restricciones)

1. Decide si una partición de swap es más fácil: para muchos sistemas de producción, lo es.
2. Si usas swapfile: crea el archivo con NOCOW antes de asignar bloques.
3. Asegura sin compresión: no guardes el swapfile en un subvolumen/dataset comprimido.
4. Recrea en lugar de modificar: trata el swapfile como inmutable. Si cambias atributos después de escribir, te buscas problemas.
5. Verifica activación ahora y tras reinicio: si es inestable, detente y cambia de enfoque.

Plan C: Múltiples áreas de swap (zram + swap en disco)

1. Decide el orden de prioridades: zram primero; NVMe segundo; HDD último.
2. Establece prioridades explícitas: no confíes en los valores por defecto.
3. Verifica el orden efectivo: swapon --show --output=NAME,PRIO.
4. Prueba de carga de memoria: demuestra que el sistema degrada de forma gradual y no entra en thrash.

Preguntas frecuentes

1) ¿Debería usar partición de swap o swapfile en Debian 13?

En ext4/XFS: swapfile está bien y es más fácil de redimensionar. Si necesitas fiabilidad de hibernación o estás en sistemas de archivos complicados (notablemente Btrfs/ZFS), una partición (o zvol en ZFS) suele ser la opción más segura.

2) ¿Qué permisos debe tener un swapfile?

0600, propiedad de root. Cualquier otro modo es riesgo de exposición de datos y también puede causar fallos de activación según la política.

3) ¿Por qué mi swapfile muestra prioridad -2?

Es una prioridad asignada por defecto cuando no especificas una. No está necesariamente mal. Se vuelve problemático cuando tienes múltiples áreas de swap y te importa cuál se usa primero.

4) ¿Es fallocate siempre seguro para swapfiles?

Usualmente seguro en ext4/XFS. No es universalmente seguro en todos los sistemas de archivos y configuraciones. Si la activación se queja de huecos o el archivo está muy fragmentado, recréalo con dd o mueve el swap a un sistema de archivos más simple.

5) ¿Cómo sé si el swap está perjudicando el rendimiento?

Busca swap-in/out sostenido (vmstat), aumento de iowait (iostat) y presión de memoria “full” creciente (PSI). Si la latencia de respuesta sube junto con eso, estás en thrash.

6) ¿Puedo poner un swapfile en Btrfs?

Sí, pero solo si sigues las restricciones (sin CoW, sin compresión, asignación estable). Si no puedes garantizarlo, usa una partición de swap. La fiabilidad vence a la novedad.

7) ¿Qué tamaño debe tener mi swapfile para servidores?

Comúnmente 4–8 GiB como red de seguridad, luego ajusta según picos observados e historial de incidentes. Si necesitas hibernación, dimensiona explícitamente para ese caso.

8) ¿Debería poner vm.swappiness a 1 por rendimiento?

No por defecto. Puede reducir el swapping, pero también aumenta la posibilidad de OOM kills en picos. Ajústalo con evidencia del workload, no por folklore de Internet.

9) ¿Por qué no se habilita el swap al arrancar aunque fstab sea correcto?

Frecuentemente por orden de montaje: el swapfile está en un sistema de archivos que no está disponible cuando se ejecuta la activación. Revisa los logs de arranque y las unidades generadas por systemd, y considera reubicar el swap.

10) ¿zram reemplaza al swap en disco?

Es complementario. zram es excelente para absorber picos cortos rápidamente. Bajo presión sostenida, aún podrías necesitar swap en disco—o más RAM—dependiendo de la carga.

Conclusión: siguientes pasos que realmente reducen el riesgo

Si ejecutas Debian 13 en producción, trata el swap como parte del diseño del sistema, no como una casilla para marcar. Tus siguientes pasos son simples y prácticos:

1. Audita el estado de swap a nivel de flota: confirma que el swap esté habilitado, las prioridades sean intencionales y la activación sea consistente entre reinicios.
2. Arregla la corrección primero: permisos 0600, asignación no-sparse y adecuación del sistema de archivos.
3. Haz el comportamiento de arranque determinista: fstab (o unidades de swap explícitas de systemd), más una comprobación de salud que alerte cuando falte swap.
4. Mide la presión de memoria: usa vmstat, PSI y logs de OOM; no dependas de quejas de usuarios para monitorizar.
5. Usa la prioridad para evitar sorpresas: mantiene el swap rápido como prioridad y deja el swap lento como último recurso, si es que lo mantienes.

El swap no arreglará una fuga de memoria. Sin embargo, mantendrá tus sistemas en pie el tiempo suficiente para que arregles el problema real. Es un intercambio que acepto.