Problemi di prestazioni con SQL Server 2012 Enterprise Edition con licenza CAL

In SQL Server 2012 sono state introdotte numerose modifiche alle licenze; il più significativo è stato il passaggio dalla licenza basata su socket alla licenza basata su core per Enterprise Edition. Una delle sfide che Microsoft ha dovuto affrontare con questa modifica è stata fornire un percorso di migrazione per i clienti che in precedenza utilizzavano licenze basate su Server+CAL per Enterprise Edition prima di SQL Server 2012. I clienti con Software Assurance possono eseguire l'aggiornamento a SQL Server 2012 Enterprise Edition e continuare a utilizzare Server +Licenza CAL (nota anche come "nonno") ma con una limitazione a 20 processori logici, come documentato nella Guida alle licenze di SQL Server 2012. Questa licenza si estende anche alle macchine virtuali con un limite di 4 macchine virtuali coperte dalla licenza Enterprise Server+CAL, ma con la stessa limitazione di 20 processori logici come documentato nella Guida alle licenze di virtualizzazione di SQL Server 2012.

Molte persone sono state colte alla sprovvista dalla limitazione di 20 processori logici, anche se è documentata nelle guide alle licenze.

Viene inserita una voce nel file ERRORLOG all'avvio dell'istanza, specificando il numero di processori logici e che viene applicata la limitazione di 20 processori:

Con la configurazione predefinita applicata da SQL Server in base alla limitazione di 20 processori logici tramite Server+CAL, i primi 20 scheduler sono VISIBILI IN LINEA e tutti i restanti scheduler sono VISIBILI NON IN LINEA. Di conseguenza, possono verificarsi problemi di prestazioni per l'istanza, a causa degli squilibri del programma di pianificazione del nodo NUMA. Per dimostrarlo ho creato una VM sul nostro server di prova Dell R720 che ha due socket e processori Intel Xeon E5-2670 installati, ciascuno con 8 core e Hyperthreading abilitato, fornendo un totale di 32 processori logici disponibili in Windows Server 2012 Datacenter Edition. La VM è stata configurata per avere 32 CPU virtuali con 16 processori virtuali allocati in due nodi vNUMA.

Figura 1 – Impostazioni vNUMA

In SQL Server con il modello di licenza Enterprise Server+CAL, ciò si traduce in una configurazione dell'utilità di pianificazione simile alla seguente:

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 – Assegnazione dello scheduler in Enterprise Server+CAL

Come puoi vedere, l'istanza utilizza tutti i 16 processori logici nel primo nodo NUMA e solo quattro dei processori logici nel secondo nodo NUMA. Ciò si traduce in un significativo squilibrio degli scheduler tra i due nodi NUMA che può portare a notevoli problemi di prestazioni sotto carico. Per dimostrare ciò, ho creato 300 connessioni che eseguono il carico di lavoro della documentazione in linea di AdventureWorks sull'istanza e quindi ho acquisito le informazioni sull'utilità di pianificazione per le pianificazioni VISIBLE ONLINE nell'istanza utilizzando la query seguente:

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 esempio di output di questa query sotto carico è mostrato nella Figura 3 di seguito.

Figura 3 – Utilità di pianificazione sotto carico con Enterprise Server+CAL

Puoi anche vedere questo sintomo visivamente in strumenti di monitoraggio come SQL Sentry Performance Advisor:

Figura 4 – Squilibrio NUMA come mostrato in SQL Sentry Performance Advisor

Queste informazioni mostrano uno squilibrio significativo e di conseguenza le prestazioni ne risentiranno. Ciò è chiaramente evidente nei conteggi delle attività eseguibili per i quattro schedulatori nel secondo nodo NUMA, che sono da tre a quattro volte più grandi di quelli per gli schedulatori nel primo nodo NUMA. Quindi qual è esattamente il problema e perché si verifica?

A prima vista potresti pensare che questo sia un bug in SQL Server, ma non lo è. Questo è qualcosa che si verifica in base alla progettazione, anche se dubito che questo scenario fosse previsto quando è stata originariamente implementata la limitazione di 20 processori logici. Sui sistemi basati su NUMA, le nuove connessioni vengono assegnate ai nodi NUMA in modo round robin, quindi all'interno del nodo NUMA la connessione viene assegnata a uno scheduler in base al carico. Se cambiamo il modo in cui guardiamo questi dati e aggreghiamo i dati in base a parent_node_id, vedremo che le attività vengono effettivamente bilanciate tra i nodi NUMA. Per fare ciò utilizzeremo la query seguente, il cui output è mostrato nella 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 – Saldo round-robin del nodo NUMA

Questo comportamento è documentato nella documentazione in linea per SQL Server (http://msdn.microsoft.com/en-us/library/ms180954(v=sql.105).aspx). Sapendo quello che so su SQLOS, SQL Server e hardware, questo ha senso. Prima della limitazione di 20 processori logici in SQL Server 2012 Enterprise Edition con licenza Server+CAL, era raro che SQL Server avesse uno squilibrio dell'utilità di pianificazione tra i nodi NUMA in un server di produzione. Uno dei problemi in questo caso specifico è il modo in cui il NUMA virtuale è stato passato alla VM. L'esecuzione della stessa identica installazione sull'hardware fisico consente a tutti gli scheduler di essere ONLINE VISIBILI poiché i processori logici aggiuntivi presentati dagli hyperthread sono distinguibili da SQL e gratuiti.

In altre parole, il limite di 20 processori logici si traduce effettivamente in 40 scheduler ONLINE se (a) non è una macchina virtuale, (b) i processori sono Intel e (c) l'hyper-threading è abilitato.

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;