Ir al contenido 
Te voy a enseñar cómo configurar vm.swappiness para que los servicios web y de bases de datos en los servidores de alojamiento respondan más rápido y generen menos operaciones de E/S. Con pasos claros, valores iniciales adecuados y un buen seguimiento, sacarás más partido a la memoria RAM disponible y reducirás Latencias y evitas el intercambio innecesario de memoria.
Puntos centrales
Estos puntos te ofrecen una visión general rápida para que puedas aplicar los ajustes de inmediato.
- Comportamiento de Swappiness: Determina cuándo empieza el núcleo a trasladar la RAM al espacio de intercambio.
- En relación con la carga de trabajo: Adapta los valores al tipo de aplicación, como una base de datos o una página web.
- Probar de forma temporal: Primero compruébalo en directo y luego fíjalo de forma definitiva.
- Diseño de la memoria de intercambio: Tener en cuenta el tamaño, el contexto y las prioridades.
- Monitoreo: Supervisar y ajustar las entradas y salidas (E/S), la memoria RAM y los tiempos de respuesta.
Qué es vm.swappiness y cómo funciona
El parámetro del núcleo vm.swappiness Determina la intensidad con la que Linux traslada las páginas de memoria de la RAM al espacio de intercambio. El valor actual se encuentra en el sistema de archivos pseudo en /proc/sys/vm/swappiness y se puede modificar en tiempo de ejecución o de forma permanente. Un valor alto provoca que el contenido se traslade antes a la partición de swap, mientras que un valor bajo lo mantiene más tiempo en la RAM. El objetivo es lograr un buen equilibrio entre el uso de la RAM, la caché de páginas y un comportamiento controlado de la partición de swap. Tengo muy presente que la RAM es mucho más rápida que cualquier SSD, por lo que prefiero Memoria de trabajo claro, antes del swap.
Por qué la «swappiness» es importante en los servidores de alojamiento
En los servidores web y de aplicaciones, la configuración de Intercambio sobre el tiempo de respuesta y el rendimiento. Un intercambio agresivo genera una carga adicional de E/S y ralentiza las consultas, sobre todo en cargas de trabajo con un uso intensivo de bases de datos. Por el contrario, unos valores demasiado bajos conllevan el riesgo de que se produzcan posteriormente eventos OOM, que interrumpen los procesos de forma brusca. Por eso, además de la RAM y el espacio de intercambio, evalúo también los picos de carga típicos, las cachés y los patrones de consultas. Quien reduce las latencias evita los tirones y mantiene las transacciones de forma notable líquido.
Recomendaciones según la carga de trabajo
Rara vez hay un único valor que se adapte a todos los escenarios, por lo que empiezo con rangos probados en la práctica y luego los ajusto en función de los datos de medición. Las bases de datos se benefician de ajustes muy bajos, mientras que los servidores web puros suelen soportar valores algo más altos. Los sistemas de prueba o de desarrollo pueden funcionar más cerca de los valores estándar, ya que la comodidad juega un papel más importante. Utilizo el siguiente esquema como punto de partida pragmático para Alojamiento-Cargas de trabajo. A continuación, superviso la E/S, el uso del espacio de intercambio y los tiempos de respuesta, y realizo los ajustes necesarios según sea preciso.
| Carga de trabajo | Nivel de swappiness recomendado | Objetivo |
|---|---|---|
| Bases de datos (MySQL, PostgreSQL) | 0–10 | Mantener el búfer en la RAM y reducir al mínimo las latencias |
| En tiempo real/baja latencia | 0–10 | Evitar picos de E/S mediante el swap |
| Servidor web con cachés | 10-20 (en algunos casos, 10-30) | Almacenar en el disco las páginas inactivas y mantener las solicitudes activas en la RAM |
| Desarrollo/Pruebas | 30-60 | Comodidad y estabilidad por encima de la latencia |
Comprobar el valor actual
Antes de modificar los valores, leo el estado y lo documento. Línea de base. Para ello utilizo «cat /proc/sys/vm/swappiness» o «sysctl vm.swappiness»; ambas opciones me dan un valor como 60. Al mismo tiempo, compruebo el uso de la RAM y del espacio de intercambio con «free -h». Con swapon –show puedo ver el tamaño, la prioridad y el soporte de los dispositivos de swap activos. Estos datos iniciales me ayudan a evaluar los efectos más adelante asignar para poder hacerlo.
Probar temporalmente en lugar de cambiar directamente
Primero voy a probar Swappiness a modo de prueba, para ver las reacciones en condiciones reales Carga . El comando «sysctl vm.swappiness=10» surte efecto de inmediato, pero solo dura hasta el reinicio. Durante las pruebas, observo «top» o «htop», compruebo «vmstat» e «iostat» y mido los tiempos de respuesta de los servicios. Si la tasa de intercambio se reduce y las latencias se mantienen estables, sigo avanzando en pasos razonables. Solo cuando las métricas sean convincentes, anoto el valor permanente fijo.
Configurar de forma permanente
Si el valor de prueba es correcto, lo añado a una configuración de sysctl y vuelvo a cargar los ajustes. En /etc/sysctl.conf añado la línea vm.swappiness=10 y la activo con sysctl -p. Para mayor claridad, prefiero crear un archivo propio en /etc/sysctl.d/, por ejemplo, 99-swappiness.conf, y cargarlo con sysctl –system. Esto facilita el control de versiones y su integración en procesos de automatización. En este artículo se ofrece una descripción detallada de los parámetros relacionados: ajuste de sysctl, que me ayuda a organizar los cambios y Claridad trae.
Tamaño del archivo de intercambio, estructura de la memoria y soportes de datos
La «swappiness» nunca actúa de forma aislada, por eso evalúo el tamaño y la ubicación del Intercambiar Siempre hay que tenerlo en cuenta. Un espacio de intercambio insuficiente se llena rápidamente, mientras que uno sobredimensionado alarga las fases de E/S en situaciones de carga. En SSD o NVMe, el espacio de intercambio es más rápido que en HDD, pero la RAM sigue estando varios órdenes de magnitud por delante. Disponer de varios dispositivos de intercambio con prioridades ayuda a utilizar primero el medio más rápido. Quien quiera profundizar en las ventajas y desventajas, encontrará en esta descripción general sobre Memoria virtual en el alojamiento web reflexiones útiles para la Práctica.
Flujo de trabajo en la consulta: paso a paso
Empezaré por hacer un análisis de la situación actual: anotaré el valor actual de Swappiness, el uso de la RAM y del espacio de intercambio, así como la CPU y las E/S, y lo guardaré como Referencia Guardar. A continuación, clasifico la carga de trabajo: principalmente bases de datos, web con caché, funcionamiento mixto o en contenedores. Después, defino un objetivo: para bases de datos, de 0 a 10; para la web, normalmente de 10 a 20; para cargas mixtas, voy probando con cautela. Establezco el valor de forma temporal, observo varias fases de carga y comparo las métricas. Si el resultado coincide repetidamente, fijo el valor, documento el cambio y lo compruebo tras actualizaciones del kernel, del hardware o Publique-Cambiar de nuevo.
Casos de uso específicos: contenedores, máquinas virtuales y la nube
En contenedores y máquinas virtuales, evalúo el valor de «swappiness» tanto a nivel de host como de máquina invitada. juntos . Las plataformas de orquestación como Kubernetes suelen beneficiarse de ajustes muy bajos en los nodos de trabajo para mantener bajas las latencias de los pods. En las máquinas virtuales, configuro internamente los valores adecuados, pero me aseguro de que el hipervisor no actúe en sentido contrario. En configuraciones de nube elástica, los valores conservadores ayudan a suavizar los picos hasta que la escalabilidad surta efecto. Evito que un único contenedor, debido a un comportamiento intensivo de intercambio, afecte a todo el Plataforma frena.
Supervisión y resolución de problemas
Las señales de alerta típicas de un valor de «swappiness» inadecuado las detecto en una elevada carga de E/S a pesar de que aún queda RAM libre, en tiempos de respuesta irregulares y en consultas a la base de datos lentas. Compruebo estos patrones con vmstat, iostat, sar y las métricas de mi pila de observabilidad. Si el sistema muestra un uso elevado del swap a pesar de disponer de RAM libre, suelo reducir el valor de swappiness. Si observo registros de OOM o interrupciones cuando la RAM es escasa, aumento moderadamente el valor de swappiness o ajusto la configuración del swap. La siguiente tabla clasifica los síntomas de una probable Causa y marca una primera dirección.
| Síntoma | Causa probable | Siguiente paso |
|---|---|---|
| Alto volumen de E/S con RAM libre | El nivel de swappiness es demasiado alto | Reducir el valor, medir el impacto |
| Eventos OOM bajo carga | El valor de «Swappiness» es demasiado bajo o hay muy poco espacio de intercambio | Aumentar el valor, comprobar el tamaño del swap |
| Consultas lentas a pesar de la reserva de CPU | Se ha desactivado el búfer de la base de datos | Valor entre 0 y 10, analizar el búfer de la base de datos |
| Picos de carga sin cuellos de botella en la CPU | Picos de E/S provocados por el intercambio de memoria | Reducir el «swappiness», comprobar los aciertos de caché |
Comprender las métricas de grano fino
Para evaluar objetivamente el «swappiness», analizo más a fondo los contadores del núcleo. En /proc/vmstat, pswpin y pswpout indican el número de páginas leídas y desalojadas, respectivamente. pgscan_kswapd_* y pgsteal_* muestran la agresividad con la que trabaja el recuperador. Si se acumulan los pgmajfault (fallos de página graves), esto indica recargas con gran carga de E/S. Consulto estos valores repetidamente o mediante sar -B y sar -W para ver las tasas, no solo instantáneas. Con vmstat 1 detecto si/so (swap in/out) y puedo asignar los picos a eventos reales. Además, /proc/pressure/memory ofrece una estimación de hasta qué punto las tareas se ven afectadas por la presión de memoria bloque (PSI). Si estos valores aumentan ligeramente o por completo, tengo un indicio claro de que el reclaim es demasiado agresivo o de que el nivel de swappiness no es el adecuado.
Swappiness 0 frente a 1: qué hace realmente el núcleo
A menudo se da por sentado que Swappiness=0 desactiva por completo el swap. Eso no es del todo cierto. El valor 0 indica al núcleo que evite el swap en la medida de lo posible y que solo lo utilice en caso de verdadera falta de memoria. En la práctica, un valor de entre 1 y 10 basta para lograr un comportamiento muy conservador, mientras que el valor 0 puede provocar, en algunas versiones, fases de recuperación tardías pero intensas. Para servicios en los que la latencia es crítica, suelo establecer un valor de entre 1 y 5 y observo si pswpout/pswpin se mantienen prácticamente en cero. Si con el valor 0 se producen eventos OOM durante picos de actividad, lo aumento ligeramente para que el núcleo alivie la presión antes y de forma suave, en lugar de hacerlo de forma brusca. irrumpir.
Cómo sacar el máximo partido a Zswap y ZRAM
Además del swap clásico en disco, utilizo Zswap o ZRAM, dependiendo del perfil. Zswap comprime las páginas paginadas y las mantiene inicialmente en la RAM, antes de que se transfieran al disco cuando sea necesario. Esto reduce las operaciones de E/S y suaviza las latencias, pero consume recursos de la CPU. En servidores con una gran reserva de CPU, esto supone una más rentable Compromiso. ZRAM proporciona memoria de intercambio comprimida directamente en la RAM, lo cual es ideal para cargas con picos de actividad o máquinas virtuales muy pequeñas, en las que prefiero utilizar RAM comprimida en lugar de E/S lenta. Importante: elijo conscientemente uno de los conceptos y establezco las prioridades de tal forma que se atienda primero la ruta más rápida. La «swappiness» sigue siendo una herramienta de control: incluso con Zswap/ZRAM, quiero evitar oleadas de recuperación innecesarias.
Caché de página, vfs_cache_pressure y aciertos en la caché
Swappiness interactúa con la caché de páginas, que almacena archivos e inodos en la RAM. Con vm.vfs_cache_pressure controlo la agresividad con la que el núcleo vacía estas cachés frente a páginas anónimas. Unos valores demasiado altos hacen que las cachés de metadatos desaparezcan demasiado rápido, lo que ralentiza los servidores web. Normalmente empiezo con un valor de entre 50 y 100, mido las tasas de aciertos de la caché y observo cómo se comportan las latencias en los recursos estáticos y las respuestas de la API. El objetivo es mantener en la RAM los contenidos más utilizados, sin que las páginas que se consultan con poca frecuencia saturen la memoria. Si la tasa de aciertos sigue siendo buena y la E/S baja, significa que el equilibrio es adecuado; de lo contrario, ajusto la swappiness y el vfs_cache_pressure en el Tándem.
Evitar el «dirty-writeback» y los picos de E/S
Las rutas de escritura influyen en las latencias tanto como el swap. Con vm.dirty_background_ratio/bytes y vm.dirty_ratio/bytes determino cuánta caché «sucia» se acumula antes de que el núcleo la escriba. Prefiero utilizar *_bytes en lugar de porcentajes para establecer límites máximos definidos, especialmente en configuraciones con mucha RAM, en las que los porcentajes pueden generar enormes oleadas de reescritura. Objetivo: una escritura continua y planificable, en lugar de picos esporádicos que, junto con el swap, generan bloqueos de E/S. Compruebo iostat y las colas de reescritura, y mantengo los valores de tal forma que los SSD/NVMe estén constantemente ocupados, pero no atropellar convertirse.
NUMA, «Zone Reclaim» y hosts de gran tamaño
En los sistemas con NUMA, la localidad de la memoria es importante. Si vm.zone_reclaim_mode está activado, el núcleo puede recuperar memoria de forma más agresiva en el nodo NUMA local, lo que provoca picos de recuperación no deseados. Para muchas cargas de trabajo de alojamiento, desactivo la recuperación de zonas y dejo que el programador se encargue de la ubicación, con el fin de lograr un comportamiento más estable. Además, compruebo las páginas enormes transparentes (THP): Las bases de datos suelen responder mejor con THP=never o madvise, ya que la desfragmentación no planificada y las asignaciones de THP pueden provocar picos de latencia. El «swappiness» puede ser perfecto, pero si las políticas de THP o NUMA interfieren, los Tartamudeo.
Aspectos avanzados de los contenedores y los cgroups
Con Cgroups v2 dispongo de otros controles además de la swappiness del host: «memory.high» provoca una recuperación suave, «memory.max» establece límites máximos estrictos y «memory.swap.max» limita el uso del swap por carga de trabajo. De este modo, evito que determinados contenedores ralenticen el host mediante el swap. En el nodo, establezco valores bajos de swappiness y otorgo prioridad a las cargas de trabajo críticas mediante memory.low, para que sus conjuntos activos permanezcan más tiempo en la RAM. En Kubernetes, presto atención a cómo gestiona el nodo el intercambio y pruebo los cambios primero en grupos que no son de producción. Lo importante es la visión global: los parámetros del host, los límites de Cgroup y el orquestador deben estar en consonancia; de lo contrario, la presión solo se traslada de un nivel a otro. otros.
Implementación, automatización y recaída
Aplico los cambios en Swappiness, al igual que cualquier optimización del rendimiento, de forma controlada: primero en un pequeño grupo de nodos prácticamente idénticos (Canary) y, a continuación, de forma gradual a un conjunto más amplio. Systemd-sysctl o la gestión de configuraciones incorporan los valores de forma reproducible. Documento los valores iniciales y finales, las fechas y horas, los hosts implicados y Métricas. Para el caso de que se produzca una recaída, planifico de antemano el cambio inverso (por ejemplo, sysctl vm.swappiness=60) y guardo los archivos sysctl anteriores. Durante las ventanas de mantenimiento, mido deliberadamente escenarios típicos de carga para no confundir los cambios con las fluctuaciones horarias o de tráfico. Solo así las decisiones siguen siendo sólidas y consensuadas en el equipo. comprensible.
Malentendidos frecuentes y antipatrones
- „Swappiness=0 desactiva el swap“: No, el núcleo sigue utilizando el espacio de intercambio, aunque de forma muy moderada.
- „Cuanto más swap, más seguro es“: Un uso excesivo del swap prolonga las fases de presión y enmascara los cuellos de botella de la RAM, en lugar de resolverlos.
- „Con NVMe, el intercambio de datos no importa“: NVMe es rápido, pero varios órdenes de magnitud más lento que la RAM. Las latencias siguen siendo perceptibles.
- „Un valor para todos los servidores“: Las cargas de trabajo varían mucho. Sin mediciones, el ajuste queda al azar.
- „Swappiness soluciona cualquier problema de latencia“: A menudo, los problemas se deben a los aciertos de caché, el «writeback», el THP, los planes de consulta o las rutas de red.
Resumen para empezar rápidamente
Normalmente configuro vm.swappiness entre 10 y 20 para los servidores web y entre 0 y 10 para las bases de datos, compruebo el efecto y observo la E/S, las latencias y Intercambiar-Porcentaje. Establezco el valor definitivo mediante sysctl en /etc/sysctl.d/ y mantengo un registro de los cambios. Al mismo tiempo, me aseguro de que la configuración del espacio de intercambio sea adecuada: tamaño adecuado, soporte rápido y prioridades razonables. En cuanto a la presión sobre la memoria, presto atención además a la caché de páginas y a su comportamiento; esta visión general ofrece una buena guía de inicio sobre Eliminación de la caché de página, que me ayuda a analizar las causas y Contexto . Con este procedimiento consigo tiempos de respuesta fiables, evito picos de paginación y aprovecho eficazmente la memoria RAM disponible.
