Fusión de páginas iguales del núcleo (KSM): KSM para un mejor rendimiento de la virtualización

Virtualización KSM Reduce las necesidades físicas de RAM, ya que el núcleo de Linux agrupa las páginas de memoria idénticas entre máquinas virtuales y las comparte de forma eficiente mediante «copy-on-write». De este modo, aumento la densidad de máquinas virtuales, mitigo los cuellos de botella de RAM y mantengo la Actuación en equilibrio.

Puntos centrales

Las siguientes ideas clave me ayudan a comprender rápidamente el KSM y a utilizarlo de forma específica:

• Desduplicación La eliminación de páginas de memoria idénticas reduce considerablemente el consumo de RAM.
• Copy-on-Write mantiene las páginas legibles conjuntamente y solo las separa cuando se producen cambios.
• Ajuste fino Los parámetros ksmd equilibran la carga de la CPU y el ahorro.
• Ubicación NUMA Evita latencias innecesarias en los hosts con varios zócalos.
• Seguridad requiere un uso compartido selectivo en entornos multitenant.

¿Qué es el KSM? Conceptos básicos y procedimiento

Con Fusión de páginas iguales del núcleo El hilo del núcleo ksmd busca periódicamente páginas privadas anónimas marcadas como „mergeable“ y agrupa los contenidos que coinciden bit a bit. Esto me beneficia, ya que a menudo muchas máquinas virtuales mantienen en memoria bibliotecas, códigos de programa o componentes del sistema operativo idénticos. KSM marca las páginas agrupadas como Copia en escritura, lo que hace que todos los usuarios lean la misma página física hasta que uno de ellos escribe en ella. Solo cuando se produce un acceso de escritura, el núcleo crea una página propia para ese proceso, mientras que la original sigue compartiéndose. Importante: KSM no deduplica las páginas del sistema de archivos ni las de la caché de páginas, y debo liberar memoria explícitamente para la fusión.

Uso en entornos de virtualización

En hosts con muchas máquinas virtuales similares, se pone de manifiesto KSM el mayor efecto, ya que las páginas redundantes aparecen con frecuencia. En configuraciones KVM y en la nube, la fusión reduce considerablemente la carga efectiva de RAM por máquina invitada y, por lo tanto, aumenta la densidad de máquinas virtuales por servidor. Los testimonios prácticos indican que, con una configuración adecuada, se pueden alcanzar hasta 300 % más de sistemas invitados sin que se aprecie una merma notable en el tiempo de respuesta. Si combino KSM con Exceso de memoria, consigo que los servidores funcionen a pleno rendimiento y aprovecho mejor la memoria RAM disponible. Al compartir páginas idénticas, reduzco el riesgo de picos de swap y consigo un funcionamiento fluido Curva de rendimiento a través de numerosas instancias.

Configuración en Linux y KVM

Activo KSM a través de CONFIG_KSM en el núcleo y controlo el comportamiento mediante Sysfs en /sys/kernel/mm/ksm/. Allí inicio el escaneo (run), configuro la intensidad (pages_to_scan, sleep_millisecs) y observo las páginas liberadas (pages_sharing). En distribuciones empresariales utilizo servicios como ksm y ksmtuned, que ajustan automáticamente la intensidad al alza o a la baja en función de los umbrales de RAM libre. Para un control más detallado, marco áreas de memoria como fusionables de forma específica mediante madvise(MADV_MERGEABLE) o prctl(PR_SET_MEMORY_MERGE). En entornos dinámicos, me gusta combinar KSM con Globo de memoriapara optimizar la Asignación de RAM y mantenerla, además, flexible.

Rendimiento y puesta a punto: el equilibrio adecuado

Obtengo mejores resultados sobre todo en aquellos casos en los que la RAM es el verdadero cuello de botella y los núcleos de la CPU quedarían sin utilizar; en esos casos, se nota KSM el rendimiento general, ya que ejecuto más máquinas virtuales en paralelo. Sin embargo, el hilo de ksmd consume tiempo de CPU, por lo que unos parámetros de escaneo demasiado agresivos pueden reducir las ventajas. Empiezo de forma conservadora, mido los valores de pages_sharing y pages_scanned, y observo las latencias bajo carga antes de aumentar la velocidad de análisis. Si hay suficiente RAM libre, mantengo ksmd menos activo y no lo acelero hasta que empiezan a escasear los hosts. De este modo, mantengo un buen equilibrio entre Aumento de la capacidad de almacenamiento y la sobrecarga de la CPU.

