Arquitectura NUMA en servidores: claves para el rendimiento y la escalabilidad

La arquitectura NUMA en servidores ha revolucionado el acceso a los recursos, pero también puede convertirse en un obstáculo para el rendimiento si no se gestiona adecuadamente. Con el incremento del número de núcleos, la adopción de configuraciones multisocket y la complejidad de la topología de los procesadores, la memoria ha dejado de ser igualmente accesible para todos los hilos de ejecución. NUMA (Non-Uniform Memory Access) surge como una solución para escalar el rendimiento, aunque en la práctica puede provocar ralentizaciones y una eficiencia menor de la esperada.

¿Qué es la arquitectura NUMA y por qué surgió?

NUMA, o Acceso No Uniforme a la Memoria, es una arquitectura en la que el tiempo de acceso a la RAM depende de la ubicación física de la memoria respecto al núcleo del procesador. A diferencia del modelo clásico UMA (Uniform Memory Access), donde todos los núcleos acceden a la memoria con una latencia similar, en NUMA la proximidad física marca la diferencia.

En los primeros ordenadores, UMA era suficiente: un controlador de memoria centralizado gestionaba el acceso de todos los núcleos o procesadores. Sin embargo, el aumento de la demanda y el paso a sistemas multisocket hicieron que UMA dejara de escalar de forma eficiente, convirtiéndose el controlador de memoria en un cuello de botella.

Para resolver este problema, NUMA divide el sistema en varios nodos, cada uno con su propio procesador (o grupo de núcleos) y memoria local. El acceso a la memoria local es mucho más rápido que acceder a la memoria de otro nodo, que requiere comunicación entre procesadores.

Este diseño facilita la escalabilidad y reduce la carga sobre los buses compartidos, razón por la cual NUMA se ha convertido en el estándar en servidores modernos, especialmente en configuraciones con múltiples procesadores.

No obstante, a nivel de software, la memoria sigue apareciendo como un espacio de direcciones único. Si un hilo se ejecuta en un nodo pero sus datos están en otro, cada acceso implica una latencia adicional, que puede acumularse y afectar al rendimiento de forma impredecible.

Por tanto, NUMA no es una aceleración por defecto, sino un compromiso: resuelve problemas de escalabilidad a nivel de hardware, pero transfiere complejidad a los sistemas operativos y aplicaciones. Si estos no consideran la topología NUMA, la arquitectura puede ser contraproducente para el rendimiento.

Diferencias clave entre NUMA y UMA en servidores

La diferencia entre UMA y NUMA es fundamental para entender cómo un servidor interactúa con la memoria. En UMA, todos los núcleos acceden a un único pool de memoria con una latencia uniforme, lo que simplifica la programación y la gestión del sistema operativo. Este modelo es ideal para sistemas de un solo socket o con pocos núcleos.

NUMA, en cambio, distribuye la memoria entre nodos. Cada procesador accede más rápido a su memoria local y más lento a la de otros nodos. La diferencia de latencia puede ser significativa, afectando especialmente a aplicaciones sensibles a los tiempos de respuesta, como bases de datos, sistemas de caché o virtualización.

Además, el comportamiento bajo carga difiere: en UMA, el rendimiento se degrada gradualmente con la carga; en NUMA, la degradación puede ser brusca si los hilos y los datos no están correctamente alineados entre nodos.

En configuraciones multisocket, UMA ya no es viable por limitaciones físicas, lo que hace que NUMA sea la única opción escalable, aunque añade complejidad y exige un conocimiento profundo de la arquitectura por parte de administradores y desarrolladores.

Acceso a la memoria en sistemas NUMA

El acceso a la memoria en NUMA deja de ser una operación de coste uniforme. Cada núcleo está vinculado físicamente a un nodo, con un controlador de memoria y una porción de la RAM. El acceso local es rápido y eficiente, pero no siempre está garantizado, ya que la distribución de datos y procesos cambia dinámicamente.

