Prestandaproblem med SQL Server 2012 Enterprise Edition under CAL-licensiering

Många licensändringar infördes i SQL Server 2012; den viktigaste var övergången från socket-baserad licensiering till kärnbaserad licensiering för Enterprise Edition. En av utmaningarna som Microsoft stod inför med denna förändring var att tillhandahålla en migreringsväg för kunder som tidigare använde Server+CAL-baserad licensiering för Enterprise Edition före SQL Server 2012. Kunder under Software Assurance kan uppgradera till SQL Server 2012 Enterprise Edition och fortfarande använda Server +CAL-licensiering (även känd som "grandfathering") men med en begränsning till 20 logiska processorer, som dokumenterats i SQL Server 2012 Licensing Guide. Denna licensiering sträcker sig även till virtuella datorer med en gräns på 4 virtuella datorer som täcks av Enterprise Server+CAL-licensen, men fortfarande med samma begränsning på 20 logiska processorer som dokumenterats i SQL Server 2012 Virtualization Licensing Guide.

Många människor har blivit överrumplade av begränsningen på 20 logiska processorer, även om det finns dokumenterat i licensguiderna.

En inmatning görs i ERRORLOG-filen när instansen startar, och anger antalet logiska processorer och att begränsningen på 20 processorer tillämpas:

Med standardkonfigurationen som SQL Server tillämpar under begränsningen på 20 logiska processorer med Server+CAL, är de första 20 schemaläggarna VISIBLE ONLINE och alla återstående schemaläggare är VISIBLE OFFLINE. Som ett resultat kan prestandaproblem uppstå för instansen på grund av obalanser i NUMA nodschemaläggare. För att demonstrera detta skapade jag en virtuell dator på vår Dell R720-testserver som har två sockets och Intel Xeon E5-2670-processorer installerade, var och en med 8 kärnor och Hyperthreading aktiverad, vilket ger totalt 32 logiska processorer tillgängliga under Windows Server 2012 Datacenter Edition. Den virtuella datorn konfigurerades för att ha 32 virtuella processorer med 16 virtuella processorer tilldelade i två vNUMA-noder.

Figur 1 – vNUMA-inställningar

I SQL Server under licensmodellen Enterprise Server+CAL resulterar detta i en schemaläggarkonfiguration som liknar följande:

VÄLJ 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;

Figur 2 – Schemaläggartilldelning under Enterprise Server+CAL

Som du kan se används alla 16 logiska processorerna i den första NUMA-noden och endast fyra av de logiska processorerna i den andra NUMA-noden av instansen. Detta resulterar i en betydande obalans av schemaläggare mellan de två NUMA-noderna som kan leda till betydande prestandaproblem under belastning. För att demonstrera detta snurrade jag upp 300 anslutningar som körde AdventureWorks Books Online-arbetsbelastningen mot instansen och samlade sedan in schemaläggarinformationen för VISIBLE ONLINE-schemaläggarna i instansen med hjälp av följande fråga:

VÄLJ 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';

Ett exempel på den här frågan under belastning visas i figur 3 nedan.

Figur 3 – Schemaläggare laddas med Enterprise Server+CAL

Du kan också se detta symptom visuellt i övervakningsverktyg som SQL Sentry Performance Advisor:

Figur 4 – NUMA-obalans som visas i SQL Sentry Performance Advisor

Denna information visar en betydande obalans och prestandan kommer att påverkas som ett resultat. Detta är tydligt uppenbart i antalet körbara uppgifter för de fyra schemaläggarna i den andra NUMA-noden, som är tre till fyra gånger så stora som för schemaläggarna i den första NUMA-noden. Så exakt vad är problemet och varför inträffar detta?

Vid första anblicken kanske du tror att detta är en bugg i SQL Server, men det är det inte. Detta är något som uppstår genom design, även om jag tvivlar på att detta scenario förväntades när begränsningen på 20 logiska processorer ursprungligen implementerades. På NUMA-baserade system tilldelas nya anslutningar till NUMA-noderna på ett round-robin-sätt, och sedan inuti NUMA-noden tilldelas anslutningen en schemaläggare baserat på belastning. Om vi ​​ändrar hur vi ser på denna data och aggregerar data baserat på parent_node_id ser vi att uppgifterna faktiskt balanseras över NUMA-noderna. För att göra detta använder vi följande fråga, vars utdata visas i figur 5.

