Arquitectura NUMA: por qué desempeña un papel importante en los servidores modernos

El Arquitectura NUMA determina la velocidad a la que los servidores modernos suministran memoria a los subprocesos y la capacidad de escalado de las cargas de trabajo con cargas elevadas. Muestro por qué los accesos a la memoria local dominan la latencia y el ancho de banda, cómo los hipervisores utilizan NUMA y qué ajustes en las máquinas virtuales liberan ganancias directas de rendimiento.

Puntos centrales

Resumo brevemente las conclusiones más importantes y destaco los factores que tienen mayor repercusión en los centros de datos.

• Memoria local Minimiza la latencia y aumenta el rendimiento.
• Nodo NUMA Estructuran las CPU y la RAM de manera eficiente.
• Tamaño de la vCPU Ajustar por VM al tamaño del nodo
• NUMA virtual Pasar al sistema operativo invitado
• Reglas de tensión para grandes necesidades de RAM

Me centro sistemáticamente en Latencia y proximidad de datos, porque es ahí donde se decide el rendimiento del servidor. Los sockets grandes, los núcleos múltiples y la gran cantidad de RAM sirven de poco si los subprocesos esperan constantemente a áreas de memoria remotas. Dimensiono las máquinas virtuales de modo que quepan en un nodo NUMA y la asignación de memoria permanezca local. Apoyo las funciones del hipervisor de forma selectiva, en lugar de activarlas todas de forma global. De este modo, me aseguro de que Escala sin sorpresas en los picos de carga.

Lo que realmente caracteriza a NUMA

Pienso en Nodo: Cada nodo NUMA combina núcleos de CPU y un área de RAM local con rutas de acceso muy cortas. Si un subproceso encuentra los datos en la caché L1, L2 o L3, todo funciona con extrema rapidez; si el conjunto de datos se encuentra en la RAM local, la latencia sigue siendo baja. Sin embargo, si el subproceso accede a otro nodo, el tiempo de espera aumenta y el rendimiento disminuye. Son precisamente estas diferencias las que hacen que No uniforme Acceso a la memoria. Por lo tanto, organizo las cargas de trabajo de manera que la mayor parte del acceso se mantenga a nivel local.

Por qué UMA llega a sus límites

UMA asigna a todos los procesadores un ruta de almacenamiento lo que genera congestión a medida que aumenta el número de núcleos. Cada núcleo adicional se suma a las mismas colas y compite por el ancho de banda. En muchas configuraciones antiguas, esto provocaba una acumulación de latencia hasta que, aunque la utilización de la CPU era alta, la aplicación respondía con lentitud. Da la sensación de que la CPU está al límite, aunque en realidad el cuello de botella se encuentra en el acceso a la memoria. NUMA resuelve precisamente este problema. Atascos mediante rutas locales y topología de nodos.

NUMA frente a UMA: resumen de las diferencias

Me gusta resumir las diferencias más importantes en un formato compacto. Cuadro firme, para que las decisiones se tomen más rápidamente. Este resumen muestra lo que es importante en cuanto a arquitectura, latencia y escalabilidad. Me ayuda a dimensionar nuevos hosts, así como a depurar errores en entornos productivos. Quien ve claramente la diferencia entre el acceso local y el remoto, toma mejores decisiones a la hora de adaptar las máquinas virtuales y asignar la RAM. Aquí es precisamente donde se decide la Actuación bajo carga.

Criterio	NUMA	UMA	Efecto práctico
acceso a la memoria	Local o remoto	Normalizado	El acceso local es más rápido; el acceso remoto tiene un coste de latencia.
Escala	Muy bueno con nudos	Limitado desde el principio	Más núcleos escalan de forma más fiable con NUMA
Topología	Varios nodos	Pool uniforme	Es necesario realizar una planificación que tenga en cuenta la topología
hipervisor	NUMA virtual disponible	Menos relevante	El sistema operativo invitado puede planificar NUMA-aware.
Ajuste fino	vCPU/RAM por nodo	Ajuste global	Las máquinas virtuales compatibles con nodos proporcionan estabilidad

NUMA en entornos virtuales

Dejo que el hipervisor se encargue de la Topología al sistema operativo invitado para que el programador y la gestión de memoria planifiquen localmente. Virtual NUMA muestra al invitado los límites de sus nodos, lo que permite a las bases de datos, JVM y trabajadores .NET organizar sus montones y subprocesos de forma más económica. De este modo, evito costosos accesos remotos y mantengo estable la latencia. En configuraciones sensibles, lo combino con una estrategia de fijación coherente y una asignación fija de RAM. Para tiempos de respuesta extremadamente cortos, también utilizo Alojamiento con microlatencia para reducir aún más la fluctuación.

