Il y a plusieurs années, Microsoft a publié un article très utile de la base de connaissances sur la façon de configurer SQL Server 2012 et SQL Server 2014 pour obtenir les meilleures performances avec de lourdes charges de travail sur du matériel serveur moderne de plus grande taille. Mon collègue Aaron Bertrand et moi avons tous deux joué un petit rôle dans la vérification de l'article original de la base de connaissances. Cet article de la base de connaissances a été assez bien mis à jour depuis lors, et il reste une excellente référence pour les options de configuration utiles pour SQL Server 2012/2014.
Depuis lors, Microsoft a également rétroporté un certain nombre d'améliorations de performances très utiles de SQL Server 2016 vers SQL Server 2012 et SQL Server 2014, tant que vous êtes sur une version suffisamment récente de l'une de ces anciennes versions de SQL Server. Microsoft vous recommande de déployer de manière proactive les Service Packs et les mises à jour cumulatives afin de minimiser le risque de rencontrer des problèmes qui ont été corrigés dans les versions ultérieures de SQL Server.
En prime, vous obtiendrez également de nouvelles fonctionnalités et d'autres améliorations telles que celles que je décris dans cet article. Dans la plupart des cas, vous devrez activer un indicateur de trace pour bénéficier de ces améliorations de performances.
Gestionnaire de pages sales
Le premier est l'utilisation de Dirty Page Manager (DPM) en conjonction avec l'activation des points de contrôle indirects pour vos bases de données utilisateur et système dans SQL Server 2012 et SQL Server 2014. Les points de contrôle indirects sont la valeur par défaut pour les nouvelles bases de données créées sur SQL Server 2016, et c'est le configuration recommandée pour les instances SQL Server 2016.
Si vous activez le indicateur de suivi 3449 global (et vous êtes sur SQL Server 2012 SP3 CU3 ou version ultérieure ou SQL Server 2014 SP1 CU7 ou version ultérieure), vous obtiendrez de bien meilleures performances en évitant un appel FlushCache dans un certain nombre de scénarios courants différents, tels que la sauvegarde de la base de données, la sauvegarde du journal des transactions, créer une base de données, ajouter un fichier à une base de données, récupérer une base de données, réduire un fichier de base de données et lors d'un arrêt « gracieux » de SQL Server. L'indicateur de suivi 3449 prend effet immédiatement, sans redémarrage nécessaire. Vous devez également définir TF 3449 comme indicateur de trace de démarrage.
Éviter ces appels FlushCache est particulièrement important lorsque vous disposez d'une grande quantité de RAM (plus de 256 Go) dans votre serveur de base de données, l'avantage augmentant avec la taille de votre pool de mémoire tampon utilisé. Vous pouvez en savoir plus sur cette amélioration dans cet article de blog :
Ensuite, si vous utilisez SQL Server 2012 SP4 ou SQL Server 2014 SP2 (ou version ultérieure), vous obtiendrez un certain nombre d'autres nouvelles améliorations de performances, telles que le partitionnement Soft NUMA automatique et la mise à l'échelle dynamique des objets de mémoire qui ont été initialement introduits dans SQL Server 2016. .
Partitionnement NUMA logiciel automatique
Dans SQL Server 2012 SP4 et SQL Server 2014 SP2, lorsque vous définissez Trace Flag 8079 en tant qu'indicateur de trace de démarrage, SQL Server analysera la disposition du matériel lors du démarrage du moteur et configurera automatiquement Soft NUMA sur les systèmes signalant 8 cœurs physiques ou plus par nœud NUMA. Le comportement NUMA logiciel automatique est compatible Hyperthreading (HT/processeur logique), ce qui signifie qu'il fonctionne à la fois avec Intel Hyper-Threading et AMD SMT. Lors de la détermination de la disposition optimale des nœuds NUMA logiciels, les informations du processeur logique sont interrogées et utilisées pour empêcher les regroupements de nœuds logiques uniquement et physiques uniquement, ce qui pourrait entraîner des variations de performances entre les nœuds NUMA logiciels.
Les processeurs de serveur actuels peuvent avoir jusqu'à 32 cœurs physiques dans un seul nœud NUMA, ce qui peut exposer des problèmes d'évolutivité de type SMP dans un seul nœud NUMA matériel. Microsoft affirme constater une amélioration notable des performances grâce à cette fonctionnalité en utilisant son harnais de test interne SQL Server 2016 :
"Avec HT conscient auto soft-NUMA, nous obtenons jusqu'à 30 % de gain de performances de requête lorsque DOP est défini sur le nombre de cœurs physiques sur un socket (12 dans ce cas) en utilisant Automatic Soft NUMA."
Comme toujours, c'est une bonne idée de tester les performances de votre charge de travail avec Automatic Soft NUMA avant de l'utiliser en production.
Mise à l'échelle dynamique de l'objet mémoire
Dans SQL Server 2012 SP4 et SQL Server 2014 SP2, SQL Server partitionnera dynamiquement les objets mémoire en fonction du nombre de nœuds NUMA et de cœurs de processeur logique pour mieux évoluer sur le matériel serveur moderne. L'objectif de la promotion dynamique est de partitionner automatiquement un objet mémoire thread-safe (CMEMTHREAD) s'il devient un goulot d'étranglement.
Les objets de mémoire non partitionnés seront dynamiquement promus pour être partitionnés par le nœud NUMA (le nombre de partitions est égal au nombre de nœuds NUMA) en fonction de la charge de travail et du goulot d'étranglement, et les objets de mémoire partitionnés par le nœud NUMA peuvent être davantage promus pour être partitionnés par des cœurs de CPU logiques (le nombre de partitions est égal au nombre de cœurs de CPU logiques). Cette amélioration élimine le besoin de Trace Flag 8048 une fois que vous avez installé SQL 2014 SP2 ou SQL Server 2012 SP4.
Amélioration du verrou tournant SOS_RWLock
Dans SQL Server 2014 SP2, il existe des améliorations (à nouveau rétroportées à partir de SQL Server 2016) qui suppriment le besoin de verrous tournants pour les opérations SOS_RWLock. Microsoft décrit cette amélioration plus en détail comme suit :
"Le SOS_RWLock est une primitive de synchronisation utilisée à divers endroits dans la base de code SQL Server. Comme son nom l'indique, le code peut avoir plusieurs propriétaires partagés (lecteurs) ou uniques (écrivain). Cette amélioration supprime le besoin de verrou tournant pour SOS_RWLock et utilise à la place des techniques sans verrouillage similaires à l'OLTP en mémoire. Avec ce changement, de nombreux threads peuvent lire une structure de données protégée par SOS_RWLock en parallèle sans se bloquer mutuellement et offrant ainsi une évolutivité accrue. Avant ce changement, l'ancienne implémentation du verrou tournant n'autorisait qu'un seul thread à acquérir le SOS_RWLock à la fois même pour lire une structure de données."
Vous obtiendrez également un certain nombre d'améliorations de gérabilité utiles dans SQL Server 2012 SP4 et SQL Server 2014 SP2. Vous pouvez en savoir plus sur ces améliorations dans ces articles de blog :
- SQL Server 2012 Service Pack 4 (SP4) est sorti !
- SQL Server 2014 Service Pack 2 est maintenant disponible !!!
La clé à retenir de tout cela est que si vous exécutez SQL Server 2012 (qui n'est plus pris en charge le 11 juillet 2017), vous voulez être sur SQL Server 2012 SP4, tandis que si vous exécutez SQL Server 2014, vous voulez être sur SQL Server 2014 SP2 ou plus récent. Vous devrez également activer les indicateurs de trace applicables et définir les propriétés de base de données pertinentes pour tirer parti de ces améliorations.
