La consommation de «mémoire totale du serveur» de SQL Server stagne depuis des mois avec 64 Go et plus disponibles

Question

J'ai rencontré un problème étrange où SQL Server 2016 Standard Edition 64 bits semble s'être limité à exactement la moitié de la mémoire totale allouée à celui-ci (64 Go de 128 Go).

La sortie de @@VERSION Est:

Microsoft SQL Server 2016 (SP1-CU7-GDR) (KB4057119) - 13.0.4466.4 (X64) 22 décembre 2017 11:25:00 Copyright (c) Microsoft Corporation Standard Edition (64 bits) sur Windows Server 2012 R2 Datacenter 6.3 ( Build 9600:) (Hyperviseur)

La sortie de sys.dm_os_process_memory Est:

Lorsque je demande sys.dm_os_performance_counters, Je vois que la Target Server Memory (KB) est à 131072000 Et Total Server Memory (KB) est à un peu moins de la moitié de celle à 65308016. Dans la plupart des scénarios, je comprendrais qu'il s'agit d'un comportement normal car SQL Server n'a pas encore déterminé qu'il doit allouer de la mémoire supplémentaire pour lui-même.

Cependant, il est "bloqué" à ~ 64 Go depuis plus de 2 mois maintenant. Au cours de cette période, nous avons effectué une quantité importante d'opérations gourmandes en mémoire sur certaines des bases de données et avons ajouté près de 40 bases de données supplémentaires à l'instance. Nous sommes assis à 292 bases de données au total, chacune avec des fichiers de données pré-alloués à 4 Go avec un taux de croissance automatique de 256 Mo et des fichiers journaux de 2 Go avec un taux de croissance automatique de 128 Mo. J'effectue une sauvegarde complète une fois par nuit à 12 h 00 et commence les sauvegardes du journal des transactions du lundi au vendredi à partir de 6 h 00 à 20 h 00, toutes les 15 minutes. Ces bases de données sont relativement faibles sur leur débit global, mais je suis sceptique que quelque chose ne va pas étant donné que SQL Server ne s'est pas glissé vers le Target Server Memory Naturellement à travers de nouveaux ajouts de bases de données, des exécutions de requêtes normales, ainsi que de la mémoire -des pipelines ETL intensifs qui ont été exécutés.

L'instance SQL Server elle-même se trouve au sommet d'un serveur Windows Server 2012R2 virtualisé (VMware) avec 12 CPU, 144 Go de mémoire (128 Go vers SQL Server, 16 Go réservés pour Windows) et 4 disques virtuels au total qui se trouvent au sommet d'un vSAN avec 15 000 SAS lecteurs. Windows se trouve naturellement sur un disque C: 64 Go avec un fichier d'échange de 32 Go. Les fichiers de données se trouvent sur un disque D: 2 To, les fichiers journaux se trouvent au-dessus d'un disque L: 2 To et tempdb se trouve sur un disque T: 256 Go avec des fichiers 8 x 16 Go sans croissance automatique.

J'ai vérifié qu'il n'y a aucune autre instance de SQL Server en cours d'exécution sur le serveur à part MSSQLSERVER.

Ce serveur est entièrement dédié uniquement à l'instance SQL Server, nous n'avons donc aucune autre application ou service en cours d'exécution qui pourrait consommer de la mémoire.

J'utilise RedGate SQL Monitor pour l'analyse, et ci-dessous est un historique des 18 derniers jours de Total Server Memory. Comme vous pouvez le voir, l'utilisation de la mémoire est restée entièrement stagnante, à l'exception d'une seule remontée d'environ 300 Mo début avril.

Quelle pourrait en être la cause? Que puis-je regarder de plus près pour déterminer pourquoi SQL Server ne veut pas utiliser les 64 Go + de mémoire supplémentaires qui lui sont alloués?

Le résultat de l'exécution de sp_Blitz:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1; 
Priorité 50: Performances :

Planificateurs de CPU hors ligne - Certains cœurs de CPU ne sont pas accessibles à SQL Server en raison de masques d'affinité ou de problèmes de licence.

Nœuds de mémoire hors ligne - En raison de problèmes de masquage d'affinité ou de licence, une partie de la mémoire peut ne pas être disponible.

Priorité 50: Fiabilité :

DAC distant désactivé - L'accès à distance à la connexion d'administration dédiée (DAC) n'est pas activé. Le DAC peut faciliter le dépannage à distance lorsque SQL Server ne répond pas.

Priorité 100: Performances :

De nombreux plans pour une seule requête - 300 plans sont présents pour une seule requête dans le cache du plan, ce qui signifie que nous avons probablement des problèmes de paramétrage.

Déclencheurs de serveur activés