La seguridad y el aislamiento desde un punto de vista objetivo

Dado que varios huéspedes comparten una misma habitación, tengo en cuenta los posibles Canales laterales, que podrían obtener información a partir de los tiempos de respuesta o los patrones de acceso. En entornos multitenant sensibles, desactivo de forma selectiva el uso compartido de páginas para determinadas instancias u hosts. Por el contrario, para cargas de trabajo menos delicadas con muchos invitados similares, KSM es un método fiable para reducir costes y aumentar la densidad. Documento la decisión por clúster y mantengo una lista de excepciones para máquinas virtuales especialmente críticas. De este modo, garantizo Transparencia y reduzco los puntos vulnerables sin sacrificar la ganancia en eficiencia.

NUMA, páginas gigantes e interacción

En los sistemas NUMA, presto atención a Almacén y, a ser posible, hago que KSM se fusione solo dentro de un nodo, para que los accesos no se realicen a través de rutas lentas. Esto reduce las latencias y mantiene alto el ancho de banda por socket. En combinación con las «Huge Pages», reduzco las faltas de acierto en la TLB, pero debo tener en cuenta que las páginas grandes alteran las probabilidades de que el contenido coincida bit a bit. Algunas cargas de trabajo se benefician más de las «Huge Pages», otras más de la deduplicación; lo valido mediante pruebas de rendimiento. El objetivo sigue siendo maximizar el acceso local y memoria remota que hay que evitar.

Comprender el seguimiento y los indicadores clave

Evalúo el efecto de KSM basándome en unos pocos contadores, pero muy reveladores: pages_sharing, pages_shared, pages_scanned, pages_unshared y full_scans. Si pages_sharing aumenta de forma estable y la carga de la CPU se mantiene moderada, mi configuración va por el buen camino. Si los valores se mantienen estables, compruebo si los invitados marcan la memoria como «mergeable». Además, observo el «Host-Swap», las latencias de las máquinas virtuales y la «IO-Wait» para detectar a tiempo cualquier efecto secundario. Los paneles de control con series temporales me muestran las tendencias, de modo que puedo Ajustes tomo decisiones basadas en datos.

Ejemplos prácticos y potencial de ahorro

En clústeres de prueba con docenas de máquinas virtuales Linux similares, pude comprobar, gracias a KSM En algunos casos, se lograron ahorros de RAM de dos dígitos en puntos porcentuales y, por lo tanto, una densidad notablemente mayor. Las cargas de trabajo de Java con muchas clases y bibliotecas idénticas proporcionaron mejoras especialmente consistentes. Cuanto más homogéneas son las instancias, más se reduce la huella de memoria; las pilas heterogéneas ofrecen resultados menores, pero aún así útiles. En combinación con un overcommit bien configurado, mantengo bajos los costes por instancia y ejecuto más servicios en el mismo hardware. De este modo se crea una clara Impacto económico con una calidad previsible.

KSM frente a alternativas: diferencias y interrelación

Apuesto por un Cartera Técnicas de memoria complementarias que funcionan de forma diferente según el objetivo. KSM elimina la redundancia en el contenido de la RAM, mientras que el «ballooning» recupera memoria de forma dinámica para los invitados y las «Huge Pages» mejoran la eficiencia de la CPU. Ninguna técnica sustituye a la otra; yo las combino de forma específica según el perfil de la carga de trabajo y el objetivo de densidad. Para los principiantes, la siguiente visión general les ayudará a tomar una decisión más rápidamente. Como siguiente paso, merece la pena echar un vistazo a KVM y Xen en comparación, para determinar la Elección de la plataforma clasificarlo adecuadamente.

Tecnología	Tarea	Ventaja	Desventaja	Adecuado para
KSM	Deduplicación de páginas de RAM idénticas	Alta Ahorro de RAM en máquinas virtuales similares	Carga adicional de la CPU debida a los análisis	Muchos invitados similares, hosts KVM
Globo de memoria	Recuperación dinámica de un almacén de gas	Mejor Utilización con cargas de trabajo variables	Se necesita un conductor de globos por invitado	Perfiles de ocupación mixtos
Páginas enormes	Páginas de mayor tamaño para reducir las faltas de acierto en la TLB	Más alto Eficiencia de la CPU en aplicaciones que consumen mucha memoria	Menor probabilidad de deduplicación	Bases de datos, JVM, motores en memoria
Fijación NUMA	Asignación de máquinas virtuales a nodos de almacenamiento locales	constante Latencia y ancho de banda	Menor flexibilidad en la programación	Servidores con varios sockets, cargas de trabajo en las que la latencia es un factor crítico

