Por qué una VM mayor que un socket de CPU suele ser más lenta

Cuando una máquina virtual va lenta, el reflejo es darle más núcleos. En un servidor moderno de dos sockets hay un punto en el que ese reflejo se vuelve en su contra, y la VM más grande corre más despacio que la más pequeña a la que sustituyó. Ese punto es el tamaño de un socket de CPU, y la razón se llama NUMA.

Qué es NUMA, en un párrafo

Un servidor con dos procesadores es en realidad dos ordenadores que comparten un puente. Cada socket tiene sus propios controladores de memoria y su propio banco de memoria conectado directamente a él. Un núcleo que lee memoria conectada a su propio socket la obtiene a velocidad local. Un núcleo que lee memoria conectada al otro socket tiene que cruzar la interconexión entre los sockets, y ese acceso es más lento. Esta disposición es el acceso no uniforme a memoria: cada núcleo puede alcanzar toda la memoria, pero no al mismo coste. Cada socket con su memoria es un nodo NUMA.

Por qué cruzar la frontera cuesta más de lo que parece

Un acceso a memoria remota tarda aproximadamente 1,7 veces más que uno local. Eso por sí solo es una penalización grande para cualquier cosa que toque memoria a menudo, que es casi todo. Y no es toda la factura:

• Coherencia de caché. Los dos sockets deben mantener sus cachés consistentes. Cuando hilos de ambos lados trabajan sobre los mismos datos, las líneas de caché rebotan a través de la interconexión, y cada rebote es una parada.
• Saturación de la interconexión. El enlace entre los sockets tiene un ancho de banda finito. Una VM ocupada repartida entre ambos sockets compite por él con todo lo demás que hay en el host.
• Planificación. Una VM cuyas vCPU no pueden ejecutarse todas a la vez en un socket espera a que el hipervisor encuentre sitio en los dos, y sus hilos aterrizan donde haya espacio, a menudo lejos de sus datos.

Estos efectos se multiplican en lugar de sumarse. Una carga de trabajo que escalaría bien dentro de un socket puede perder una parte importante de su rendimiento en cuanto se reparte entre dos, y los núcleos extra que añadió están pagando por el privilegio.

Lea la topología de su host

Antes de dimensionar nada, mire lo que el host tiene de verdad:

lscpu | grep -E 'Socket|Core|Thread|NUMA'
numactl --hardware

Salida típica en un host de dos sockets:

Thread(s) per core:  2
Core(s) per socket:  18
Socket(s):           2
NUMA node(s):        2
NUMA node0 CPU(s):   0-17,36-53
NUMA node1 CPU(s):   18-35,54-71

Los números que importan son los núcleos por socket y la memoria por nodo, que numactl --hardware imprime junto con una tabla de distancias. Las distancias muestran cuánto más cuesta un acceso remoto que uno local en esta máquina exacta.

Dimensione contra núcleos físicos, no contra hyper-threads.

Las dos reglas de dimensionado

De la topología salen dos reglas fáciles de enunciar y que merece la pena no romper nunca:

• Una VM nunca recibe más vCPU que núcleos físicos tiene un socket. Deje margen para el propio hipervisor, así que en un socket de dieciocho núcleos un techo razonable está un par de núcleos por debajo.
• Una VM nunca recibe más memoria que la que sirve un nodo NUMA. De lo contrario parte de su memoria es remota por construcción, haga lo que haga el planificador.

Una VM que cumple las dos reglas puede vivir entera dentro de un nodo, y un buen hipervisor la mantendrá ahí.

Compruebe dónde vive de verdad una VM en ejecución

En un host KVM puede ver cómo se reparte la memoria de un guest entre los nodos:

numastat -c qemu-kvm
virsh vcpuinfo <vm-name>
virsh numatune <vm-name>

Si numastat muestra una VM grande con una cantidad sustancial de memoria en ambos nodos, está pagando la penalización de acceso remoto en una parte de su trabajo. Dentro de un guest Linux, lscpu y numactl --hardware muestran la topología que el hipervisor le presenta.

Cuando un socket de verdad no basta

Algunas cargas de trabajo necesitan genuinamente más de lo que un socket puede dar. Hay respuestas mejores que una VM gigante:

• Escale horizontalmente. Dos VM que caben cada una en un nodo, detrás de un balanceador de carga o como miembros de un clúster, suelen ganar a una VM que abarca ambos.
• Arregle primero el cuello de botella. Una VM que parece necesitar más núcleos a menudo está esperando al storage, a locks o a un único hilo ocupado. Añadir núcleos a una carga de trabajo que no puede usarlos no cambia nada salvo la penalización NUMA.
• Si tiene que ser grande, hágala consciente de NUMA. Presente al guest una topología virtual que refleje la del host, dos nodos virtuales que coincidan con los dos físicos, y fije cada nodo virtual a su nodo físico. Un sistema operativo y una aplicación que conocen NUMA pueden entonces mantener los hilos cerca de sus datos. Los gestores KVM enterprise, OLVM entre ellos, exponen el pinning NUMA para esto.

Más grande no es linealmente más rápido de todos modos

Incluso dentro de un socket, doblar las vCPU rara vez dobla el rendimiento. Partes de toda carga de trabajo son seriales, los locks se saturan a medida que se multiplican los hilos, las cachés se comparten y el hipervisor necesita más esfuerzo para planificar una VM ancha. Doblar vale normalmente una fracción del doble, y pasada la frontera del socket puede volverse negativo. La forma honesta de dimensionar es ejecutar la carga de trabajo real en dos tamaños y medir. La VM más pequeña gana más veces de lo que la gente espera.

Cómo lo hacemos nosotros

En nuestros private clouds OLVM y en todas las demás plataformas que operamos, las dos reglas se aplican a cada VM: nunca más vCPU que núcleos tiene un socket físico, nunca más memoria que la que sirve un nodo NUMA, dimensionadas a partir de la topología real del host. Ajustamos el tamaño a lo que la carga de trabajo necesita en lugar de redondear hacia arriba.

Si sus VM se dimensionaron a ojo, o simplemente crecieron una petición cada vez, con gusto miramos la topología y los números con usted.

Hable con un ingeniero

Related (rows[1])

Relacionado: Private cloud sobre KVM con OLVM · Ingeniería de rendimiento y capacidad · Cloud dedicado en Apache CloudStack, a su medida