Prestatieproblemen met SQL Server 2012 Enterprise Edition onder CAL-licentieverlening

In SQL Server 2012 zijn tal van licentiewijzigingen doorgevoerd; de belangrijkste was de overgang van licenties op basis van sockets naar licenties op basis van cores voor Enterprise Edition. Een van de uitdagingen waarmee Microsoft met deze wijziging werd geconfronteerd, was het bieden van een migratiepad voor klanten die eerder Server+CAL-licenties voor Enterprise Edition gebruikten vóór SQL Server 2012. Klanten onder Software Assurance kunnen upgraden naar SQL Server 2012 Enterprise Edition en nog steeds Server gebruiken +CAL-licenties (ook bekend als "grandfathering") maar met een beperking tot 20 logische processors, zoals gedocumenteerd in de SQL Server 2012 Licensing Guide. Deze licentie strekt zich ook uit tot VM's met een limiet van 4 VM's die worden gedekt door de Enterprise Server+CAL-licentie, maar nog steeds met dezelfde 20 logische processorbeperking als gedocumenteerd in de SQL Server 2012 Virtualization Licensing Guide.

Veel mensen zijn overrompeld door de 20 logische processorbeperking, ook al is dit gedocumenteerd in de licentiehandleidingen.

Er wordt een invoer gemaakt in het ERRORLOG-bestand wanneer de instantie opstart, met vermelding van het aantal logische processors en dat de beperking van 20 processors wordt afgedwongen:

Met de standaardconfiguratie die SQL Server toepast onder de limiet van 20 logische processors met Server+CAL, zijn de eerste 20 planners ONLINE ZICHTBAAR en alle resterende planners ZICHTBAAR OFFLINE. Als gevolg hiervan kunnen er prestatieproblemen optreden voor de instantie, als gevolg van onevenwichtigheden in de NUMA-node-planner. Om dit te demonstreren heb ik een VM gemaakt op onze Dell R720-testserver met twee sockets en Intel Xeon E5-2670-processors geïnstalleerd, elk met 8 cores en Hyperthreading ingeschakeld, waardoor er in totaal 32 logische processors beschikbaar zijn onder Windows Server 2012 Datacenter Edition. De VM is geconfigureerd om 32 virtuele CPU's te hebben met 16 virtuele processors toegewezen in twee vNUMA-knooppunten.

Figuur 1 – vNUMA-instellingen

In SQL Server onder het Enterprise Server+CAL-licentiemodel resulteert dit in een plannerconfiguratie die er ongeveer als volgt uitziet:

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

Figuur 2 – Plannertoewijzing onder Enterprise Server+CAL

Zoals u kunt zien, worden alle 16 logische processors in het eerste NUMA-knooppunt en slechts vier van de logische processors in het tweede NUMA-knooppunt door de instantie gebruikt. Dit resulteert in een aanzienlijke onbalans van planners tussen de twee NUMA-knooppunten, wat kan leiden tot aanzienlijke prestatieproblemen onder belasting. Om dit te demonstreren, heb ik 300 verbindingen gemaakt met de AdventureWorks Books Online-workload tegen de instantie en vervolgens de plannerinformatie voor de ZICHTBARE ONLINE-planners in de instantie vastgelegd met behulp van de volgende query:

SELECT parent_node_id, scheduler_id, [cpu_id], is_idle, current_tasks_count, runnable_tasks_count, active_workers_count, load_factorFROM sys.dm_os_schedulersWHERE [status] =N'VISIBLE ONLINE';

Een voorbeelduitvoer van deze query onder belasting wordt weergegeven in Afbeelding 3 hieronder.

Figuur 3 – Planners onder belasting met Enterprise Server+CAL

U kunt dit symptoom ook visueel zien in monitoringtools zoals SQL Sentry Performance Advisor:

Figuur 4 – NUMA-onbalans zoals weergegeven in SQL Sentry Performance Advisor

Deze informatie laat een aanzienlijke onbalans zien en de prestaties zullen hierdoor worden beïnvloed. Dit blijkt duidelijk uit het aantal uitvoerbare taken voor de vier planners in het tweede NUMA-knooppunt, die drie tot vier keer zo groot zijn als die voor de planners in het eerste NUMA-knooppunt. Dus wat is precies het probleem en waarom gebeurt dit?