Activación práctica y guías de actuación para el anfitrión

A nivel de host, lo enfoco de forma pragmática: ejecuto ksm/ksmtuned y establezco unos valores básicos que han dado buenos resultados en la práctica. Ejemplo:

# Activar servicios (depende de la distribución)
systemctl enable --now ksm ksmtuned

# Ajuste manual (surte efecto inmediatamente, hasta el reinicio)
echo 1 > /sys/kernel/mm/ksm/run
echo 1000 > /sys/kernel/mm/ksm/pages_to_scan
echo 50 > /sys/kernel/mm/ksm/sleep_millisecs

En libvirt, controlo el uso compartido por cada máquina virtual. Por defecto, QEMU marca la memoria RAM del invitado como «mergeable». Para máquinas virtuales especialmente sensibles, desactivo explícitamente el uso compartido:

Así es como mantengo una línea clara: activación generalizada en hosts con cargas de trabajo homogéneas y exclusiones selectivas para los casos excepcionales.

Ajuste preciso de los parámetros KSM en detalle

• ejecutar: 0 = desactivado, 1 = activado, 2 = desactivado y desvincular las páginas ya fusionadas. Yo utilizo el „2“ solo para pruebas específicas o cuando quiero revertir de forma segura el uso compartido antes de las ventanas de mantenimiento.
• páginas_que_hay_que_escanear: Número de páginas que se comprueban por ciclo. Los valores más altos aceleran la búsqueda de páginas idénticas, pero aumentan la carga de la CPU.
• sleep_millisecs: Pausa entre ciclos. Las pausas más largas reducen la sobrecarga, pero tardan más en alcanzar el nivel de ahorro máximo.
• merge_across_nodes: En los hosts NUMA, lo configuro en 0 para que el merging solo se realice dentro de un nodo NUMA. Esto mantiene la localidad.
• use_zero_pages: Si esta opción está activada, los procesos comparten las páginas cero de forma eficiente con la página cero del núcleo. Esto proporciona un ahorro „seguro“ sin los costes asociados al COW.

Con ksmtuned realizo un ajuste dinámico basado en umbrales de RAM. En cuanto la memoria libre empieza a escasear, ksmtuned aumenta la velocidad de escaneo (Npagen-Boost); cuando la presión disminuye, vuelve a reducirla. El resultado es una configuración adaptativa y „flexible“ que no requiere intervenciones manuales.

Interacción con THP, Huge Pages y el «ballooning» (en profundidad)

Páginas transparentes enormes (THP) y Páginas enormes optimizan la eficiencia de la CPU, mientras que KSM reduce la redundancia en la RAM. Para ello, tengo en cuenta lo siguiente:

• KSM trabaja con páginas normales de 4 KB. Las páginas THP (normalmente de 2 MB) no se pueden deduplicar. Cuanto más interviene THP, menos «alimento» tiene KSM.
• Para cargas de trabajo en las que la latencia es crítica o que dependen de la CPU, utilizo principalmente THP/Huge Pages. Para hosts con poca memoria RAM y máquinas virtuales homogéneas, doy prioridad a KSM.
• Ballooning complementa a KSM: el controlador Balloon devuelve la memoria libre a la máquina host. KSM reduce al mismo tiempo la demanda al consolidar páginas idénticas. Juntos, suavizamos los picos de carga y evitamos el intercambio prematuro de memoria.

Tomo la decisión basándome en datos empíricos: las pruebas de rendimiento con y sin THP/Huge Pages, así como con KSM activado, me indican qué combinación ofrece la mejor relación coste-rendimiento global.

Modelos de seguridad y funciones modernas de la CPU

En entornos con separación estricta de clientes Desactivo sistemáticamente el uso compartido por máquina virtual/host. Esto minimiza los canales de información laterales derivados de las páginas compartidas y simplifica las auditorías de cumplimiento normativo. Las modernas Cifrado de almacenamiento A nivel de host/invitado (por ejemplo, clave por máquina virtual), esto impide en la práctica que KSM pueda fusionar contenidos de forma eficaz entre invitados, ya que los contenidos idénticos ya no se encuentran bit a bit en la memoria RAM física. En este tipo de clústeres, evito realizar escaneos agresivos y mantengo ksmd en un modo más bien pasivo, para no desperdiciar recursos de la CPU.

