VMware CPU Hot Plug vNUMA Effekter på SQL Server

När ESX 5 och Hyper-V i Windows Server 2012 släppte och ändrade de begränsningar som tidigare fanns för VM-storlekar, visste jag nästan omedelbart att vi skulle se fler storskaliga SQL Server-arbetsbelastningar börja virtualiseras. Jag har arbetat med ett antal kunder under det senaste året som virtualiserade 16-32 kärn-SQL-servrar av olika anledningar, från förenklade katastrofåterställningsstrategier som matchade resten av verksamheten, till konsolidering och lägre totala ägandekostnader på nyare hårdvara plattformar. En av anledningarna till skalbarhetsförändringen med ESX 5+ var introduktionen av virtuell NUMA (vNUMA) för breda gäster som översteg storleken på en enskild hårdvaru-NUMA-nod. Med vNUMA är gäst-VM optimerad för att matcha hårdvaru-NUMA-topologin, vilket gör att gästoperativsystemet och alla NUMA-medvetna applikationer, som SQL Server, som körs på den virtuella datorn kan dra fördel av NUMA-prestandaoptimeringarna, precis som om de vore körs på en fysisk server.

Inom VMware är en vNUMA-topologi tillgänglig på hårdvaruversion 8 eller högre, och konfigureras som standard om antalet vCPU:er är större än åtta för gästen. Det är också möjligt att manuellt konfigurera vNUMA-topologin för en virtuell dator med hjälp av avancerade konfigurationsalternativ, vilket kan vara användbart för virtuella datorer som har mer minne tilldelat än en fysisk NUMA-nod kan tillhandahålla, men som fortfarande använder åtta eller färre vCPU:er. För det mesta fungerar standardkonfigurationsinställningarna för de flesta virtuella datorer som jag har tittat på under de senaste åren, men det finns vissa scenarier där standard vNUMA-topologin inte är idealisk och manuell konfiguration kan ge vissa fördelar. Nyligen arbetade jag med en klient med ett antal 32 vCPU SQL Server virtuella datorer med 512 GB RAM tilldelat och gjorde lite prestandajustering där vNUMA-topologin inte var i närheten av vad som förväntades.

VM-värdservrarna i den här miljön var fyra socket E5-4650 åtta kärnprocessorer och 1 TB RAM, var och en dedikerad till en enda SQL Server VM under typiska operationer, men med tillgänglig kapacitet för att upprätthålla två virtuella datorer i ett felscenario. Med denna hårdvarulayout finns det fyra NUMA-noder, en per socket, och den förväntade VM-konfigurationen skulle också ha 4 vNUMA-noder presenterade för en 32 vCPU-konfiguration. Men vad jag hittade när jag tittade på DMV i SQL Server var att så inte var fallet:

Figur 1 – Felaktig vNUMA-konfiguration

Som du säkert kan se på bilden är något riktigt fel med NUMA-konfigurationen på denna server. Det finns fyra minnesnoder inom SQLOS och bara en enda CPU-nod, med alla vCPU:er tilldelade i den. För att vara helt ärlig, fick det här mig att tänka när jag såg det eftersom det stred mot allt jag visste om hur SQLOS konfigurerade de interna strukturerna vid instansstart. Efter att ha grävt runt lite i ErrorLog-filerna, Performance Monitor och Windows Task Manager, laddade jag ner en kopia av CoreInfo från SysInternals och tog en titt på NUMA-layouten som rapporteras till Windows.

Logisk processor till NUMA-nodkarta:
********************************* NUMA-nod 0

CoreInfo-utgången bekräftade att den virtuella datorn presenterar de 32 vCPU:erna som 4 olika sockets, men grupperade sedan alla 32 vCPU:erna i NUMA Node 0. När jag tittade på prestandaräknarna för Windows Server 2012 på den virtuella datorn kunde jag se från NUMA Node Memory-räknargruppen, att 4 NUMA minnesnoder presenterades för OS med minnet jämnt fördelat över noderna. Allt detta stämde överens med vad jag såg i SQLOS, och jag kunde också se från ERRORLOG-posterna vid start att CPU-masken för noden maskerade alla tillgängliga CPU:er i CPU Node 0, men fyra stora sidallokatorer skapades, en för varje minnesnod.