Op het eerste gezicht zou je denken dat dit een bug in SQL Server is, maar dat is niet zo. Dit is iets dat inherent is aan het ontwerp, hoewel ik betwijfel of dit scenario werd verwacht toen de 20 logische processorbeperking oorspronkelijk werd geïmplementeerd. Op NUMA-gebaseerde systemen worden nieuwe verbindingen op een round-robin-manier toegewezen aan de NUMA-knooppunten, en vervolgens binnen het NUMA-knooppunt wordt de verbinding toegewezen aan een planner op basis van belasting. Als we de manier waarop we naar deze gegevens kijken veranderen en de gegevens samenvoegen op basis van parent_node_id, zullen we zien dat de taken daadwerkelijk worden verdeeld over de NUMA-knooppunten. Om dit te doen gebruiken we de volgende query, waarvan de uitvoer wordt getoond in figuur 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_factorFROM sys.dm_os_BLE]ouders'. /pre> 

 
Figuur 5 – NUMA-knooppunt round-robin-saldo 
 

 Dit gedrag is gedocumenteerd in Books Online voor SQL Server (http://msdn.microsoft.com/en-us/library/ms180954(v=sql.105).aspx). Wetende wat ik weet over SQLOS, SQL Server en hardware, is dit logisch. Vóór de beperking van 20 logische processors in SQL Server 2012 Enterprise Edition met Server+CAL-licenties, was het een zeldzaam scenario dat SQL Server een onbalans in de planner zou hebben tussen NUMA-knooppunten in een productieserver. Een van de problemen in dit specifieke geval is de manier waarop de virtuele NUMA werd doorgegeven aan de VM. Door exact dezelfde installatie op de fysieke hardware uit te voeren, kunnen alle planners ONLINE ZICHTBAAR zijn, aangezien de extra logische processors die door de hyperthreads worden gepresenteerd, te onderscheiden zijn door SQL en gratis zijn.
 

 Met andere woorden, de 20-logische processorlimiet resulteert in feite in 40 planners ONLINE als (a) het geen virtuele machine is, (b) de processors Intel zijn en (c) hyperthreading is ingeschakeld. sterk> 
 

 Dus we zien dit bericht in het foutenlogboek:
 Datum    14-11-2012 10:36:18 uur
Log     SQL-server (huidig ​​– 14-11-2012 10:36:00 uur)
Bron  Server
Bericht
SQL Server heeft 2 sockets gedetecteerd met 8 cores per socket en 16 logische processors per socket, 32 in totaal logische processors; gebruikmakend van 32 logische processors op basis van SQL Server-licenties. Dit is een informatief bericht; er is geen gebruikersactie vereist. 

 En dezelfde zoekopdracht als hierboven resulteert erin dat alle 32 processors ONLINE ZICHTBAAR zijn:
 
SELECT parent_node_id, [status], scheduler_id, [cpu_id], is_idle, current_tasks_count, runnable_tasks_count, active_workers_count, load_factorFROM sys.dm_os_schedulersWHERE [status] =N'VISIBLE ONLINE';
 

 
Figuur 6 – Dezelfde configuratie op fysieke hardware 
 

 In dit geval, aangezien er slechts 32 logische processors zijn, heeft de limiet van 20 (nou ja, 40) cores helemaal geen invloed op ons, en wordt het werk gelijk verdeeld over alle cores.
 

 In scenario's waarin de beperking van 20 processors de NUMA-balans van planners beïnvloedt, is het mogelijk om de serverconfiguratie handmatig te wijzigen om het aantal ZICHTBARE ONLINE-planners in elk van de NUMA-knooppunten in evenwicht te brengen door het gebruik van ALTER SERVER CONFIGURATION . In het gegeven VM-voorbeeld configureert de volgende opdracht de eerste 10 logische processors in elk NUMA-knooppunt naar VISIBLE ONLINE.
 
WIJZIG SERVERCONFIGURATIESET PROCESAFFINITY CPU =0 TOT 9, 16 TOT 25;
 

 Met deze nieuwe configuratie, met dezelfde workload van 300 sessies en de AdventureWorks Books Online-workload, kunnen we zien dat de onbalans in de belasting niet langer optreedt.
 

 
Figuur 7 – Balans hersteld met handmatige configuratie 
 

 En opnieuw met SQL Sentry Performance Advisor kunnen we zien dat de CPU-belasting gelijkmatiger wordt verdeeld over beide NUMA-knooppunten:
 

 
Figuur 8 – NUMA-balans zoals weergegeven in SQL Sentry Performance Advisor 
 

 Dit probleem is niet strikt beperkt tot VM's en de manier waarop virtuele CPU's aan het besturingssysteem worden gepresenteerd. Het is ook mogelijk om dit probleem tegen te komen met fysieke hardware. Bijvoorbeeld een oudere Dell R910 met vier sockets en acht cores per socket, of zelfs een op AMD Opteron 6200 Interlagos gebaseerde server met twee sockets en 16 cores per socket, die zichzelf presenteert als vier NUMA-knooppunten met elk acht cores. Onder een van deze configuraties kan de procesonbalans er ook toe leiden dat een van de NUMA-knooppunten volledig offline wordt gezet. Bijgevolg kunnen andere bijwerkingen, zoals geheugen van dat knooppunt dat wordt gedistribueerd over de online knooppunten, wat leidt tot problemen met toegang tot vreemd geheugen, ook de prestaties verslechteren.
 
Samenvatting
 

 De standaardconfiguratie van SQL Server 2012 met gebruik van de Enterprise Edition-licentie voor Server+CAL is niet ideaal onder alle NUMA-configuraties die mogelijk voor SQL Server bestaan. Telkens wanneer Enterprise Server+CAL-licenties worden gebruikt, moeten de NUMA-configuratie en plannerstatussen per NUMA-knooppunt worden herzien om ervoor te zorgen dat SQL Server is geconfigureerd voor optimale prestaties. Dit probleem doet zich niet voor onder licenties op basis van cores, aangezien alle planners een licentie hebben en ONLINE ZICHTBAAR zijn.