Prácticas recomendadas para tamaños de máquinas virtuales y asignación de CPU

Dimensiono vCPU de modo que una máquina virtual quepa en un nodo NUMA o solo lo roce ligeramente. Ejemplo: si un host tiene dos nodos de 20 núcleos cada uno, planifico máquinas virtuales con entre 4 y 16 vCPU preferiblemente dentro de un nodo. Si se supera este límite, se corre el riesgo de accesos remotos y tiempos de espera innecesarios. Distribuyo la RAM de la forma más estática posible para que el sistema operativo invitado mantenga sus páginas localmente. Para cargas de trabajo con una fuerte proporción de un solo subproceso, incluyo la estrategia de núcleo adecuada y utilizo análisis como Un hilo frente a varios núcleos.

Ventajas concretas para el hardware de alojamiento

Con una planificación NUMA limpia, aumento la densidad por host, sin sacrificar los tiempos de respuesta. En muchos centros de datos, esto permite operar un número notablemente mayor de máquinas virtuales por zócalo, mientras que las aplicaciones responden de forma fiable. La menor latencia repercute directamente en la experiencia del usuario y en el rendimiento por lotes. Los costes por carga de trabajo se reducen, ya que el tiempo de CPU y la RAM se utilizan de forma más eficiente. Quienes eligen el hardware de forma fundamentada se benefician además de la moderna Hardware de alojamiento web de alto rendimiento con gran capacidad de almacenamiento.

Ajuste de la carga de trabajo: bases de datos, cachés, contenedores

Me aseguro de que Bases de datos mantienen sus montones localmente y calculan los subprocesos de trabajo en „su“ nodo. Para los motores SQL, las cachés en memoria y las JVM, vale la pena asignar CPU y reservar memoria de forma fija. La orquestación de contenedores se beneficia de las afinidades de los nodos, de modo que los pods utilicen las rutas de almacenamiento más cortas. En caso de E/S intensiva, apuesto por asignaciones NVMe cercanas a NUMA para mantener los datos cerca de los nodos. De este modo, las rutas de acceso permanecen cortas y las Tiempo de respuesta amable.

Supervisión y resolución de problemas en NUMA

Mido Latencia y el acceso remoto de forma específica, en lugar de limitarme a mirar los porcentajes de CPU. Las herramientas me muestran, por cada nodo, cuántas páginas se encuentran en remoto y qué subprocesos generan presión en la memoria. Si aumentan los fallos remotos, ajusto el tamaño de la vCPU, las afinidades o la asignación de RAM. Si el rendimiento sigue siendo bajo a pesar de las elevadas reservas de CPU, a menudo se debe a las rutas de memoria. Para mí, la visibilidad desde la perspectiva de los nodos es la forma más rápida de Causas, no solo a los síntomas.

NUMA-Spanning: uso correcto

Activo Tensión Específicamente para máquinas virtuales con grandes necesidades de RAM o un ancho de banda excepcional. La máquina virtual puede entonces obtener memoria a través de varios nodos, lo que permite en primer lugar las instancias individuales con una huella masiva. El precio es el acceso remoto ocasional, que mitigo con afinidades de CPU y una mayor proporción de localidad de página. En el caso de cargas mixtas, prefiero elegir varias máquinas virtuales de tamaño medio en lugar de una instancia muy grande. De este modo, se mantiene Planificabilidad en la vida cotidiana.

Licencias, densidad y costes reales

Tasa I Costos no a nivel de host, sino por carga de trabajo y mes en euros. Cuando NUMA aumenta la densidad de las máquinas virtuales, los costes fijos por instancia disminuyen y las reservas de rendimiento aumentan. Esto afecta tanto a las licencias por núcleo como a los costes de asistencia técnica y energía. Quien reduce el acceso remoto, acorta el tiempo de cálculo y ahorra energía realizando la misma tarea. Al final, lo que cuenta es el Balance general por resultado, no solo por servidor.

Interpretación correcta de la topología del hardware y las interconexiones

