¿Las páginas enormes ofrecen a las máquinas virtuales de un laboratorio doméstico una mejora de rendimiento medible?

Las páginas enormes pueden ofrecer una ventaja medible para algunas máquinas virtuales de laboratorios domésticos, pero no son un interruptor universal para acelerar la virtualización. Los candidatos más adecuados son las cargas de trabajo con mucha memoria y sensibles a la TLB, como bases de datos, servicios en memoria, dispositivos virtuales de procesamiento de paquetes y máquinas virtuales que permanecen ocupadas el tiempo suficiente para que la sobrecarga de las tablas de páginas sea relevante. En una máquina virtual de Home Assistant con poca carga, una pequeña máquina virtual Linux de utilidad o una máquina de pruebas ocasional, la diferencia puede ser demasiado pequeña para justificar la reserva de RAM.

La regla práctica es comparar el rendimiento de la misma máquina virtual con memoria normal y con páginas enormes antes de hacerlas permanentes. Linux ya dispone de Páginas Enormes Transparentes (THP), mientras que KVM/libvirt también puede respaldar un sistema invitado con páginas HugeTLB explícitas. Las páginas enormes estáticas intercambian flexibilidad del host por un respaldo con páginas grandes más predecible, por lo que un servidor doméstico con poca RAM o una sobreasignación agresiva puede perder más de lo que gana.

Las páginas enormes reducen el trabajo de traducción de direcciones, no todos los cuellos de botella de las máquinas virtuales

La mayoría de los sistemas Linux x86 utilizan páginas base de 4 KiB, mientras que tamaños de página mayores, como 2 MiB y 1 GiB, pueden mapear mucha más memoria con una sola traducción. La documentación de Páginas Enormes Transparentes del kernel de Linux explica el beneficio central: una asignación más grande puede reducir los fallos de la TLB, y estos también pueden resultar menos costosos en entornos virtualizados con tablas de páginas anidadas.

El kernel también documenta las reservas explícitas de HugeTLB en su guía de páginas HugeTLB, que describe el mecanismo de páginas grandes reservadas que se utiliza cuando se quieren tamaños de página predecibles en lugar de depender únicamente de la promoción transparente.

Esto solo importa cuando la traducción de direcciones representa una parte significativa de la carga de trabajo. Las páginas enormes no hacen que un disco lento sea más rápido, aumentan el ancho de banda de la red, solucionan la contención de CPU ni compensan una cantidad insuficiente de RAM para el sistema invitado. Si una máquina virtual pasa la mayor parte del tiempo esperando al almacenamiento, a API remotas o a una aplicación de un solo subproceso, cambiar el tamaño de página del host puede modificar muy poco el resultado.

¿Qué máquinas virtuales de un laboratorio doméstico tienen más probabilidades de beneficiarse?

Una máquina virtual se convierte en una mejor candidata para Huge Pages a medida que aumenta su conjunto de memoria activa y permanece en uso frecuente. Las bases de datos con grandes grupos de búferes, las cachés en memoria, los motores de análisis, los enrutadores virtuales de alto rendimiento y algunas cargas de trabajo de juegos o compilación pueden acceder repetidamente a suficiente memoria como para que resulte útil tener menos entradas de traducción. La guía de KVM de Red Hat también describe Huge Pages como especialmente relevantes para cargas de trabajo virtualizadas con mucha memoria y uso intensivo de memoria en su documentación sobre el ajuste de la virtualización.

Las máquinas virtuales de infraestructura pequeña son diferentes. Un resolvedor DNS, un proxy inverso ligero, un nodo pequeño de monitorización o un servidor de automatización pueden utilizar activamente solo una fracción de la memoria asignada. En esa situación, es más probable que los factores de rendimiento dominantes sean el comportamiento de la aplicación, la latencia del almacenamiento, la planificación de la CPU, las rutas de red o las dependencias externas.

