Ydelsesproblemer med SQL Server 2012 Enterprise Edition under CAL-licens

Adskillige licensændringer blev introduceret i SQL Server 2012; den mest betydningsfulde var overgangen fra socket-baseret licensering til kerne-baseret licensering til Enterprise Edition. En af de udfordringer, som Microsoft stod over for med denne ændring, var at levere en migreringssti til kunder, der tidligere brugte Server+CAL-baseret licens til Enterprise Edition før SQL Server 2012. Kunder under Software Assurance kan opgradere til SQL Server 2012 Enterprise Edition og stadig bruge Server +CAL-licensering (også kendt som "grandfathering"), men med en begrænsning til 20 logiske processorer, som dokumenteret i SQL Server 2012 Licensing Guide. Denne licens omfatter også VM'er med en grænse på 4 VM'er, der er dækket af Enterprise Server+CAL-licensen, men stadig med den samme begrænsning på 20 logiske processorer som dokumenteret i SQL Server 2012 Virtualization Licensing Guide.

Mange mennesker er blevet overrumplet af begrænsningen på 20 logiske processorer, selvom det er dokumenteret i licensvejledningerne.

Der foretages en indtastning i ERRORLOG-filen, når instansen starter op, som angiver antallet af logiske processorer, og at begrænsningen på 20 processorer håndhæves:

Med standardkonfigurationen, som SQL Server anvender under begrænsningen på 20 logiske processorer ved hjælp af Server+CAL, er de første 20 planlæggere VISIBLE ONLINE og eventuelle resterende planlæggere er VISIBLE OFFLINE. Som et resultat kan der opstå ydeevneproblemer for forekomsten på grund af ubalancer i NUMA-knudeplanlægning. For at demonstrere dette oprettede jeg en VM på vores Dell R720-testserver, som har to sockets og Intel Xeon E5-2670-processorer installeret, hver med 8 kerner og Hyperthreading aktiveret, hvilket giver i alt 32 logiske processorer tilgængelige under Windows Server 2012 Datacenter Edition. VM'en blev konfigureret til at have 32 virtuelle CPU'er med 16 virtuelle processorer allokeret i to vNUMA-noder.

Figur 1 – vNUMA-indstillinger

I SQL Server under Enterprise Server+CAL-licensmodellen resulterer dette i en planlægningskonfiguration, der ligner følgende:

VÆLG 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 – Planlægningstildeling under Enterprise Server+CAL

Som du kan se, bruges alle 16 af de logiske processorer i den første NUMA-node og kun fire af de logiske processorer i den anden NUMA-node af instansen. Dette resulterer i en betydelig ubalance mellem planlæggere mellem de to NUMA-knuder, der kan føre til betydelige ydeevneproblemer under belastning. For at demonstrere dette satte jeg 300 forbindelser op, der kørte AdventureWorks Books Online-arbejdsbelastningen mod forekomsten og fangede derefter planlægningsoplysningerne for VISIBLE ONLINE-planlæggerne i forekomsten ved hjælp af følgende forespørgsel:

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';

Et eksempel på output af denne forespørgsel under belastning er vist i figur 3 nedenfor.

Figur 3 – Planlæggere under indlæsning med Enterprise Server+CAL

Du kan også se dette symptom visuelt i overvågningsværktøjer såsom SQL Sentry Performance Advisor:

Figur 4 – NUMA-ubalance som vist i SQL Sentry Performance Advisor

Disse oplysninger viser en betydelig ubalance, og ydeevnen vil blive påvirket som et resultat. Dette er tydeligt tydeligt i antallet af kørebare opgaver for de fire planlæggere i den anden NUMA-knude, som er tre til fire gange større end dem for planlæggerne i den første NUMA-knude. Så hvad er problemet præcist, og hvorfor sker det?