Cuando un núcleo necesita acceder a memoria de otro nodo, depende de buses interprocesador como QPI o UPI, lo que incrementa la latencia y reduce el ancho de banda efectivo. Para el software, este detalle es invisible, pero el impacto en los tiempos de acceso y el rendimiento es real.

Los sistemas operativos intentan minimizar este problema ubicando la memoria cerca del hilo que la solicita, pero migraciones de hilos, cambios de carga o nuevos procesos pueden romper esta correspondencia.

Además, las líneas de caché pueden migrar entre núcleos y nodos, enmascarando temporalmente la problemática. Sin embargo, bajo cargas intensas, el sistema recurre frecuentemente a la memoria remota, elevando las latencias.

En resumen, el acceso a memoria en NUMA es probabilístico: el mismo código puede ejecutarse rápido o lento según la asignación en ese momento, lo que dificulta la estabilidad del rendimiento en servidores exigentes.

Topología del procesador y arquitectura NUMA

NUMA está intrínsecamente ligada a la topología del procesador. En servidores modernos, los CPUs son sistemas complejos con núcleos, controladores de memoria y conexiones interprocesador. Cada socket suele formar un nodo NUMA, y dentro de un mismo socket pueden existir varios dominios NUMA debido a diseños basados en chiplets.

El sistema operativo describe esta estructura como una topología NUMA: identifica qué núcleos y memorias pertenecen a cada nodo y cuáles son vecinos. Sin embargo, esta información no siempre se utiliza de forma óptima en la práctica.

La dinámica del sistema, con migraciones de hilos y cambios de carga, puede romper la correspondencia entre cálculos y datos, agravando los problemas de latencia y reduciendo la escalabilidad efectiva, incluso cuando el hardware es más potente.

¿Por qué NUMA afecta negativamente al rendimiento?

NUMA puede perjudicar el rendimiento porque rompe la localización de datos esperada por la mayoría de aplicaciones. Cuando los hilos y los datos residen en nodos distintos, las latencias de acceso se disparan, afectando especialmente a cargas intensivas en memoria.

Otra causa es la competencia por los buses interprocesador: varios hilos accediendo a memoria remota saturan el canal, lo que incrementa exponencialmente las latencias y puede colapsar el sistema antes de llegar al límite de CPU o RAM.

El planificador del sistema operativo, que busca balancear la carga entre núcleos, a menudo no respeta la localización NUMA, moviendo hilos sin trasladar los datos asociados. Esto degrada el rendimiento aunque la utilización del procesador parezca equilibrada.

El efecto es más severo en aplicaciones multihilo con estructuras de datos compartidas, donde el acceso frecuente a memoria remota es inevitable. Además, la degradación puede parecer aleatoria, dificultando el diagnóstico.

NUMA en sistemas multiprocesador: el inicio de los problemas

En servidores multiprocesador, los efectos de NUMA se amplifican. Cada socket adicional aporta más núcleos y memoria, pero también más caminos posibles de acceso, haciendo que la gestión de recursos sea más compleja y sensible a errores.

Las conexiones interprocesador se convierten en el cuello de botella crítico, ya que todas las operaciones de sincronización y acceso remoto deben pasar por ellas. El aumento de sockets no siempre se traduce en mayor rendimiento si las aplicaciones no están optimizadas para NUMA.

En entornos con cargas compartidas (varios servicios o máquinas virtuales), los datos y procesos pueden mezclarse entre nodos, provocando retrasos difíciles de monitorizar y diagnosticar.

Además, la sincronización en aplicaciones multihilo puede provocar un efecto "ping-pong", con datos moviéndose constantemente entre sockets, lo que incrementa aún más las latencias y limita la escalabilidad.

Latencia en NUMA: el enemigo de la escalabilidad

La latencia en el acceso a memoria es el factor determinante del rendimiento en NUMA. Aunque el ancho de banda total sea alto, el incremento de la latencia al acceder a memoria remota puede anular cualquier ganancia por aumentar núcleos o RAM.

