Descripción del acceso no uniforme a memoria

Actualizado: 5 de diciembre de 2005

Microsoft SQL Server 2005 está preparado para el acceso no uniforme a memoria (NUMA, Non-Uniform Memory Access) y su rendimiento es bueno en hardware de NUMA sin necesidad de realizar ninguna configuración especial. A medida que aumentan la velocidad del reloj y el número de procesadores, resulta cada vez más difícil reducir la latencia de la memoria necesaria para utilizar esta potencia de procesamiento adicional. Para evitarlo, los proveedores de hardware proporcionan cachés L3 grandes, pero esto es sólo una solución limitada. La arquitectura NUMA proporciona una solución escalable a este problema. SQL Server 2005 se ha diseñado para aprovechar los equipos basados en NUMA sin necesidad de realizar cambios en las aplicaciones.

Conceptos de NUMA

La tendencia en el hardware ha sido tener más de un bus del sistema, y que cada uno de ellos sirva a un pequeño conjunto de procesadores. Cada grupo de procesadores tiene su propia memoria y, posiblemente, sus propios canales de E/S. Sin embargo, cada CPU puede tener acceso a la memoria asociada a otros grupos de forma coherente. Cada grupo se denomina nodo NUMA. El número de CPU dentro de un nodo NUMA depende del proveedor de hardware. Resulta más rápido tener acceso a la memoria local que a la memoria asociada a otros nodos NUMA. Por este motivo se la denomina arquitectura de acceso no uniforme a memoria.

En hardware de NUMA, algunas regiones de la memoria residen en buses físicamente distintos de otras regiones. Puesto que NUMA utiliza memoria local y externa, tardará más tiempo en obtener acceso a algunas regiones de memoria. Los términos memoria local y memoria externa se suelen usar para hacer referencia a un subproceso que se está ejecutando. La memoria local es la que se encuentra en el mismo nodo en que la CPU está ejecutando el subproceso actualmente. Así pues, toda memoria que no pertenezca al nodo en el que se está ejecutando actualmente el subproceso será externa. La memoria externa también se denomina memoria remota. La relación entre lo que cuesta obtener acceso a una memoria externa y a una memoria local se denomina relación NUMA. Si la relación NUMA es 1, se trata de multiproceso simétrico (SMP). Cuanto mayor sea la relación, más costará obtener acceso a la memoria de los demás nodos. A veces, el rendimiento de las aplicaciones de Windows que no están preparadas para NUMA (incluido el Service Pack 3 de SQL Server 2000 y anteriores) es deficiente en hardware de NUMA.

La principal ventaja de NUMA es su escalabilidad. La arquitectura NUMA fue diseñada para traspasar los límites de escalabilidad de la arquitectura SMP. Con SMP, el acceso a la memoria se expone en el mismo bus de memoria compartida. Esto funciona perfectamente en un número relativamente reducido de CPU, pero no cuando existen docenas, incluso cientos, de CPU que compiten para tener acceso al bus de memoria compartida. NUMA alivia estos cuellos de botella limitando el número de CPU en cualquier bus de memoria y conectando los nodos mediante una interconexión de alta velocidad.

NUMA de hardware y NUMA de software

NUMA puede hacer coincidir la memoria con las CPU a través de un hardware especializado (NUMA de hardware) o mediante la configuración de la memoria de SQL Server (NUMA de software). Durante el inicio, SQL Server se configura basándose en el sistema operativo subyacente y en la configuración del hardware o en la configuración NUMA de software. Tanto para NUMA de hardware como de software, cuando SQL Server inicia una configuración NUMA, el registro de SQL Server registra un mensaje de configuración multimodo por cada nodo, junto con la máscara de CPU.

NUMA de hardware

Los equipos con NUMA de hardware disponen de más de un bus del sistema y cada uno de ellos sirve a un pequeño conjunto de procesadores. Cada grupo de procesadores tiene su propia memoria y, posiblemente, sus propios canales de E/S. Sin embargo, cada CPU puede tener acceso a la memoria asociada a otros grupos de forma coherente. Cada grupo se denomina nodo NUMA. El número de CPU dentro de un nodo NUMA depende del proveedor de hardware. El fabricante de hardware le puede indicar si su equipo es compatible con NUMA de hardware.