Le déclencheur du serveur [RG_SQLLighthouse_DDLTrigger] est activé. Assurez-vous de comprendre ce que fait ce déclencheur - moins il fait de travail, mieux c'est.

Le déclencheur du serveur [SSMSRemoteBlock] est activé. Assurez-vous de comprendre ce que fait ce déclencheur - moins il fait de travail, mieux c'est.

Priorité 150: Performances :

Requêtes forçant les indices de jointure - 1480 instances d'indices de jointure ont été enregistrées depuis le redémarrage. Cela signifie que les requêtes gèrent l'optimiseur SQL Server, et si elles ne savent pas ce qu'elles font, cela peut causer plus de tort que de bien. Cela peut également expliquer pourquoi les efforts de réglage DBA ne fonctionnent pas.

Requêtes forçant des indications de commande - 2153 instances d'indication de commande ont été enregistrées depuis le redémarrage. Cela signifie que les requêtes gèrent l'optimiseur SQL Server, et si elles ne savent pas ce qu'elles font, cela peut causer plus de tort que de bien. Cela peut également expliquer pourquoi les efforts de réglage DBA ne fonctionnent pas.

Priorité 170: Configuration des fichiers :

Base de données système sur le lecteur C

master - La base de données master possède un fichier sur le lecteur C. Placer des bases de données système sur le lecteur C risque de faire planter le serveur lorsqu'il manque d'espace.

model - La base de données model contient un fichier sur le lecteur C. Placer des bases de données système sur le lecteur C risque de faire planter le serveur lorsqu'il manque d'espace.

msdb - La base de données msdb contient un fichier sur le lecteur C. Placer des bases de données système sur le lecteur C risque de faire planter le serveur lorsqu'il manque d'espace.

Priorité 200: Information :

Travaux d'agent démarrant simultanément - Plusieurs travaux d'agent SQL Server sont configurés pour démarrer simultanément. Pour des listes d'horaires détaillées, consultez la requête dans l'URL.

Tables dans la base de données master master - La table CommandLog dans la base de données master a été créée par les utilisateurs finaux le 30 juillet 2017 17:22. Les tables de la base de données master peuvent ne pas être restaurées en cas de sinistre.

TraceFlag On

L'indicateur de trace 1118 est activé globalement.

L'indicateur de trace 1222 est activé globalement.

L'indicateur de trace 2371 est activé globalement.

Priorité 200: Configuration du serveur non par défaut :

Agent XPs - Cette option sp_configure a été modifiée. Sa valeur par défaut est 0 et elle a été définie sur 1.

backup checksum default - Cette option sp_configure a été modifiée. Sa valeur par défaut est 0 et elle a été définie sur 1.

sauvegarde compression par défaut - Cette option sp_configure a été modifiée. Sa valeur par défaut est 0 et elle a été définie sur 1.

seuil de coût pour le parallélisme - Cette option sp_configure a été modifiée. Sa valeur par défaut est 5 et elle a été définie sur 48.

degré maximum de parallélisme - Cette option sp_configure a été modifiée. Sa valeur par défaut est 0 et elle a été définie sur 12.

max server memory (MB) - Cette option sp_configure a été modifiée. Sa valeur par défaut est 2147483647 et elle a été définie sur 128000.

optimiser pour les charges de travail ad hoc - Cette option sp_configure a été modifiée. Sa valeur par défaut est 0 et elle a été définie sur 1.

show advanced options - Cette option sp_configure a été modifiée. Sa valeur par défaut est 0 et elle a été définie sur 1.

xp_cmdshell - Cette option sp_configure a été modifiée. Sa valeur par défaut est 0 et elle a été définie sur 1.

Priorité 200: Fiabilité :

Procédures stockées étendues dans Master

master - La procédure stockée étendue [sqbdata] se trouve dans la base de données master. CLR est peut-être en cours d'utilisation et la base de données principale doit désormais faire partie de votre planification de sauvegarde/restauration.

master - La procédure stockée étendue [sqbdir] se trouve dans la base de données master. CLR est peut-être en cours d'utilisation et la base de données principale doit désormais faire partie de votre planification de sauvegarde/restauration.

master - La procédure stockée étendue [sqbmemory] se trouve dans la base de données master. CLR est peut-être en cours d'utilisation et la base de données principale doit désormais faire partie de votre planification de sauvegarde/restauration.

master - La procédure stockée étendue [sqbstatus] se trouve dans la base de données master. CLR est peut-être en cours d'utilisation et la base de données principale doit désormais faire partie de votre planification de sauvegarde/restauration.

master - La procédure stockée étendue [sqbtest] se trouve dans la base de données master. CLR est peut-être en cours d'utilisation et la base de données principale doit désormais faire partie de votre planification de sauvegarde/restauration.