Me refiero a la física. Topología activamente en mi planificación. Los servidores modernos utilizan diseños de CPU de varios componentes y conectan chiplets o matrices a través de interconexiones. Esto significa que no todos los núcleos tienen el mismo camino hacia cada módulo RAM, e incluso dentro de un zócalo hay rutas preferentes. Cuanto más tráfico pasa por los enlaces entre zócalos, más aumenta Latencia y la sobrecarga de coherencia. Por lo tanto, compruebo cuántos canales de memoria están activos por nodo, si todas las ranuras DIMM están equipadas simétricamente y cómo están conectados los nodos en la placa base. Las características Sub-NUMA, que dividen los nodos en dominios más pequeños, pueden equilibrar los puntos críticos cuando las cargas de trabajo están claramente segmentadas. También observo la Topología L3: Si los subprocesos y sus datos se encuentran en diferentes dominios de caché, la transferencia de caché por sí sola consume una cantidad notable de rendimiento. Una simple prueba de ancho de banda y una visión general de la topología muestran rápidamente si la plataforma ofrece la localidad esperada o si las interconexiones se convierten en un cuello de botella.

Opciones de firmware y BIOS con efecto

En la BIOS, me aseguro de que Intercalación de nodos está desactivado para que la estructura NUMA siga siendo visible. Utilizo el clúster Sub-NUMA o modos similares de forma específica cuando las cargas de trabajo tienen muchas cantidades de trabajo medianas y claramente separadas. Para obtener latencias consistentes, selecciono perfiles de energía orientados al rendimiento y reduzco los más profundos. Estados C y evita el estacionamiento agresivo del núcleo. Optimizo la asignación de memoria para aprovechar al máximo Ancho de banda del canal de memoria; Las configuraciones DIMM asimétricas afectan directamente al rendimiento y al tiempo de espera. También compruebo las opciones de prefetcher y RAS: algunos mecanismos de protección aumentan la latencia sin servir a la carga de trabajo. Importante: pruebo cada ajuste de la BIOS con carga real, ya que los microefectos causados por las cachés y las interconexiones a menudo solo se manifiestan bajo presión.

Sistema operativo invitado y ajuste del tiempo de ejecución: desde el primer contacto hasta las páginas enormes

En Gast utilizo Primer toque-Asignación a mi favor: los subprocesos inicializan „su“ memoria para que las páginas se creen localmente. En Linux, activo o desactivo el equilibrio NUMA automático en función de la carga de trabajo; los sistemas relacionados con bases de datos suelen beneficiarse de una conexión estable, mientras que los trabajadores web distribuidos soportan migraciones reducidas. Con numactl o task pinning, conecto servicios a nodos y defino membind-Directrices. Páginas enormes Reduzco la presión TLB; en bases de datos con latencia crítica, prefiero páginas enormes estáticas y memoria caliente (pre-touch) para evitar picos de fallos de página. Dependiendo del motor, utilizo páginas enormes transparentes en „madvise“ o las desactivo si generan latencias de desfragmentación. Controlo Afinidades IRQ y distribuyo las interrupciones de red y NVMe a los nodos adecuados; RPS/XPS y las colas múltiples ayudan a mantener la coherencia de las rutas de datos. En Windows, utilizo grupos de procesadores y Soft-NUMA en la pila, me aseguro de que se bloqueen las páginas en la memoria para los servicios que consumen mucha memoria y activo el GC del servidor en .NET. Para las JVM, utilizo heurísticas conscientes de NUMA, pre-touche Heaps y controlo la afinidad de los subprocesos para que GC y Worker utilicen los mismos nodos.

Alinear correctamente los ajustes específicos del hipervisor

Me paso a la Topología vNUMA a la estructura física. Selecciono los parámetros „Sockets“, „Cores per Socket“ y „Threads per Core“ de tal manera que el hipervisor no divida la máquina virtual en nodos. Para las instancias sensibles a la latencia, reservo RAM para evitar el ballooning y el swapping, y aseguro los recursos pCPU mediante afinidad u opciones de programador adecuadas. Precaución con la adición en caliente de CPU o memoria: muchas plataformas desactivan vNUMA en el invitado, lo que da lugar a accesos remotos ocultos. Planifico la migración en vivo de manera que los hosts de destino tengan una topología NUMA compatible y, tras la migración, doy tiempo a las máquinas virtuales para que Localidad de la página Reconstruir (pre-touch, calentamiento). En entornos KVM, utilizo las opciones de ajuste NUMA y cpuset-Cgroups; en otros hipervisores, las herramientas exstop/similares ayudan a ver la distribución de vCPU y los nodos activos en tiempo real.

No desperdicie la localidad PCIe y E/S