VÄLJ 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_GROUP_FROM_SCHEMA_DUPLEMs_SYS. /pre> 

 
Figur 5 – NUMA nod round-robin balans 
 

 Detta beteende dokumenteras i Books Online for SQL Server (http://msdn.microsoft.com/en-us/library/ms180954(v=sql.105).aspx). Att veta vad jag vet om SQLOS, SQL Server och hårdvara är det vettigt. Innan begränsningen på 20 logiska processorer i SQL Server 2012 Enterprise Edition med Server+CAL-licensering var det ett sällsynt scenario att SQL Server skulle ha en obalans i schemaläggaren mellan NUMA-noder i en produktionsserver. Ett av problemen i det här specifika fallet är hur den virtuella NUMA skickades till den virtuella datorn. Genom att utföra exakt samma installation på den fysiska hårdvaran kan alla schemaläggare vara SYNLIGA ONLINE eftersom de ytterligare logiska processorerna som presenteras av hypertrådarna är särskiljbara med SQL och gratis.
 

 Med andra ord, den 20-logiska processorgränsen resulterar faktiskt i 40 schemaläggare ONLINE om (a) det inte är en virtuell maskin, (b) processorerna är Intel och (c) hypertrådning är aktiverad. 
 

 Så vi ser detta meddelande i felloggen:
 Datum    11/14/2012 10:36:18 PM
Logg     SQL-server (aktuell – 11/14/2012 22:36:00 PM)
Källa  server
Meddelande
SQL Servern upptäckte 2 sockets med 8 kärnor per socket och 16 logiska processorer per socket, totalt 32 logiska processorer; använder 32 logiska processorer baserade på SQL Server-licenser. Detta är ett informationsmeddelande; ingen användaråtgärd krävs. 

 Och samma fråga som ovan resulterar i att alla 32 processorer är SYNLIGA ONLINE:
 
VÄLJ 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';
 

 
Figur 6 – Samma konfiguration på fysisk hårdvara 
 

 I det här fallet, eftersom det bara finns 32 logiska processorer, påverkar inte gränsen på 20 (nåja, 40) kärnor oss alls, och arbetet fördelas jämnt över alla kärnor.
 

 I scenarier där 20-processorbegränsningen påverkar NUMA-balansen av schemaläggare är det möjligt att manuellt ändra serverkonfigurationen för att balansera antalet VISIBLE ONLINE-schemaläggare i var och en av NUMA-noderna genom att använda ALTER SERVER CONFIGURATION . I det visade VM-exemplet kommer följande kommando att konfigurera de första 10 logiska processorerna i varje NUMA-nod till VISIBLE ONLINE.
 
ALTER SERVER CONFIGURATIONSET PROCESS AFFINITY CPU =0 TILL 9, 16 TILL 25;
 

 Med denna nya konfiguration, som kör samma arbetsbelastning på 300 sessioner och AdventureWorks Books Online-arbetsbelastningen, kan vi se att belastningsobalansen inte längre uppstår.
 

 
Figur 7 – Balans återställd med manuell konfiguration 
 

 Och återigen med hjälp av SQL Sentry Performance Advisor kan vi se CPU-belastningen fördelad mer jämnt över båda NUMA-noderna:
 

 
Figur 8 – NUMA-saldo som visas i SQL Sentry Performance Advisor 
 

 Det här problemet är inte strikt begränsat till virtuella datorer och det sätt som virtuella CPU:er presenteras för operativsystemet. Det är också möjligt att stöta på detta problem med fysisk hårdvara. Till exempel en äldre Dell R910 med fyra sockets och åtta kärnor per socket, eller till och med en AMD Opteron 6200 Interlagos-baserad server med två sockets och 16 kärnor per socket, som presenterar sig som fyra NUMA-noder med vardera åtta kärnor. Under någon av dessa konfigurationer kan processobalansen också resultera i att en av NUMA-noderna är helt offline. Följaktligen kan andra biverkningar som att minnet från den noden distribueras över onlinenoderna som leder till problem med åtkomst till främmande minne också försämra prestandan.
 
Sammanfattning
 

 Standardkonfigurationen av SQL Server 2012 med Enterprise Edition-licenser för Server+CAL är inte idealisk under alla NUMA-konfigurationer som kan finnas för SQL Server. Närhelst Enterprise Server+CAL-licensering används måste NUMA-konfigurationen och schemaläggarens status per NUMA-nod granskas för att säkerställa att SQL Server är konfigurerad för optimal prestanda. Det här problemet uppstår inte under kärnbaserad licensiering eftersom alla schemaläggare är licensierade och SYNLIGA ONLINE.