master - La procédure stockée étendue [sqbtestcancel] se trouve dans la base de données master. CLR est peut-être en cours d'utilisation et la base de données principale doit désormais faire partie de votre planification de sauvegarde/restauration.

master - La procédure stockée étendue [sqbteststatus] se trouve dans la base de données master. CLR est peut-être en cours d'utilisation et la base de données principale doit désormais faire partie de votre planification de sauvegarde/restauration.

master - La procédure stockée étendue [sqbutility] se trouve dans la base de données master. CLR est peut-être en cours d'utilisation et la base de données principale doit désormais faire partie de votre planification de sauvegarde/restauration.

master - La procédure stockée étendue [sqlbackup] se trouve dans la base de données master. CLR est peut-être en cours d'utilisation et la base de données principale doit désormais faire partie de votre planification de sauvegarde/restauration.

Priorité 210: Configuration de base de données non par défaut :

Lire l'isolement de l'instantané validé activé - Ce paramètre de base de données n'est pas la valeur par défaut.

RedGate

RedGateMonitor

Snapshot Isolation Enabled - Ce paramètre de base de données n'est pas la valeur par défaut.

RedGate

RedGateMonitor

Priorité 240: Statistiques d'attente :

1 - SOS_SCHEDULER_YIELD - 1770,8 heures d'attente, 115,9 minutes de temps d'attente moyen par heure, 100,0% d'attente de signal, 1419212079 tâches en attente, 4,5 ms de temps d'attente moyen.

Priorité 250: Information :

SQL Server s'exécute sous un compte de service NT - j'exécute en tant que NT Service\MSSQLSERVER. J'aimerais avoir un compte de service Active Directory à la place.

Priorité 250: Informations sur le serveur :

Contenu de la trace par défaut - La trace par défaut contient 36 heures de données entre le 14 avril 2018 23h21 et le 16 avril 2018 11h13. Les fichiers de trace par défaut se trouvent dans: C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Log

Drive C Space - 196816.00MB gratuit sur le lecteur C

Drive D Space - 894823,00 Mo gratuits sur le lecteur E

Espace disque L - 1361367,00 Mo gratuits sur le lecteur F

Espace Drive T - 114441,00 Mo gratuits sur le lecteur G

Matériel - Processeurs logiques: 12. Mémoire physique: 144 Go.

Matériel - NUMA Config

Noeud: 0 État: ONLINE Planificateurs en ligne: 4 Planificateurs hors ligne: 2 Groupe de processeurs: 0 Noeud mémoire: 0 Mémoire VAS réservée Go: 186

Nœud: 1 État: HORS LIGNE Planificateurs en ligne: 0 Planificateurs hors ligne: 6 Groupe de processeurs: 0 Nœud de mémoire: 0 Mémoire VAS réservée GB: 186

Initialisation instantanée des fichiers activée - Le compte de service dispose de l'autorisation Effectuer des tâches de maintenance de volume.

Plan d'alimentation - Votre serveur possède des processeurs à 2,60 GHz et est en mode d'alimentation équilibrée - Euh ... vous voulez que vos processeurs fonctionnent à pleine vitesse, non?

Dernier redémarrage du serveur - 9 mars 2018 07:27

Nom du serveur - [expurgé]

Prestations de service

Service: SQL Server (MSSQLSERVER) s'exécute sous le compte de service NT Service\MSSQLSERVER. Dernière mise en service: 9 mars 2018 07:27. Type de démarrage: automatique, en cours d'exécution.

Service: l'Agent SQL Server (MSSQLSERVER) s'exécute sous le compte de service LocalSystem. Dernier démarrage: non affiché. Type de démarrage: automatique, en cours d'exécution.

Dernier redémarrage de SQL Server - 9 mars 2018 06:27

Service SQL Server - Version: 13.0.4466.4. Niveau de patch: SP1. Mise à jour cumulative: CU7. Édition: Édition Standard (64 bits). Groupes de disponibilité activés: 0. État du gestionnaire de groupes de disponibilité: 2

Serveur virtuel - Type: (HYPERVISOR)

Version Windows - Vous utilisez une version assez moderne de Windows: ère Server 2012R2, version 6.3

Priorité 254: Rundate :

Journal du capitaine: starder quelque chose et quelque chose ...

Brent Ozar · Accepted Answer

Je parie que vous avez configuré les processeurs virtuels de manière à ce que certains des nœuds de processeur et/ou des nœuds de mémoire soient hors ligne.