Si tiene NUMA de hardware, lo puede configurar para que utilice memoria intercalada en vez de NUMA. En ese caso, Windows y, por tanto, SQL Server no lo reconocerán como NUMA. Ejecute la siguiente consulta para conocer el número de nodos de memoria disponibles para SQL Server:

SELECT DISTINCT memory_node_id
FROM sys.dm_os_memory_clerks

Si SQL Server devuelve sólo un único nodo de memoria (nodo 0), significará que no dispone de NUMA de hardware, o que el hardware está configurado como intercalado (no NUMA). Si cree que NUMA de hardware no está correctamente configurado, póngase en contacto con el proveedor de hardware para habilitar NUMA. SQL Server omite la configuración de NUMA si NUMA de hardware tiene cuatro o menos CPU y al menos un nodo tiene únicamente una CPU.

NUMA de software

SQL Server 2005 le permite agrupar las CPU en nodos llamados NUMA de software. Lo más habitual es configurar NUMA de software si se tienen muchas CPU y no se dispone de NUMA de hardware, aunque también puede utilizar NUMA de software para subdividir los nodos NUMA de hardware en grupos más pequeños. Únicamente el programador de SQL Server y la interfaz de red de SQL Server (SNI) están preparados para NUMA de software. Los nodos de memoria se crean en función de NUMA de hardware y, por tanto, no se ven influidos por NUMA de software. Por tanto, si por ejemplo tiene un equipo SMP con ocho CPU y crea cuatro nodos NUMA de software con dos CPU en cada uno, sólo tendrá un nodo de memoria sirviendo a los cuatro nodos NUMA. NUMA de software no proporciona afinidad entre memoria y CPU.

Entre las ventajas de NUMA de software se incluyen la reducción de E/S y los cuellos de botella de escritura diferida en los equipos con muchas CPU y sin NUMA de hardware. Existe un único subproceso de E/S y un único subproceso de escritura diferida para cada nodo NUMA. Dependiendo del uso de la base de datos, estos subprocesos únicos pueden suponer un cuello de botella importante para el rendimiento. La configuración de cuatro nodos NUMA de software proporciona cuatro subprocesos de E/S y cuatro subprocesos de escritura diferida, lo que podría mejorar el rendimiento.

No puede crear un NUMA de software que incluya varias CPU de diferentes nodos NUMA de hardware. Por ejemplo, si su hardware tiene ocho CPU (0...7) y dispone de dos nodos NUMA de hardware (0-3 y 4-7), podrá crear NUMA de software combinando CPU(0,1) y CPU(2,3). No puede crear NUMA de software utilizando CPU (1, 5), pero puede utilizar la afinidad de CPU para establecer afinidad con una instancia de SQL Server para CPU procedentes de diferentes nodos NUMA. Por tanto, en el ejemplo anterior, si SQL Server usa las CPU 0-3, tendrá un subproceso de E/S y un subproceso de escritura diferida. Si en el ejemplo anterior SQL Server utiliza las CPU 1, 2, 5 y 6, tendrá acceso a dos nodos NUMA y tendrá dos subprocesos de E/S y dos subprocesos de escritura diferida.

[!NOTA] Algunas configuraciones de hardware comparten recursos comunes como una caché en L3 o en L4. Los procesadores se pueden agrupar en torno a estos recursos compartidos para crear nodos NUMA de software.

Para obtener más información, vea Cómo configurar SQL Server para que utilice NUMA de software.

Vea también

Tareas

Cómo configurar el motor de la base de datos para escuchar en varios puertos TCP.
Cómo asignar puertos TCP/IP a nodos NUMA
Cómo configurar SQL Server para que utilice NUMA de software

Conceptos

Cómo SQL Server 2005 es compatible con NUMA
Escenarios de NUMA
Asignar subprocesos a una CPU
Usar la opción lightweight pooling
Programar tareas o lotes en SQL Server

Ayuda e información

Obtener ayuda sobre SQL Server 2005

Historial de cambios

Versión	Historial
5 de diciembre de 2005	Contenido modificado: Se reorganizaron todos los temas sobre NUMA para esta versión. Se agregó mucha información nueva.