Ir al contenido 
Alojamiento de intercambio Determina en el día a día si un servidor sigue funcionando con normalidad ante picos repentinos o si se ralentiza bajo carga. Explico claramente cuándo el swap resulta útil como búfer y a partir de qué punto empeora los tiempos de respuesta, incluyendo el dimensionamiento, el «swappiness», los aspectos relacionados con las E/S y la supervisión.
Puntos centrales
- Red de seguridad En lugar de un fallo del sistema, el swap me da tiempo para reaccionar antes de que se cierren los servicios.
- Liberación de memoria RAM – Eliminar las páginas inactivas e incorporar la caché activa: acceso más rápido a los datos más frecuentes.
- Límite de rendimiento – El intercambio intensivo de datos y el thrashing aumentan las latencias.
- Ajuste fino – Un nivel bajo de «swappiness», Zswap/ZRAM y un almacenamiento rápido reducen la carga de E/S.
- Monitoreo – Un uso prolongado de la memoria virtual, un elevado número de errores de página y tiempos de espera de E/S son señales de alarma.
Qué hace realmente el swap en los servidores Linux
Entiendo el «swap» como virtual Memoria que traslada las páginas de memoria de la RAM al SSD/HDD que se utilizan con poca frecuencia, para que el código activo y las cachés permanezcan en la memoria RAM de alta velocidad. Para ello, el núcleo da prioridad a los datos «calientes» en la RAM y traslada las páginas «frías» al espacio de intercambio, sin cerrar los procesos de forma inmediata. De este modo, las aplicaciones que consumen mucha memoria se ejecutan en paralelo, aunque la RAM física sea limitada. Para más detalles sobre su funcionamiento, te remito a esta breve explicación sobre memoria virtual. Lo importante es que, mientras el conjunto de datos activo quepa en la RAM, el efecto sobre el tiempo de respuesta será mínimo y el servidor responderá como es de esperar.
Por qué el swap es útil en el alojamiento web: ventajas reales
Utilizo Swap porque, como Tampón Evita fallos cuando se necesita más RAM a corto plazo. Sin reserva, el OOM-Killer entra en acción y cierra procesos, lo que detiene bruscamente los servicios críticos. Con el swap, supero los picos de carga, analizo los registros y optimizo la carga antes de ampliar la RAM. Además, un uso moderado del swap aumenta la caché del sistema de archivos en la RAM, lo que acelera los accesos de lectura frecuentes. La interacción entre la RAM, la caché y el swap garantiza unos tiempos de respuesta más uniformes, siempre y cuando el intercambio no se descontrole.
Cuándo el swap frena y cómo lo detecto
En cuanto un sistema intensivo Cuando los datos se alternan entre la RAM y el espacio de intercambio, las latencias aumentan considerablemente. Esto se observa cuando el uso del swap crece de forma constante durante 10-15 minutos y los tiempos de espera de E/S se disparan. Si a esto se suma el thrashing, el servidor trabaja principalmente con transferencias de páginas en lugar de con la carga útil, por lo que las solicitudes tardan segundos en procesarse. Un valor de «swappiness» demasiado alto también provoca un traspaso innecesario, aunque aún quede RAM libre. En estas fases, el cuello de botella se desplaza claramente hacia el almacenamiento y la aplicación se vuelve lenta.
Utilizar Swappiness, Zswap y ZRAM de forma específica
Normalmente considero que la «swappiness» es bajo, por ejemplo, en el rango de 5 a 20, para que el swap solo se active cuando haya una carga real. De este modo, la memoria activa permanece más tiempo en la RAM y la E/S se mantiene más estable. Zswap comprime las páginas en la RAM antes de que se transfieran al disco; así reduzco la carga de escritura y acorto los tiempos de acceso. ZRAM crea un dispositivo de RAM comprimida que entra en acción antes que el swap físico, lo que supone una ayuda notable en VPS pequeños. Estas técnicas no sustituyen a la RAM física, sino que me proporcionan un margen de tiempo y suavizan los picos.
El tamaño adecuado de la memoria virtual según el tipo de servidor
Elijo la talla relacionado con el contexto: adecuado a la carga de trabajo, la RAM y el perfil de E/S. Los servidores web pequeños suelen necesitar entre 1 y 2 GB para amortiguar los picos de carga. Los servidores de bases de datos suelen beneficiarse de entre 4 y 8 GB para almacenar temporalmente consultas complejas o copias de seguridad. Para los VPS con poca RAM, calculo aproximadamente 1× la RAM, de modo que los contenedores no se vean limitados de forma drástica en los picos de actividad. En máquinas dedicadas de gran tamaño, suelen bastar entre 4 y 8 GB fijos, ya que ya se dispone de RAM en abundancia.
| Tipo de servidor | Tamaño del swap (valor orientativo) | Intercambio | Nota |
|---|---|---|---|
| Servidor web (pequeño/mediano) | 1-2 GB | 5-15 | Amortiguar los picos de carga, mantener la caché en la RAM |
| Servidor de base de datos | 4-8 GB | 5-10 | Almacenar en búfer los picos de consultas/copias de seguridad |
| VPS con poca memoria RAM | hasta ~1× la RAM | 10-20 | Soportar picos de carga repentinos |
| Servidores dedicados (mucha memoria RAM) | 4-8 GB | 5-10 | Deja un pequeño margen, evita el «thrash» |
IO y SSD: prolongar la vida útil y garantizar el rendimiento
Coloco el swap en rápido y SSD fiables, pero procuro no saturar el rendimiento de escritura de forma permanente. Una carga de swap constante aumenta las latencias y puede acortar la vida útil de la memoria flash. Por eso reduzco el «swappiness» y, si es necesario, activo Zswap para reducir la presión de E/S. A partir de tiempos de espera de E/S superiores a unos 20 ms, prefiero aplicar optimizaciones antes de que los usuarios noten la lentitud. Si el conjunto de trabajo supera claramente la capacidad de la RAM, amplío la memoria RAM en lugar de aumentar el espacio de intercambio.
Seguimiento: detectar a tiempo las señales de alerta
Superviso continuo Analizo la ocupación de la memoria de intercambio a lo largo del tiempo y considero críticos los picos que duran más de 10-15 minutos. Al mismo tiempo, observo las tasas de fallos de página y la actividad de kswapd, ya que esto proporciona indicios tempranos de un inicio de thrashing. Las latencias de E/S persistentemente altas y las colas cada vez más largas confirman el cuello de botella en el almacenamiento. Si se observa mucho tráfico de swap y, al mismo tiempo, hay memoria RAM libre, reduzco el valor de «swappiness» y reviso las estrategias de almacenamiento en caché. Para comprender mejor los efectos de la caché, resulta útil este artículo práctico sobre Caché del servidor y paginación.
Aplicación práctica: ejemplos de configuración y comandos
Aplico el «swappiness» consciente Mediante sysctl: vm.swappiness=10 limita la paginación agresiva. Para Zswap, activo el parámetro del kernel zswap.enabled=1 y elijo un compresor eficiente como zstd. Configuro ZRAM con una proporción de 25–50% de la RAM, compruebo los picos de carga y luego realizo los ajustes necesarios. Creo los archivos de intercambio de forma flexible mediante `fallocate`, les asigno permisos restrictivos y los activo con `swapon`. Tras los ajustes, compruebo `dmesg`, `iostat` y `vmstat` para evaluar los efectos sobre las latencias y los errores de página.
Cómo interpretar correctamente la información sobre el «swap hosting» en las comparativas de productos
Cuando reviso las ofertas, compruebo exactamente, qué estrategia de swap y qué funciones de supervisión ofrece el proveedor. Son relevantes unos valores estándar claros para la „swappiness“, métricas transparentes para las latencias de E/S y vías de actualización sencillas. Si el uso del swap es constante, opto por aumentar la RAM desde el principio, en lugar de enmascarar el problema con un swap más grande. Valoro afirmaciones como «no se necesita swap» en el contexto de perfiles de carga reales y del comportamiento de la caché. Esta guía sobre Uso de la memoria virtual en el alojamiento web.
Implementación de la memoria virtual: partición frente a archivo, prioridades y distribución
En la práctica, elijo entre una partición de swap y un archivo de swap en función de la flexibilidad y la facilidad de uso. Una Archivo de intercambio Se puede crear, ampliar o eliminar rápidamente, lo que la hace ideal para entornos dinámicos y VPS. Una Partición de intercambio tiene una estructura ligeramente más sencilla y, en algunos casos, resulta más eficiente en sistemas muy antiguos; sin embargo, la diferencia es insignificante en los núcleos modernos. Lo importante es la Priorización: Con las prioridades de swapon determino qué dispositivo se utiliza en primer lugar. Si las prioridades son iguales, la carga se distribuye entre varios dispositivos; de este modo, optimizo las operaciones de E/S y aumento el rendimiento, por ejemplo, cuando tengo dos SSD NVMe en paralelo. Si los dispositivos de swap se encuentran en soportes físicos diferentes, el sistema se beneficia de un paralelismo real; en una única matriz RAID, el efecto es, por naturaleza, menor. En Btrfs, me aseguro de colocar los archivos de swap en áreas NoCoW y sin instantáneas; en ZFS, prefiero utilizar un zvol en lugar de un archivo. La cuestión sigue siendo la misma: planifico el swap de tal manera que, en caso de necesidad, previsible y rápido responde: no es que compense la falta de memoria RAM.
Contenedores, Kubernetes y cgroups: limitar el espacio de intercambio de forma selectiva
En entornos de contenedores, utilizo el espacio de intercambio de forma más restrictiva. Muchas configuraciones de Kubernetes funcionan tradicionalmente con el swap desactivado, ya que el programador se beneficia de los límites estrictos y busca evitar picos de latencia. Cuando se permite el intercambio, lo limito por carga de trabajo mediante Cgroups (cgroup v2: memory.max, memory.high, memory.swap.max) y defino así la cantidad máxima de intercambio que puede utilizar un contenedor. Para los servicios en los que la latencia es crítica, elijo presupuestos de swap muy bajos o nulos y los protejo además con memory.low o memory.min, para que las tareas en segundo plano no les resten recursos. Para irritable En los contenedores auxiliares (por ejemplo, de copia de seguridad o de procesamiento por lotes), permito un uso moderado del swap para evitar que se cierren. Importante: superviso el nodo personalmente; si el host ya está utilizando una cantidad apreciable de swap, mantengo a raya la densidad de pods y el overcommit, en lugar de aumentar el valor de swappiness. En nodos VPS pequeños, ZRAM sirve como búfer para que los picos momentáneos de los contenedores no provoquen inmediatamente un error OOM.
Características específicas de la carga de trabajo: bases de datos, JVM y servicios en memoria
En Bases de datos Solo permito un uso moderado del swap. Unas pocas páginas inactivas almacenadas en el swap están bien; en cuanto los pools de búfer (por ejemplo, el pool de búfer de InnoDB o los búferes compartidos de PostgreSQL) empiezan a acabar en el swap en cantidades apreciables, las latencias se disparan. Por eso mantengo el valor de «swappiness» bajo, compruebo las páginas enormes transparentes (THP) y, si es necesario, configuro páginas enormes fijas cuando la pila se beneficia de ello. Para Basado en la JVM En mis aplicaciones, planifico el heap y la memoria nativa de forma conservadora, establezco Xms cerca de Xmx para que la JVM asigne el conjunto de trabajo lo antes posible y, de este modo, reduzco los fallos mayores bajo carga. Cuando el tiempo de arranque es secundario, resulta conveniente realizar un «pre-touch» del heap para evitar picos de fallos de página en el tráfico. Servicios en memoria En el caso de Redis, Memcached o determinadas cachés, a veces las bloqueo en la RAM mediante mlock o les asigno límites estrictos; prefiero un error definido a picos de latencia de varios segundos debidos al swap. Para pilas de búsqueda como Elasticsearch, preveo suficiente RAM para las cachés de archivos, ya que se benefician enormemente de la caché del sistema operativo; el swap solo debe existir como un pequeño colchón de seguridad.
NUMA y hosts de gran tamaño: garantizar latencias consistentes
En sistemas de doble zócalo o NUMA, evito una distribución desigual de la memoria que provoque picos tardíos de swap. Compruebo el parámetro `zone_reclaim_mode` y, por regla general, lo mantengo desactivado (0), para que el núcleo no recupere memoria local de forma agresiva y recurra innecesariamente al swap. Para servicios con gran huella de memoria, elijo la asignación intercalada, para evitar que un nodo NUMA se sature mientras otro aún tiene reservas; los nodos desequilibrados son un caldo de cultivo para el thrashing. Si dispongo de varios discos rápidos, defino Varios dispositivos de intercambio con la misma prioridad, para evitar el IO. Además, en máquinas grandes mantengo deliberadamente un memoria libre en la memoria RAM (margen de seguridad), para absorber simultáneamente los picos en la caché del sistema de archivos y en el espacio de usuario.
Manual de resolución de problemas en caso de picos de intercambio
Cuando aumentan las latencias y se detecta el swap, sigo un procedimiento claro:
- Análisis del estado del sistema: los comandos «free -h», «vmstat 1» e «iostat -x 1» me indican si hay poca memoria RAM, si las operaciones de E/S están saturadas y cuál es el volumen de si/so (entrada y salida del swap). Además, compruebo el tiempo de CPU de kswapd y la longitud de la cola del almacenamiento.
- Identificar la causa: con top/htop, pidstat -r -p PID, smem o pmap puedo ver qué procesos están creciendo, generan muchos «Major Faults» o alcanzan los límites de los Cgroups.
- Medidas inmediatas: reducir el «swappiness», activar «Zswap», limitar o posponer los trabajos por lotes que llamen la atención, ajustar los límites en función de su criticidad. Evito utilizar «swapoff» bajo carga, ya que aumenta la presión a corto plazo aumentado y IO se lanza al ataque.
- Ajustes posteriores: comprobar las estrategias de caché del sistema de archivos, evaluar los parámetros vfs_cache_pressure y Dirty-Writeback sin provocar que el núcleo realice un vaciado agresivo. Optimizo los planes de consulta, las ventanas de lotes y los tamaños de caché en la aplicación.
- Solución a largo plazo: ampliación de la memoria RAM y planificación de la capacidad en función de la carga de trabajo real (percentiles 95 y 99), no de los valores medios. El espacio de intercambio sigue siendo reducido, pero Fiable.
Para la notificación de alarmas, tengo en cuenta además Errores graves de página y, si están disponibles, las métricas PSI (Pressure Stall Information) del núcleo. La experiencia demuestra que el aumento de los valores de «memory.stall» guarda una estrecha relación con las quejas de los usuarios.
Seguridad y cumplimiento normativo en materia de swaps
El swap puede contener datos sensibles: contraseñas, material de clave o partes de sesiones. En entornos regulados cerrar Utilizo el swap (por ejemplo, mediante dm-crypt) para que, en caso de sustitución del hardware o de robo, no quede ninguna información en texto claro. En el caso de los SSD, utilizo, cuando procede, Discard/TRIM para el espacio de intercambio, con el fin de mantener estables el rendimiento y la vida útil. Al dar de baja un sistema, desactivo el espacio de intercambio de forma limpia, lo reinicio (mkswap) o lo sobrescribo para que no queden restos. La hibernación rara vez es relevante en los servidores; en caso de que lo sea, planifico el tamaño y la ubicación del espacio de intercambio en consecuencia y refuerzo adicionalmente el cifrado.
Detalles del sistema de archivos y del núcleo: pequeños ajustes, grandes efectos
Hay algunos detalles que dan sus frutos en la práctica. Compruebo si el Programador de E/S que se adapte al soporte (por ejemplo, mq-deadline/kyber para SSD SATA, none para NVMe modernos), con el fin de mantener bajas las latencias. En núcleos más antiguos, ajusto con cuidado vm.page-cluster (lectura anticipada de la memoria virtual), siempre que esté disponible; unas lecturas anticipadas demasiado grandes aumentan las operaciones de E/S sin aportar un beneficio real. Configuré valores como vfs_cache_pressure y los ratios de datos sucios (dirty_ratio/dirty_background_ratio) de tal forma que el núcleo no desaloje las cachés de forma precipitada y distribuya la carga de escritura de manera más uniforme. Y, por último: observo /proc/meminfo – Campos como «SwapCached», «Active(file)»/«Inactive(file)» o «Dirty» me ayudan a distinguir la dinámica de la caché de una falta real de RAM.
Planificación de la capacidad: comprender la carga de trabajo, suavizar los picos
Así se usa Swap en el día a día Ayuda a En lugar de fijarme en los fallos, mido la tasa efectiva de trabajo. Correlaciono la carga de usuarios, las tasas de solicitudes y los aciertos en la caché con el uso de la RAM a lo largo de varias semanas. Me interesa saber cuál es el caliente Qué parte de la memoria se utiliza (de forma realmente continua) y cuál es el nivel de los picos de carga. A partir de ahí, planifico un búfer de RAM que cubra las cargas del percentil 95 y 99, y mantengo el swap como red de seguridad. Paralelamente, optimizo los procesos que generan objetos grandes y de corta duración (exportaciones por lotes, transcodificación de imágenes y vídeos) dividiéndolos en fases y limitando la E/S y la CPU. De este modo, aumenta la probabilidad de que el swap solo corto se utiliza; precisamente para eso está pensado.
Resumen para la práctica
Para mí, el swap sigue siendo un Cinturón de seguridad, no es un sustituto de la RAM. Lo dimensiono de forma moderada, mantengo el «swappiness» bajo, utilizo Zswap/ZRAM cuando es necesario y realizo mediciones de forma sistemática. Si el uso del swap y las latencias de E/S aumentan de forma persistente, reacciono ajustando la configuración y ampliando la RAM, en lugar de aumentar el tamaño del swap. De este modo, utilizo el búfer de forma selectiva, mantengo el conjunto de datos activos en la RAM y consigo tiempos de respuesta constantes. Quien respete estas pautas convertirá el swap en una herramienta fiable, y no en la causa de problemas de rendimiento.