Para entornos menos sensibles, pero homogéneos, mantengo KSM como configuración predeterminada. Documento la política para cada clúster: „Predeterminado: activado, excepciones mediante nosharepages“ o „Predeterminado: desactivado, acceso compartido solo para grupos definidos“; ambas opciones son válidas, siempre y cuando se apliquen de forma transparente y reproducible.

Idoneidad para la carga de trabajo y antipatrones

KSM destaca en cargas de trabajo homogéneas y con gran cantidad de bibliotecas (por ejemplo, muchos servidores de aplicaciones idénticos, servicios basados en JVM, agentes). Se benefician menos:

• Asignaciones muy variables y de corta duración (por ejemplo, muchos búferes pequeños que cambian rápidamente), ya que la probabilidad de COW es alta.
• Datos comprimidos, cifrados o pseudoaleatorios – Apenas aparecen páginas idénticas.
• Grandes bases de datos en memoria con un reciclaje agresivo de páginas, cuando los datos cambian rápidamente. En estos casos, suelen prevalecer las ventajas de las Huge Pages/THP.

En las granjas de contenedores, KSM también puede funcionar, siempre que los procesos marquen las memorias como «mergeable». Sin embargo, en la práctica, centro KSM principalmente en las máquinas virtuales, ya que allí QEMU ya establece los indicadores madvise necesarios.

Solución de problemas y tropiezos típicos

• El intercambio de páginas se ha estancado: Compruebo si QEMU/las máquinas virtuales realmente crean memoria fusionable (sin la directiva «nosharepages» en el XML de libvirt) y si ksmd está en ejecución. Si los resultados siguen siendo planos, es probable que la carga de trabajo sea demasiado heterogénea.
• Carga de la CPU demasiado alta: Aumento el valor de `sleep_millisecs` y/o reduzco el de `pages_to_scan`. Además, puedo desactivar la fusión entre NUMA para reducir el espacio de búsqueda.
• Picos de latencia inesperados: Compruebo si los eventos COW se correlacionan con picos de carga. En tales casos, reduzco la frecuencia de escaneo o excluyo temporalmente las máquinas virtuales afectadas del uso compartido.
• El overcommit se agrava en el swap: KSM no sustituye a la planificación de la capacidad. Siempre mantengo una reserva de RAM libre y solo ajusto ksmd como medida de seguridad, no como solución de emergencia.

Planificación, dimensionamiento y automatización

Para obtener resultados predecibles, defino unos valores objetivo para cada host:

• Espacio libre: Un porcentaje fijo de RAM libre que, si no se alcanza, hace que ksmtuned actúe de forma más agresiva. Así consigo que la deduplicación se realice solo cuando realmente es necesario.
• Equidad: Cuando las cargas de trabajo son desiguales, separo los grupos (por ejemplo, por proyecto o entorno), para que las máquinas virtuales homogéneas se beneficien juntas y las heterogéneas no „diluyan“ el rendimiento.
• Valores límite: Establezco límites para las velocidades máximas de escaneo y compruebo periódicamente si el ahorro justifica el uso de la CPU.

En el ámbito de la automatización, considero que KSM es un manual de procedimientos repetible y versionado (por ejemplo, «drop-ins» de Systemd o fragmentos de código de Cloud-Init). De este modo, me aseguro de que los nuevos hosts entren en funcionamiento con un conjunto de parámetros idéntico y de que las desviaciones se detecten rápidamente.

Resumen para administradores

Utilizo KSM, cuando los hosts alojan muchas máquinas virtuales similares y la RAM es el recurso más escaso. En ese caso, la deduplicación es lo que más ayuda, mientras que yo controlo con precisión el consumo de CPU mediante ksmtuned y los parámetros de sysfs. En configuraciones NUMA, mantengo la fusión a nivel local, combino KSM con ballooning y Huge Pages, y mido el efecto mediante pages_sharing y métricas de latencia. Para los invitados sensibles, desactivo el uso compartido de forma selectiva y documento las excepciones de manera transparente. De este modo, aumento densidad, garantizar tiempos de respuesta y reducir de forma sostenible los costes en euros por instancia.