Organizo NVMe-Unidades, HBA y NIC al nodo en el que se ejecutan los subprocesos de cálculo. Vinculo las colas SR-IOV o vNIC a los núcleos del mismo nodo y controlo las interrupciones en consecuencia. Para altas tasas de paquetes, escalo las colas de recepción/transmisión y las distribuyo de manera consistente entre los núcleos locales. En el caso de las pilas de almacenamiento, me aseguro de que los subprocesos de trabajo para envíos y finalizaciones de E/S funcionen en el mismo nodo, de modo que la ruta de datos no atraviese la interconexión. También planifico las rutas múltiples y el RAID de software específicos para cada nodo; una ruta „más corta“ casi siempre supera a la ruta „más amplia“ con accesos externos. De este modo, reduzco la fluctuación y, bajo la carga de E/S, consigo la tiempo de CPU allí donde tiene efecto.

Planificación de capacidad, sobrecompromiso y funciones de memoria

Prefiero ejecutar cargas de trabajo orientadas a la latencia sin Overcommit en la RAM y moderadamente en la vCPU. El ballooning, la compresión y el intercambio de hipervisores generan accesos externos o picos de fallos de página, que es precisamente lo que quiero evitar. El intercambio transparente de páginas es ineficaz en muchas configuraciones y puede ocultar la visibilidad de la localidad real. Calibro la combinación de máquinas virtuales para que no colisionen varias instancias que consumen mucho ancho de banda de memoria en el mismo nodo. Para los motores en memoria, planifico generosamente Reservas y, cuando sea conveniente, páginas enormes en el invitado que el hipervisor pueda pasar. De este modo, la tasa de aciertos TLB y los tiempos de acceso siguen siendo predecibles.

Migración en vivo y alta disponibilidad

Tengo en cuenta que una Migración destruyo temporalmente la localización lateral de una máquina virtual. Tras el traslado, caliento los montones críticos y dejo que los trabajos en segundo plano reconstruyan los hotsets. Planifico los hosts de destino con una topología NUMA similar para que no sea necesario volver a cortar vNUMA. Para casos de alta disponibilidad con hardware heterogéneo, establezco políticas: o bien acepto una latencia más alta durante un breve periodo de tiempo, o bien doy prioridad a los hosts con un tamaño de nodo compatible. Es importante la observación tras la migración: si aumentan las proporciones de páginas remotas, ajusto las afinidades o activo el prefalling hasta que la Localidad vuelve a encajar.

Modelos prácticos de diagnóstico

Reconozco los problemas típicos de NUMA por unos pocos patrones: la CPU se „calienta“, pero la Instrucciones por ciclo siguen siendo bajos; la latencia salta en oleadas; algunos subprocesos se bloquean en los accesos a la memoria, aunque los núcleos estén libres. En estos casos, compruebo los accesos remotos, la utilización de la interconexión, los fallos de TLB y la distribución de los subprocesos activos por nodo. Correlaciono la carga de interrupciones con los núcleos que soportan la aplicación y compruebo si las cachés entre nodos se invalidan constantemente. Una simple prueba de verificación consiste en reducir la máquina virtual a un nodo: si las latencias caen inmediatamente, la causa era el spanning o la programación. Del mismo modo, las pruebas específicas revelan el ancho de banda de la RAM por nodo y muestran si el equipamiento DIMM o las opciones del BIOS están ralentizando el sistema.

Lista de comprobación práctica

• Comprender la topología: nodos, canales de memoria, asignación PCIe, dominios de caché
• Comprobar BIOS: Node Interleaving desactivado, perfil energético Rendimiento, estados C planos.
• Recortar máquinas virtuales: vCPU por máquina virtual ≤ tamaño del nodo, vNUMA correcto, tener en cuenta la adición en caliente.
• Asegurar la RAM: reservas para cargas de trabajo de latencia, páginas enormes cuando sea conveniente.
• Establecer afinidad: vincular subprocesos, IRQ e colas de E/S al mismo nodo
• Contenedores/pods: utilizar la afinidad de nodos, el gestor de CPU y la conciencia topológica
• Aplicar solo de forma selectiva: acompañar las grandes instancias con políticas y supervisión
• Planificar la migración: topología de destino adecuada, heaps pre-touch, observar la localidad
• Mejorar la supervisión: accesos remotos, ancho de banda por nodo, utilización de la interconexión.
• Realizar pruebas periódicas: comprobaciones de ancho de banda/latencia tras cambios de firmware o de host.