Bajo cargas reales, con miles de hilos accediendo simultáneamente a la memoria, incluso pequeñas penalizaciones en latencia se acumulan, elevando los tiempos de respuesta y degradando el rendimiento general.

Los sistemas altamente sincronizados sufren especialmente, ya que cualquier operación que requiera datos remotos puede bloquear varios hilos y aumentar los tiempos de espera. Además, las métricas tradicionales rara vez muestran el origen de estos retrasos, complicando la detección del problema.

Errores comunes de sistemas operativos y software con NUMA

• Migración agresiva de hilos: El planificador mueve hilos entre núcleos para balancear la carga, sin considerar la localización de los datos, lo que incrementa los accesos remotos.
• Inicialización incorrecta de la memoria: Muchos servicios asignan la mayoría de la memoria al arrancar, antes de distribuir los hilos, concentrando los datos en un solo nodo.
• Código multihilo sin consciencia NUMA: Estructuras de datos y pools de hilos compartidos provocan competencia inter-nodo y latencias elevadas.
• Problemas en virtualización y contenedores: Las máquinas virtuales o contenedores pueden desconocer la topología NUMA y distribuir recursos de forma ineficiente.
• Monitoreo insuficiente: Muchas herramientas no muestran accesos remotos a memoria, dando la falsa impresión de que el sistema funciona correctamente.

Todos estos errores tienen en común la falta de control explícito sobre la localización de hilos y datos, lo que puede costar gran parte de la capacidad real del servidor bajo cargas intensas.

¿Cuándo es útil NUMA y cuándo es perjudicial?

NUMA no debe verse solo como un problema. Es indispensable para escalar servidores más allá de un socket, pero su eficacia depende del tipo de carga y de la arquitectura del software.

NUMA es muy eficiente en tareas donde cálculos y datos pueden localizarse estrictamente, como en computación de alto rendimiento, análisis científico, renderizado o bases de datos bien particionadas. En estos casos, el acceso local a la memoria compensa la complejidad añadida.

Sin embargo, en escenarios generales de servidores -web, microservicios, sistemas con mucha sincronización-, donde la carga es difícil de localizar, NUMA puede introducir una inestabilidad significativa en el rendimiento.

La virtualización y los contenedores añaden otro nivel de complejidad, pues las máquinas virtuales pueden perder la localización de los datos, provocando latencias impredecibles y un rendimiento inferior al de servidores más simples.

NUMA resulta especialmente problemática donde la latencia mínima y la estabilidad son críticas. Aunque el rendimiento promedio parezca aceptable, los picos de latencia pueden hacer que el sistema no sea apto para servicios críticos.

Conclusión

La arquitectura NUMA es una etapa inevitable en la evolución de los servidores modernos, permitiendo escalar el número de núcleos y la capacidad de memoria. Sin embargo, trae consigo una nueva clase de problemas relacionados con la latencia y la imprevisibilidad del rendimiento.

El principal desafío de NUMA es que rompe la percepción de la memoria como un recurso uniforme. El tiempo de acceso pasa a depender de la topología del procesador, la ubicación de los datos y el comportamiento del planificador. Para aplicaciones y sistemas que ignoran esta realidad, NUMA se convierte en una fuente de latencia y pérdida de eficiencia.

En escenarios de virtualización, microservicios y sincronización intensiva, el aumento de recursos hardware no garantiza una mejora del rendimiento; puede, de hecho, empeorar la situación. Por otro lado, en aplicaciones con buena localización de datos y procesos, NUMA permite aprovechar al máximo los sistemas multisocket.

En última instancia, NUMA transfiere parte de la responsabilidad del rendimiento al nivel del software. Ignorar su existencia ya no es una opción: cuanto más potente el servidor, mayor es el coste del error. Comprender NUMA es esencial para garantizar la estabilidad y previsibilidad en los sistemas actuales.