För flera år sedan publicerade Microsoft en mycket användbar Knowledge Base-artikel om hur man konfigurerar SQL Server 2012 och SQL Server 2014 för bästa prestanda med tunga arbetsbelastningar på större, modern serverhårdvara. Min kollega Aaron Bertrand och jag hade båda en liten roll i granskningen av den ursprungliga KB-artikeln. Den här KB-artikeln har hållits ganska väl uppdaterad sedan dess, och den är fortfarande en bra referens för användbara konfigurationsalternativ för SQL Server 2012/2014.
Sedan dess har Microsoft också återporterat ett antal mycket användbara prestandaförbättringar från SQL Server 2016 till både SQL Server 2012 och SQL Server 2014, så länge du är på en tillräckligt ny version av någon av dessa äldre versioner av SQL Server. Microsoft rekommenderar att du proaktivt distribuerar både Service Pack och kumulativa uppdateringar för att minimera risken för att stöta på problem som korrigerades i senare versioner av SQL Server.
Som en extra bonus får du även nya funktioner och andra förbättringar som jag beskriver i den här artikeln. I de flesta fall måste du aktivera en spårningsflagga för att dra nytta av dessa prestandaförbättringar.
Dirty Page Manager
Det första är användningen av Dirty Page Manager (DPM) i kombination med att aktivera indirekta kontrollpunkter för dina användar- och systemdatabaser i SQL Server 2012 och SQL Server 2014. Indirekta kontrollpunkter är standard för nya databaser skapade på SQL Server 2016, och det är rekommenderad konfiguration för SQL Server 2016-instanser.
Om du aktiverar global Trace Flag 3449 (och du använder SQL Server 2012 SP3 CU3 eller senare eller SQL Server 2014 SP1 CU7 eller senare), kommer du att få mycket bättre prestanda genom att undvika ett FlushCache-anrop i ett antal olika vanliga scenarier, såsom backup-databas, backup-transaktionslogg, skapa databas, lägga till en fil i en databas, återställa en databas, krympa en databasfil och under en "graciös" avstängning av SQL Server. Spårningsflagga 3449 träder i kraft omedelbart, utan någon omstart krävs. Du bör också ställa in TF 3449 som en startspårningsflagga.
Att undvika dessa FlushCache-anrop är särskilt viktigt när du har en stor mängd RAM (mer än 256 GB) i din databasserver, med fördelen som ökar med storleken på din buffertpool som används. Du kan läsa mer om denna förbättring i det här blogginlägget:
Därefter, om du använder SQL Server 2012 SP4 eller SQL Server 2014 SP2 (eller senare), kommer du att få ett antal andra nya prestandaförbättringar, såsom automatisk Soft NUMA-partitionering och dynamisk minnesobjektskalning som ursprungligen introducerades i SQL Server 2016
Automatisk mjuk NUMA-partitionering
I både SQL Server 2012 SP4 och SQL Server 2014 SP2, när du ställer in Trace Flag 8079 som en startspårningsflagga kommer SQL Server att skanna hårdvarulayouten under motorstart och automatiskt konfigurera Soft NUMA på system som rapporterar 8 eller fler fysiska kärnor per NUMA-nod. Det automatiska mjuka NUMA-beteendet är Hyperthreading (HT/logisk processor) medvetet, vilket betyder att det fungerar med både Intel Hyper-Threading och AMD SMT. När den optimala mjuka NUMA-nodlayouten bestäms, efterfrågas den logiska CPU-informationen och används för att förhindra gruppering av endast logiska och endast fysiska noder, vilket kan leda till prestandavariationer mellan de mjuka NUMA-noderna.
Nuvarande serverprocessorer kan ha upp till 32 fysiska kärnor i en enda NUMA-nod som kan avslöja SMP-liknande skalbarhetsproblem inom en enda hårdvaru-NUMA-nod. Microsoft hävdar att de ser en märkbar prestandaförbättring från den här funktionen med hjälp av deras interna SQL Server 2016 testkabel:
"Med HT-medveten auto soft-NUMA får vi upp till 30 % vinst i frågeprestanda när DOP är inställt på antalet fysiska kärnor på en socket (12 i det här fallet) med Automatic Soft NUMA."
Som alltid är det en bra idé att testa prestandan för din arbetsbelastning med Automatic Soft NUMA innan du använder den i produktionen.
Dynamisk minnesobjektskalning
I både SQL Server 2012 SP4 och SQL Server 2014 SP2 kommer SQL Server dynamiskt att partitionera minnesobjekt baserat på antalet NUMA-noder och logiska processorkärnor för att skala bättre på modern serverhårdvara. Målet med dynamisk marknadsföring är att automatiskt partitionera ett trådsäkert minnesobjekt (CMEMTHREAD) om det blir en flaskhals.
Opartitionerade minnesobjekt kommer dynamiskt att främjas för att partitioneras av NUMA-noden (antalet partitioner är lika med antalet NUMA-noder) baserat på arbetsbelastningen och flaskhalsen, och minnesobjekt som partitioneras av NUMA-noden kan ytterligare befordras till att partitioneras av logiska CPU-kärnor (antalet partitioner är lika med antalet logiska CPU-kärnor). Denna förbättring eliminerar behovet av Trace Flag 8048 när du väl har installerat SQL 2014 SP2 eller SQL Server 2012 SP4.
SOS_RWLock Spinlock-förbättring
I SQL Server 2014 SP2 finns det förbättringar (återigen porterade från SQL Server 2016) som tar bort behovet av spinlocks för SOS_RWLock-operationer. Microsoft beskriver denna förbättring mer i detalj så här:
"SOS_RWLock är en synkroniseringsprimitiv som används på olika platser i SQL Server-kodbasen. Som namnet antyder kan koden ha flera delade (läsare) eller enstaka (skrivare) äganderätter. Denna förbättring tar bort behovet av spinlock för SOS_RWLock och använder istället låsfria tekniker som liknar OLTP i minnet. Med denna förändring kan många trådar läsa en datastruktur som skyddas av SOS_RWLock parallellt utan att blockera varandra och därmed ge ökad skalbarhet. Före denna förändring tillät den äldre spinlock-implementeringen endast en tråd att skaffa SOS_RWLock åt gången även för att läsa en datastruktur."
Du kommer också att få ett antal användbara hanterbarhetsförbättringar i både SQL Server 2012 SP4 och SQL Server 2014 SP2. Du kan läsa mer om dessa förbättringar i dessa blogginlägg:
- SQL Server 2012 Service Pack 4 (SP4) släppt!
- SQL Server 2014 Service Pack 2 är nu tillgängligt!!!
Nyckeln från allt detta är att om du kör SQL Server 2012 (som föll ur det vanliga stödet den 11 juli 2017), vill du vara på SQL Server 2012 SP4, medan om du kör SQL Server 2014, du vill ha SQL Server 2014 SP2 eller senare. Du måste också aktivera tillämpliga spårningsflaggor och ställa in relevanta databasegenskaper för att dra nytta av dessa förbättringar.