Téléchargez sp_Blitz (avertissement: je suis l'un des auteurs de ce script open source gratuit) et exécutez-le:

sp_Blitz @CheckServerInfo = 1;

Recherchez les avertissements concernant les nœuds de CPU et/ou de mémoire hors ligne. SQL Server Standard Edition ne voit que les 4 premiers sockets CPU, et vous avez peut-être configuré le VM comme quelque chose comme 6 CPU dual-core. Il finira par rencontrer un problème similaire à comment les limites de 20 cœurs de Enterprise Edition limitent la quantité de mémoire que vous pouvez voir .

Si vous souhaitez partager la sortie de sp_Blitz ici, vous pouvez l'exécuter comme ceci pour sortir vers Markdown, que vous pouvez ensuite copier/coller dans votre question:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

Mise à jour 2018/04/16 - confirmée. Vous avez attaché la sortie sp_Blitz (merci pour cela!) Et cela montre en effet que vous avez des noeuds CPU et mémoire hors ligne. Celui qui a construit le VM l'a configuré comme 12 CPU monocœur, donc SQL Server Standard Edition ne voit que les 4 premiers sockets (cœurs) et la mémoire qui leur est attachée.

Pour le corriger, arrêtez la machine virtuelle, configurez-la en tant que machine virtuelle à 2 sockets et 6 cœurs, puis SQL Server Standard Edition verra tous les cœurs et la mémoire. Cela réduira également vos attentes SOS_SCHEDULER_YIELD - en ce moment, votre SQL Server martèle les 4 premiers cœurs, mais c'est tout. Après ce correctif, il pourra fonctionner sur les 12 cœurs.

PicoDeGallo · Answer

Comme addendum à plan d'action de Brent Ozar , je voulais partager les résultats. Comme l'a noté Brent, au sein de VMware, nous avions mal configuré la machine virtuelle avec 12 processeurs monocœur. Cela a eu pour conséquence que les 8 cœurs restants étaient inaccessibles par SQL Server et, par conséquent, ont entraîné le problème de mémoire décrit dans ma question d'origine. Nous avons placé nos services en mode maintenance hier soir afin de reconfigurer le VM de manière appropriée. Non seulement nous voyons la mémoire remonter de façon normale, mais comme Brent l'a également laissé entendre, le nombre d'attentes a chuté de façon exponentielle et nos performances globales de SQL Server sont montées en flèche. Les configurations vNUMA sont maintenant de petits composants heureux qui découpent nos charges de travail.

Pour ceux qui pourraient utiliser VMware vSphere 6.5, les brèves étapes pour terminer l'élément d'action décrit par Brent sont les suivantes.

Connectez-vous à vSphere Web Client pour votre cluster VMware et accédez à la machine virtuelle qui héberge SQL Server. Votre VM doit être hors ligne afin d'ajuster les configurations CPU et mémoire.
Dans le volet principal, accédez à Configure > VM hardware, cliquez sur le bouton Edit dans le coin supérieur droit. Vous allez ouvrir un menu contextuel qui a Edit Settings. Pour référence, l'image ci-dessous est la configuration incorrecte . Notez que j'ai Cores per Socket mis à 1. Compte tenu des limites de SQL Server Standard Edition, il s'agit d'une mauvaise configuration.
La solution est aussi simple que d'ajuster le Cores per Socket valeur. Dans notre cas, nous l'avons défini sur 6 pour que nous ayons 2 Sockets. Cela permet à SQL Server d'utiliser les 12 processeurs.

Remarque importante: ne définissez pas la valeur à l'endroit où le Number of Cores ou Sockets serait un nombre impair. NUMA aime l'équilibre et, en règle générale, doit être divisible par 2. Par exemple, une configuration de 4 cœurs à 3 sockets serait déséquilibrée. En fait, si vous deviez exécuter sp_Blitz avec ce type de configuration, il lancerait un avertissement à ce sujet.

La section 3.3 dans Architecture de Microsoft SQL Server sur VMware vSphere (avertissement PDF) décrit cela en détail. Les pratiques décrites dans le livre blanc s'appliquent à la plupart des virtualisations sur site de SQL Server.

Voici quelques ressources supplémentaires que j'ai compilées à travers mes recherches après le post de Brent:

Je terminerai sur une capture de RedGate SQL Monitor au cours des dernières 24 heures. Le principal point à noter est l'utilisation du processeur et le nombre d'attente - pendant nos heures de pointe hier, nous avons connu une utilisation intensive du processeur et des contentions d'attente. Après cette simple correction, nous avons décuplé nos performances. Même nos E/S disque ont considérablement diminué. Il s'agit d'un paramètre apparemment facilement ignoré qui peut améliorer les performances virtuelles d'un ordre de grandeur. Au moins, il a été ignoré par nos ingénieurs et un moment complet d'oh.