Diversi anni fa, Microsoft ha pubblicato un articolo della Knowledge Base molto utile su come configurare SQL Server 2012 e SQL Server 2014 per le migliori prestazioni con carichi di lavoro pesanti su hardware server moderno e di dimensioni maggiori. Il mio collega Aaron Bertrand ed io entrambi abbiamo avuto un piccolo ruolo nel controllo dell'articolo originale della KB. Da allora questo articolo della Knowledge Base è stato mantenuto abbastanza aggiornato ed è ancora un ottimo riferimento per utili opzioni di configurazione per SQL Server 2012/2014.
Da allora, Microsoft ha anche apportato una serie di utili miglioramenti delle prestazioni da SQL Server 2016 a SQL Server 2012 e SQL Server 2014, a patto che tu sia su una build abbastanza nuova di una di queste versioni precedenti di SQL Server. Microsoft consiglia di distribuire in modo proattivo Service Pack e Aggiornamenti cumulativi per ridurre al minimo la possibilità che si verifichino problemi che sono stati corretti nelle build successive di SQL Server.
Come bonus aggiuntivo, otterrai anche nuove funzionalità e altri miglioramenti come ho descritto in questo articolo. Nella maggior parte dei casi, sarà necessario abilitare un flag di traccia per ottenere il vantaggio di questi miglioramenti delle prestazioni.
Gestione pagine sporche
Il primo è l'uso di Dirty Page Manager (DPM) insieme all'abilitazione di checkpoint indiretti per i database utente e di sistema in SQL Server 2012 e SQL Server 2014. I checkpoint indiretti sono l'impostazione predefinita per i nuovi database creati in SQL Server 2016 ed è il configurazione consigliata per le istanze di SQL Server 2016.
Se abiliti il Trace Flag 3449 globale (e utilizzi SQL Server 2012 SP3 CU3 o versioni successive o SQL Server 2014 SP1 CU7 o versioni successive), otterrai prestazioni molto migliori evitando una chiamata FlushCache in diversi scenari comuni, come database di backup, registro delle transazioni di backup, creare database, aggiungere un file a un database, ripristinare un database, ridurre un file di database e durante un arresto "grazioso" di SQL Server. Il flag di traccia 3449 ha effetto immediato, senza che sia necessario riavviare. È inoltre necessario impostare TF 3449 come flag di traccia di avvio.
Evitare queste chiamate FlushCache è particolarmente importante quando si dispone di una grande quantità di RAM (più di 256 GB) nel server di database, con il vantaggio che aumenta con la dimensione del pool di buffer in uso. Puoi leggere questo miglioramento in modo più dettagliato in questo post del blog:
Successivamente, se utilizzi SQL Server 2012 SP4 o SQL Server 2014 SP2 (o versioni successive), otterrai una serie di altri nuovi miglioramenti delle prestazioni, come il partizionamento Soft NUMA automatico e il ridimensionamento dinamico degli oggetti di memoria originariamente introdotti in SQL Server 2016
Partizionamento Soft NUMA automatico
In SQL Server 2012 SP4 e SQL Server 2014 SP2, quando imposti Flag di traccia 8079 come flag di traccia di avvio, SQL Server eseguirà la scansione del layout hardware durante l'avvio del motore e configurerà automaticamente Soft NUMA sui sistemi che segnalano 8 o più core fisici per nodo NUMA. Il comportamento automatico del soft NUMA è compatibile con Hyperthreading (HT/processore logico), il che significa che funziona sia con Intel Hyper-Threading che con AMD SMT. Quando si determina il layout ottimale del nodo NUMA soft, le informazioni sulla CPU logica vengono interrogate e utilizzate per prevenire raggruppamenti di nodi solo logici e solo fisici che potrebbero causare variazioni delle prestazioni tra i nodi NUMA soft.
Gli attuali processori server possono avere fino a 32 core fisici in un singolo nodo NUMA che può esporre problemi di scalabilità simili a SMP all'interno di un singolo nodo NUMA hardware. Microsoft afferma di vedere un notevole miglioramento delle prestazioni da questa funzionalità utilizzando il proprio cablaggio di test interno di SQL Server 2016:
"Con HT-aware Soft-NUMA, otteniamo fino al 30% di guadagno nelle prestazioni delle query quando DOP è impostato sul numero di core fisici su un socket (12 in questo caso) utilizzando Automatic Soft NUMA."
Come sempre, è una buona idea testare le prestazioni del tuo carico di lavoro con Automatic Soft NUMA prima di utilizzarlo in produzione.
Ridimensionamento dinamico degli oggetti di memoria
Sia in SQL Server 2012 SP4 che in SQL Server 2014 SP2, SQL Server partiziona dinamicamente gli oggetti di memoria in base al numero di nodi NUMA e di core del processore logico per una migliore scalabilità sull'hardware del server moderno. L'obiettivo della promozione dinamica è partizionare automaticamente un oggetto di memoria thread-safe (CMEMTHREAD) se diventa un collo di bottiglia.
Gli oggetti di memoria non partizionati verranno promossi dinamicamente per essere partizionati dal nodo NUMA (il numero di partizioni è uguale al numero di nodi NUMA) in base al carico di lavoro e al collo di bottiglia e gli oggetti di memoria partizionati dal nodo NUMA possono essere ulteriormente promossi per essere partizionati dai core logici della CPU (il numero di partizioni è uguale al numero di core logici della CPU). Questo miglioramento elimina la necessità del flag di traccia 8048 dopo aver installato SQL 2014 SP2 o SQL Server 2012 SP4.
Miglioramento SOS_RWLock Spinlock
In SQL Server 2014 SP2 sono presenti miglioramenti (di nuovo trasferiti da SQL Server 2016) che eliminano la necessità di spinlock per le operazioni SOS_RWLock. Microsoft descrive questo miglioramento in modo più dettagliato in questo modo:
"SOS_RWLock è una primitiva di sincronizzazione utilizzata in vari punti della codebase di SQL Server. Come suggerisce il nome, il codice può avere più proprietà condivise (lettori) o singole (scrittori). Questo miglioramento elimina la necessità di spinlock per SOS_RWLock e utilizza invece tecniche lock-free simili a OLTP in memoria. Con questa modifica, molti thread possono leggere una struttura di dati protetta da SOS_RWLock in parallelo senza bloccarsi a vicenda e fornendo così una maggiore scalabilità. Prima di questa modifica, l'implementazione spinlock precedente consentiva a un solo thread di acquisire SOS_RWLock alla volta anche per leggere una struttura dati."
Otterrai anche una serie di utili miglioramenti della gestibilità sia in SQL Server 2012 SP4 che in SQL Server 2014 SP2. Puoi leggere questi miglioramenti in modo più dettagliato in questi post del blog:
- Rilasciato SQL Server 2012 Service Pack 4 (SP4)!
- SQL Server 2014 Service Pack 2 è ora disponibile!!!
Il punto chiave di tutto ciò è che se si esegue SQL Server 2012 (che è caduto dal supporto mainstream l'11 luglio 2017), si desidera essere su SQL Server 2012 SP4, mentre se si esegue SQL Server 2014, vuoi essere su SQL Server 2014 SP2 o versioni successive. Dovrai anche abilitare i flag di traccia applicabili e impostare le proprietà del database pertinenti per sfruttare questi miglioramenti.