Si todavía estás decidiendo cuánta capacidad de virtualización debería tener el propio host, el ejemplo de configuración de ZimaCube y Proxmox de ZimaSpace ofrece un contexto útil: el ajuste de la memoria debería hacerse después de que el host tenga suficiente RAM, almacenamiento y capacidad de E/S para las máquinas virtuales que realmente planeas ejecutar.

Las Transparent Huge Pages deberían formar parte de la línea base

Un error común de evaluación comparativa es comparar Huge Pages estáticas con un sistema que ya se beneficiaba de THP sin darse cuenta. Linux moderno puede compactar de forma transparente la memoria adecuada en asignaciones más grandes. La documentación del kernel señala que THP mantiene disponibles más funciones de gestión de memoria que una reserva fija de HugeTLB y puede utilizar la memoria libre de forma más flexible.

Eso significa que la comparación real a menudo no es «páginas de 4 KiB frente a páginas de 2 MiB». Es «el comportamiento normal de THP del host frente a páginas HugeTLB reservadas explícitamente para esta máquina virtual». Si THP ya está capturando gran parte de la región de memoria grande aprovechable, la ganancia adicional de las páginas enormes estáticas puede ser modesta.

Comprueba el host antes de realizar las pruebas:

cat /sys/kernel/mm/transparent_hugepage/enabled
grep -E 'AnonHugePages|HugePages|Hugepagesize' /proc/meminfo

El kernel de Linux también expone contadores de THP en /proc/vmstat, lo que ayuda a confirmar si el host realmente está asignando y compactando páginas enormes, en lugar de asumir que la función está activa.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Las páginas enormes estáticas sacrifican elasticidad por previsibilidad

Libvirt puede solicitar explícitamente páginas enormes mediante la configuración <memoryBacking>. Su documentación actual sobre XML de dominio permite elegir tamaños de página y asignarlos a los nodos NUMA del invitado.

Proxmox expone la misma idea subyacente mediante su configuración de QEMU. El esquema de qemu-server actual documenta opciones de páginas enormes de 2 MiB y 1 GiB, además de un modo de selección automática. Esto resulta útil porque facilita habilitar la función, pero no debe confundirse la facilidad de configuración con una mejora de velocidad garantizada.

El coste es la memoria reservada. Las páginas HugeTLB estáticas son deliberadamente menos flexibles que la memoria paginable ordinaria. Un host con 32 GB de RAM y varias máquinas virtuales con cargas variables puede valorar más la memoria recuperable que una pequeña reducción de la sobrecarga de traducción para un solo invitado. Si el laboratorio doméstico depende de la asignación dinámica de memoria, la sobreasignación o cambios rápidos en la densidad de máquinas virtuales, mide también el coste de oportunidad, además del resultado de la prueba comparativa.

La alineación NUMA importa más a medida que crece el host

En un mini PC con un solo socket, NUMA puede no ser una preocupación práctica. Sin embargo, en una estación de trabajo más grande o en un servidor con dos sockets, las páginas enormes no deben evaluarse de forma independiente de la localidad de la CPU y la memoria. El modelo de respaldo de memoria de Libvirt puede vincular los tamaños de página a los nodos NUMA, y sus controles de ajuste NUMA determinan dónde debe asignarse la memoria del invitado.

Por tanto, un benchmark puede mostrar una mejora aparente de las páginas enormes cuando la mejora real provino de una mejor localidad, o no mostrar ninguna ganancia porque una VM accede repetidamente a memoria NUMA remota. En hosts más grandes, prueba conjuntamente la fijación de CPU, la topología NUMA del invitado y la colocación de la memoria, en lugar de cambiar únicamente el tamaño de página.

Usa una prueba A/B reproducible en lugar de una cifra sintética llamativa

La pregunta correcta no es si las páginas enormes han mejorado alguna vez el rendimiento de KVM. Pueden hacerlo. La pregunta correcta es si mejoran tu VM lo suficiente como para compensar la pérdida de flexibilidad de la memoria.