Ved første øjekast tror du måske, at dette er en fejl i SQL Server, men det er det ikke. Dette er noget, der opstår ved design, selvom jeg tvivler på, at dette scenarie var forventet, da begrænsningen på 20 logiske processorer oprindeligt blev implementeret. På NUMA-baserede systemer tildeles nye forbindelser til NUMA-knuderne på en round-robin-måde, og inde i NUMA-knuden tildeles forbindelsen derefter til en planlægger baseret på belastning. Hvis vi ændrer måden, vi ser på disse data på, og aggregerer dataene baseret på parent_node_id, vil vi se, at opgaverne faktisk bliver afbalanceret på tværs af NUMA-knuderne. For at gøre dette bruger vi følgende forespørgsel, hvis output er vist i figur 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_ /pre> 

 
Figur 5 – NUMA node round-robin balance 
 

 Denne adfærd er dokumenteret i Books Online for SQL Server (http://msdn.microsoft.com/en-us/library/ms180954(v=sql.105).aspx). Når jeg ved, hvad jeg ved om SQLOS, SQL Server og hardware, giver det mening. Før begrænsningen på 20 logiske processorer i SQL Server 2012 Enterprise Edition med Server+CAL-licens, var det et sjældent scenarie, at SQL Server ville have en planlægningsubalance mellem NUMA-noder i en produktionsserver. Et af problemerne i dette specifikke tilfælde er måden, hvorpå den virtuelle NUMA blev videregivet til VM'en. Udførelse af nøjagtig den samme installation på den fysiske hardware gør det muligt for alle planlæggere at være ONLINE SYNLIGE, da de yderligere logiske processorer, der præsenteres af hypertrådene, kan skelnes med SQL og gratis.
 

 Med andre ord resulterer den 20-logiske processorgrænse faktisk i 40 planlæggere ONLINE, hvis (a) det ikke er en virtuel maskine, (b) processorerne er Intel, og (c) hyper-threading er aktiveret. 
 

 Så vi ser denne meddelelse i fejlloggen:
 Dato    11/14/2012 10:36:18 PM
Log     SQL-server (aktuel – 14/11/2012 22:36:00 PM)
Kilde  server
Besked
SQL Serveren registrerede 2 sockets med 8 kerner pr. socket og 16 logiske processorer pr. socket, i alt 32 logiske processorer; bruger 32 logiske processorer baseret på SQL Server-licens. Dette er en informativ besked; ingen brugerhandling er påkrævet. 

 Og den samme forespørgsel som ovenfor resulterer i, at alle 32 processorer er SYNLIGE ONLINE:
 
VÆLG 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 – Samme konfiguration på fysisk hardware 
 

 I dette tilfælde, da der kun er 32 logiske processorer, påvirker grænsen på 20 (nå, 40) kerner os overhovedet ikke, og arbejdet er fordelt jævnt på tværs af alle kernerne.
 

 I scenarier, hvor begrænsningen på 20 processorer påvirker NUMA-balancen af ​​planlæggere, er det muligt manuelt at ændre serverkonfigurationen for at balancere antallet af VISIBLE ONLINE-planlæggere i hver af NUMA-knuderne ved brug af ALTER SERVER CONFIGURATION . I det viste VM-eksempel konfigurerer følgende kommando de første 10 logiske processorer i hver NUMA-node til VISIBLE ONLINE.
 
ALTER SERVER CONFIGURATIONSET PROCES AFFINITY CPU =0 TIL 9, 16 TIL 25;
 

 Med denne nye konfiguration, der kører den samme arbejdsbyrde på 300 sessioner og AdventureWorks Books Online-arbejdsbyrden, kan vi se, at belastningsubalancen ikke længere opstår.
 

 
Figur 7 – Balance gendannet med manuel konfiguration 
 

 Og igen ved at bruge SQL Sentry Performance Advisor kan vi se CPU-belastningen fordelt mere jævnt på tværs af begge NUMA-noder:
 

 
Figur 8 – NUMA-balance som vist i SQL Sentry Performance Advisor 
 

 Dette problem er ikke strengt begrænset til VM'er og den måde, virtuelle CPU'er præsenteres for OS. Det er også muligt at løbe ind i dette problem med fysisk hardware. For eksempel en ældre Dell R910 med fire sockets og otte kerner pr. socket, eller endda en AMD Opteron 6200 Interlagos-baseret server med to sockets og 16 cores pr. socket, som præsenterer sig selv som fire NUMA-noder med hver otte kerner. Under en af ​​disse konfigurationer kan procesubalancen også resultere i, at en af ​​NUMA-knuderne er sat helt offline. Følgelig kan andre bivirkninger, såsom hukommelse fra den node, der distribueres på tværs af onlineknuderne, hvilket fører til problemer med adgang til fremmed hukommelse, også forringe ydeevnen.
 
Oversigt
 

 Standardkonfigurationen af ​​SQL Server 2012 ved hjælp af Enterprise Edition-licensen til Server+CAL er ikke ideel under alle NUMA-konfigurationer, der måtte eksistere for SQL Server. Når Enterprise Server+CAL-licensering bruges, skal NUMA-konfigurations- og planlægningsstatussen pr. NUMA-node gennemgås for at sikre, at SQL Server er konfigureret til optimal ydeevne. Dette problem opstår ikke under kernebaseret licensering, da alle planlæggere er licenserede og SYNLIGE ONLINE.