Problemas de rendimiento con SQL Server 2012 Enterprise Edition con licencia CAL

Se introdujeron numerosos cambios de licencia en SQL Server 2012; el más significativo fue el cambio de licencias basadas en sockets a licencias basadas en núcleos para Enterprise Edition. Uno de los desafíos que enfrentó Microsoft con este cambio fue proporcionar una ruta de migración para los clientes que anteriormente usaban licencias basadas en Server+CAL para Enterprise Edition antes de SQL Server 2012. Los clientes con Software Assurance pueden actualizar a SQL Server 2012 Enterprise Edition y seguir usando Server Licencia +CAL (también conocida como "excedencia") pero con una limitación a 20 procesadores lógicos, como se documenta en la Guía de licencias de SQL Server 2012. Esta licencia también se extiende a máquinas virtuales con un límite de 4 máquinas virtuales cubiertas por la licencia Enterprise Server+CAL, pero aún con la misma limitación de 20 procesadores lógicos como se documenta en la Guía de licencias de virtualización de SQL Server 2012.

Mucha gente ha sido sorprendida por la limitación de 20 procesadores lógicos, a pesar de que está documentado en las guías de licencia.

Se realiza una entrada en el archivo ERRORLOG cuando se inicia la instancia, especificando la cantidad de procesadores lógicos y que se aplica la limitación de 20 procesadores:

Con la configuración predeterminada que SQL Server aplica bajo la limitación de 20 procesadores lógicos usando Server+CAL, los primeros 20 programadores son VISIBLES EN LÍNEA y los programadores restantes son VISIBLES SIN CONEXIÓN. Como resultado, pueden ocurrir problemas de rendimiento para la instancia, debido a los desequilibrios del programador del nodo NUMA. Para demostrar esto, creé una VM en nuestro servidor de prueba Dell R720 que tiene dos zócalos y procesadores Intel Xeon E5-2670 instalados, cada uno con 8 núcleos e Hyperthreading habilitado, lo que brinda un total de 32 procesadores lógicos disponibles en Windows Server 2012 Datacenter Edition. La máquina virtual se configuró para tener 32 CPU virtuales con 16 procesadores virtuales asignados en dos nodos vNUMA.

Figura 1:configuración de vNUMA

En SQL Server bajo el modelo de licencia Enterprise Server+CAL, esto da como resultado una configuración del programador similar a la siguiente:

SELECT 
  parent_node_id,
  [status], 
  scheduler_id, 
  [cpu_id], 
  is_idle, 
  current_tasks_count, 
  runnable_tasks_count, 
  active_workers_count, 
  load_factor
FROM sys.dm_os_schedulers;

Figura 2:asignación del programador en Enterprise Server+CAL

Como puede ver, la instancia utiliza los 16 procesadores lógicos del primer nodo NUMA y solo cuatro de los procesadores lógicos del segundo nodo NUMA. Esto da como resultado un desequilibrio significativo de programadores entre los dos nodos NUMA que puede generar problemas de rendimiento significativos bajo carga. Para demostrar esto, activé 300 conexiones que ejecutaban la carga de trabajo de AdventureWorks Books Online en la instancia y luego capturé la información del programador para los programadores VISIBLE ONLINE en la instancia mediante la siguiente consulta:

SELECT 
  parent_node_id,
  scheduler_id, 
  [cpu_id], 
  is_idle, 
  current_tasks_count, 
  runnable_tasks_count, 
  active_workers_count, 
  load_factor
FROM sys.dm_os_schedulers
WHERE [status] = N'VISIBLE ONLINE';

Un resultado de ejemplo de esta consulta bajo carga se muestra en la Figura 3 a continuación.

Figura 3:Programadores bajo carga con Enterprise Server+CAL

También puede ver este síntoma visualmente en herramientas de monitoreo como SQL Sentry Performance Advisor:

Figura 4:desequilibrio de NUMA como se muestra en SQL Sentry Performance Advisor

Esta información muestra un desequilibrio significativo y, como resultado, el rendimiento se verá afectado. Esto es claramente evidente en los recuentos de tareas ejecutables para los cuatro programadores en el segundo nodo NUMA, que son de tres a cuatro veces más grandes que los de los programadores en el primer nodo NUMA. Entonces, ¿cuál es exactamente el problema y por qué ocurre esto?

A primera vista, podría pensar que se trata de un error en SQL Server, pero no lo es. Esto es algo que ocurre por diseño, aunque dudo que se esperara este escenario cuando se implementó originalmente la limitación de 20 procesadores lógicos. En los sistemas basados ​​en NUMA, las nuevas conexiones se asignan a los nodos NUMA de forma rotativa y, luego, dentro del nodo NUMA, la conexión se asigna a un programador en función de la carga. Si cambiamos la forma en que vemos estos datos y agregamos los datos en función de parent_node_id, veremos que las tareas se equilibran en los nodos NUMA. Para hacer esto, usaremos la siguiente consulta, cuyo resultado se muestra en la Figura 5.

SELECT 
  parent_node_id, 
  SUM(current_tasks_count) AS current_tasks_count, 
  SUM(runnable_tasks_count) AS runnable_tasks_count, 
  SUM(active_workers_count) AS active_workers_count, 
  AVG(load_factor) AS avg_load_factor
FROM sys.dm_os_schedulers
WHERE [status] = N'VISIBLE ONLINE'
GROUP BY parent_node_id;

Figura 5:Equilibrio rotativo de nodos NUMA

Este comportamiento está documentado en Books Online for SQL Server (http://msdn.microsoft.com/en-us/library/ms180954(v=sql.105).aspx). Sabiendo lo que sé sobre SQLOS, SQL Server y hardware, esto tiene sentido. Antes de la limitación de 20 procesadores lógicos en SQL Server 2012 Enterprise Edition con licencia Server+CAL, era raro que SQL Server tuviera un desequilibrio en el programador entre los nodos NUMA en un servidor de producción. Uno de los problemas en este caso específico es la forma en que se pasó el NUMA virtual a la máquina virtual. Realizar exactamente la misma instalación en el hardware físico permite que todos los programadores sean VISIBLES EN LÍNEA ya que los procesadores lógicos adicionales presentados por los hiperprocesos se distinguen por SQL y son gratuitos.

En otras palabras, el límite de 20 procesadores lógicos en realidad da como resultado 40 programadores EN LÍNEA si (a) no es una máquina virtual, (b) los procesadores son Intel y (c) el hiperprocesamiento está habilitado.

SELECT 
  parent_node_id,
  [status], 
  scheduler_id, 
  [cpu_id], 
  is_idle, 
  current_tasks_count, 
  runnable_tasks_count, 
  active_workers_count, 
  load_factor
FROM sys.dm_os_schedulers
WHERE [status] = N'VISIBLE ONLINE';

ALTER SERVER CONFIGURATION
SET PROCESS AFFINITY CPU = 0 TO 9, 16 TO 25;