Usa la misma imagen de VM, cantidad de vCPU, tamaño de RAM, ruta de almacenamiento, modelo de CPU, distribución NUMA y carga de trabajo en ambas ejecuciones. Reinicia el host o la VM entre modos para que el cambio en el respaldo de memoria se aplique realmente. Después, registra tanto el rendimiento a nivel de la aplicación como el comportamiento de la memoria del host.

Por ejemplo, ejecuta una prueba comparativa de base de datos, una carga de compilación o una prueba de procesamiento de paquetes que se parezca al trabajo real de la VM, en lugar de depender únicamente de un microbenchmark de copia de memoria. Repite cada condición varias veces y compara las medianas junto con la latencia de cola. Una mejora sintética del 2 % en la memoria que no cambie la latencia del servicio suele ser una evidencia más débil que una reducción constante del tiempo de CPU o de la latencia de las solicitudes con la carga de trabajo real.

¿Cuándo es suficientemente grande la ventaja para conservarlas?

En un laboratorio doméstico, el umbral debe ser operativo, no ideológico. Mantén las páginas enormes estáticas cuando el resultado sea reproducible, la carga de trabajo sea importante de forma continua y el host tenga suficiente RAM para que reservar las páginas no genere presión en otros recursos.

Las páginas enormes son una optimización posterior a los cuellos de botella principales

No actives las páginas enormes antes de comprobar si la máquina virtual está limitada por la CPU, por la capacidad de memoria, por el almacenamiento o por la red. En un laboratorio doméstico normalmente se obtiene más beneficio al corregir primero los cuellos de botella evidentes: suficiente RAM para evitar el intercambio, almacenamiento rápido para los discos de las máquinas virtuales, dispositivos VirtIO correctamente configurados, un dimensionamiento sensato de las vCPU y passthrough de hardware solo cuando resuelva una carga de trabajo real.

El resumen de ZimaSpace sobre servidores usados, mini PC y hardware NAS para laboratorios domésticos plantea el mismo punto general: el rendimiento de la virtualización empieza por elegir un hardware que se adapte a la carga de trabajo. Ajustar el tamaño de las páginas es una optimización secundaria, después de garantizar que la arquitectura del host sea sólida.

Veredicto final

Las páginas enormes pueden ofrecer una ventaja de rendimiento real, pero son más valiosas para máquinas virtuales grandes, estables y con un uso intensivo de memoria, donde la presión sobre la TLB sea medible. Para los servicios habituales de un laboratorio doméstico pequeño, mantén el comportamiento de memoria predeterminado hasta que una prueba controlada demuestre lo contrario.

Empieza con la configuración THP normal del host, mide una carga de trabajo real y, después, prueba páginas enormes explícitas de 2 MiB. Consérvalas solo si la mejora se mantiene en ejecuciones repetidas y la RAM reservada no reduce la fiabilidad ni la densidad del resto del servidor.

Preguntas frecuentes

¿Las páginas enormes de 1 GiB son siempre más rápidas que las páginas enormes de 2 MiB?

No. Las páginas más grandes cubren más espacio de direcciones por entrada de la TLB, pero las asignaciones de 1 GiB son mucho más gruesas y difíciles de reservar. La carga de trabajo y la distribución de la memoria del host determinan si resultan útiles.

¿Debería usar todas las máquinas virtuales de Proxmox páginas enormes?

No. Las páginas enormes son una opción de ajuste específica para cada carga de trabajo. Las máquinas virtuales pequeñas o con poco uso suelen beneficiarse más de mantener flexible la memoria del host.

¿Las páginas enormes transparentes hacen innecesarias las páginas enormes estáticas?

No siempre. Las THP son un mecanismo automático y flexible, mientras que las páginas HugeTLB estáticas ofrecen un respaldo más explícito y predecible. Compara ambas con la misma carga de trabajo.

¿Qué debería probar primero?

Prueba primero el rendimiento o la latencia de la aplicación y, después, confirma el mecanismo con métricas de memoria del host y de la TLB. Un menor número de fallos de la TLB solo importa si mejora el servicio que te interesa.