Vid det här laget var jag säker på att det var något relaterat till VM-konfigurationen, men jag kunde inte identifiera vad specifikt problemet var eftersom jag aldrig hade sett detta beteende på andra breda SQL Server VM:s som jag hade assisterat klienter på VMware ESX 5+ förr. Efter att ha gjort ett par konfigurationsändringar på en test-VM-server som var tillgänglig, korrigerade bara ingen av dem vNUMA-konfigurationen som presenterades i den virtuella datorn. Efter att ha ringt till VMware-supporten ombads vi att inaktivera vCPU-hotplug-funktionen för test-VM och se om det löste problemet. Med hotplug inaktiverad på den virtuella datorn bekräftade CoreInfo-utgången att vNUMA-mappningen av processorerna för den virtuella datorn nu var korrekt:

Logisk processor till NUMA-nodkarta:
********————————— NUMA-nod 0
——–********————— - NUMA Nod 1
—————-********——– NUMA Nod 2
—————————******** NUMA Node 3

Detta beteende är faktiskt dokumenterat i VMware KB-artikeln, (vNUMA är inaktiverat om VCPU hotplug är aktiverad), från oktober 2013. Detta råkade vara den första breda virtuella datorn för SQL Server som jag hade arbetat med där vCPU hotplug var aktiverad, och det är inte en typisk konfiguration jag skulle förvänta mig för en 32 vCPU VM, men var en del av standardmallen som används på klienten och råkade påverka deras SQL Server.

Effekter av att vNUMA har inaktiverats

Det finns ett antal effekter som vNUMA inaktiveras på det här sättet kan ha för en arbetsbelastning, men det finns två specifika problem som kan påverka SQL Server specifikt under denna typ av konfiguration. Den första är att servern kan ha problem med CMEMTHREAD-väntansamlingar eftersom det finns 32 vCPU:er allokerade till en enda NUMA-nod, och standardpartitioneringen för minnesobjekt i SQLOS är per NUMA-nod. Detta specifika problem dokumenterades av Bob Dorr i CSS-gruppen hos Microsoft i deras blogginlägg SQL Server 2008/2008 R2 på nyare maskiner med fler än 8 processorer presenterade per NUMA-nod kan behöva spårningsflagga 8048. Som en del av att göra väntestatistikgranskning på den virtuella datorn med klienten noterade jag att CMEMTHREAD var deras näst högsta väntetyp, vilket är onormalt enligt min erfarenhet och fick mig att titta på SQLOS NUMA-konfigurationen som visas i figur 1 ovan. I det här fallet är inte spårningsflaggan lösningen, om du tar bort vCPU-hotpluggen från VM-konfigurationen löser problemet problemet.

Det andra problemet som skulle påverka SQL Server specifikt om du använder en oparpad version är associerat med NUMA-minneshantering i SQLOS, och det sätt som SQLOS spårar och hanterar Away-sidor under den initiala minnesupptrappningsfasen efter instansstart. Detta beteende dokumenterades av Bob Dorr i CSS-blogginlägget How It Works:SQL Server (NUMA Local, Foreign and Away Memory Blocks). I huvudsak, när SQLOS försöker en lokal nodminnestilldelning under initial upprampning, om minnesadressen som returneras från en annan minnesnod, läggs sidan till i bortalistan, och ett nytt lokalt minnesallokeringsförsök inträffar, och processen upprepas tills en lokal minnesallokering lyckas, eller så uppnås serverminnesmålet. Eftersom tre fjärdedelar av vårt instansminne finns på NUMA-noder utan några schemaläggare, skapar detta ett försämrat prestandatillstånd under den initiala upprampningen av minnet för instansen. De senaste uppdateringarna har ändrat beteendet för minnesallokering under den initiala upprampningen för att bara försöka den lokala minnesallokeringen ett fast antal gånger (det specifika numret är inte dokumenterat) innan det främmande minnet används för att fortsätta bearbetningen. Dessa uppdateringar är dokumenterade i KB #2819662, FIX:SQL Server-prestandaproblem i NUMA-miljöer.

Sammanfattning

För breda virtuella datorer, definierade som att de har fler än 8 vCPU:er, är det önskvärt att vNUMA skickas in i den virtuella datorn av hypervisorn för att tillåta Windows och SQL Server att utnyttja NUMA-optimeringarna inom sin kodbas. Som ett resultat av detta bör dessa bredare virtuella datorer inte ha vCPU hotplug-konfigurationen aktiverad, eftersom detta är inkompatibelt med vNUMA och kan resultera i försämrad prestanda för SQL Server när den virtualiseras.