La consommation «totale du serveur» de SQL Server stagne pendant des mois avec 64 Go + plus disponibles

J'ai rencontré un problème étrange dans lequel SQL Server 2016 Édition Standard 64 bits semble s'être limité à exactement la moitié de la mémoire totale allouée (64 Go sur 128 Go).

La sortie de @@VERSIONest:

Microsoft SQL Server 2016 (SP1-CU7-GDR) (KB4057119) - 13.0.4466.4 (X64) 22 déc. 2017 11:25:00 Droits d'auteur (c) Microsoft Corporation Édition Standard (64 bits) sur Windows Server 2012 R2 Datacenter 6.3 ( Build 9600:) (Hypervisor)

La sortie de sys.dm_os_process_memoryest:

Quand je demande sys.dm_os_performance_counters, je vois que le Target Server Memory (KB)est à 131072000et Total Server Memory (KB)est à peu près la moitié de cela à 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é sa nécessité d'allouer de la mémoire supplémentaire pour lui-même.

Cependant, il est bloqué à ~ 64 Go depuis plus de 2 mois. Au cours de cette période, nous avons effectué un nombre considérable 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 disposons de 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 à minuit et commence les sauvegardes du journal des transactions du lundi au vendredi de 6h à 20h toutes les 15 minutes. Le débit global de ces bases de données est relativement faible, mais je suis sceptique face à un problème, étant donné que SQL Server ne s'est pas glissé vers le marché.Target Server Memory naturellement via de nouveaux ajouts à la base de données, des exécutions de requêtes normales, ainsi que des pipelines ETL gourmands en mémoire qui ont été exécutés.

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

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

Ce serveur est entièrement dédié à l'instance SQL Server uniquement. Par conséquent, aucune autre application ni aucun autre service ne peut utiliser de la mémoire et risque de consommer de la mémoire.

J'utilise RedGate SQL Monitor pour l'analyse, et voici un historique des 18 derniers jours de Total Server Memory. Comme vous pouvez le constater, l'utilisation de la mémoire est restée totalement stagnante, à l'exception d'une simple hausse d'environ 300 Mo au début d'avril.

Quelle pourrait en être la cause? Que puis-je examiner de plus près afin de déterminer pourquoi SQL Server ne veut pas utiliser les 64 Go supplémentaires de mémoire allouée?

La sortie de l'exécution sp_Blitz:

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

Priorité 50: Performance :

• Planificateurs d'UC en mode hors connexion - Certains cœurs d'UC ne sont pas accessibles à SQL Server en raison de problèmes de masquage d'affinité ou de licence.

• Nœuds de mémoire hors connexion - 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é :

• Remote DAC Disabled - L’accès à distance à la connexion Dedicated Admin Connection (DAC) n’est pas activé. Le DAC peut faciliter le dépannage à distance lorsque SQL Server ne répond pas.

Priorité 100: Performance :

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

• Déclencheurs de serveur activés

  • Le déclencheur de serveur [RG_SQLLighthouse_DDLTrigger] est activé. Assurez-vous de bien comprendre ce que fait cet élément déclencheur: moins il y a de travail, mieux c'est.

  • Le déclencheur de serveur [SSMSRemoteBlock] est activé. Assurez-vous de bien comprendre ce que fait cet élément déclencheur: moins il y a de travail, mieux c'est.

Priorité 150: Performance :

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

• Requêtes indiquant des ordres de commande forcés - 2 153 instances de conseil des ordres ont été enregistrées depuis le redémarrage. Cela signifie que les requêtes dirigent l'optimiseur SQL Server, et si elles ne savent pas ce qu'elles font, cela peut causer plus de tort que de mal. Cela peut également expliquer pourquoi les efforts de réglage DBA ne fonctionnent pas.

Priorité 170: Configuration du fichier :

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

  • master - La base de données master contient un fichier sur le lecteur C. Le fait de placer les bases de données système sur le lecteur C présente le risque de planter le serveur s’il manque d’espace.

  • model - La base de données model contient un fichier sur le lecteur C. Le fait de placer les bases de données système sur le lecteur C présente le risque de planter le serveur s’il manque d’espace.

  • msdb - La base de données msdb contient un fichier sur le lecteur C. Le fait de placer les bases de données système sur le lecteur C présente le risque de planter le serveur s’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 de programme détaillées, voir la requête dans l'URL.

• Tables du maître de la base de données principale - La table CommandLog de la base de données principale a été créée par les utilisateurs le 30 juil. 2017 17h22. 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 autre que celle par défaut :

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

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

• backup compression default - Cette option sp_configure a été modifiée. Sa valeur par défaut est 0 et il a été défini 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 il a été défini sur 48.

• max degree of parallelism - Cette option sp_configure a été modifiée. Sa valeur par défaut est 0 et il a été défini sur 12.

• max server memory (MB) - Cette option sp_configure a été modifiée. Sa valeur par défaut est 2147483647 et il a été défini 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 il a été défini sur 1.

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

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

Priorité 200: Fiabilité :

• Procédures stockées étendues en maître

• master - La procédure stockée étendue [sqbdata] se trouve dans la base de données master. Le CLR est peut-être utilisé et la base de données master doit maintenant 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. Le CLR est peut-être utilisé et la base de données master doit maintenant 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. Le CLR est peut-être utilisé et la base de données master doit maintenant 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. Le CLR est peut-être utilisé et la base de données master doit maintenant 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. Le CLR est peut-être utilisé et la base de données master doit maintenant 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. Le CLR est peut-être utilisé et la base de données master doit maintenant 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. Le CLR est peut-être utilisé et la base de données master doit maintenant 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. Le CLR est peut-être utilisé et la base de données master doit maintenant 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. Le CLR est peut-être utilisé et la base de données master doit maintenant faire partie de votre planification de sauvegarde / restauration.

Priorité 210: Configuration de la base de données autre que celle par défaut :

• Isolement instantané lu validé activé - Ce paramètre de base de données n'est pas le paramètre par défaut.

  • RedGate

  • RedGateMonitor

• Isolement d'instantané activé - Ce paramètre de base de données n'est pas le paramètre par défaut.

  • RedGate

  • RedGateMonitor

Priorité 240: Statistiques d'attente :

• 1 - SOS_SCHEDULER_YIELD - 1770,8 heures d’attente, temps d’attente moyen par heure, 100,0% d’attente du signal, 1419212079 tâches en attente, temps d’attente moyen de 4,5 ms.

Priorité 250: Information :

• SQL Server s'exécute sous un compte de service NT. J'exécute sous le nom Service NT \ MSSQLSERVER. Je souhaite 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 lecteur C

• Drive D Space - 894823.00Mo libre sur le lecteur E

• Drive L Space - 1361367.00Mo libre sur le lecteur F

• Drive T Space - 114441.00Mo libre sur le lecteur G

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

• Matériel - NUMA Config

  • Node: 0 Etat: ONLINE Ordonnanceurs en ligne: 4 Ordonnanceurs hors ligne: 2 Groupe de processeurs: 0 Noeud de mémoire: 0 Mémoire VAS réservée GB: 186

  • Node: 1 State: OFFLINE Planificateurs en ligne: 0 Planificateurs en mode hors connexion: 6 Groupe de processeurs: 0 Noeud de mémoire: 0 Mémoire VAS réservée GB: 186

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

• Plan d'alimentation - Votre serveur dispose de processeurs à 2,60 GHz et est en mode d'alimentation équilibrée - Euh ... vous voulez que vos processeurs fonctionnent à plein régime, n'est-ce pas?

• 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 heure de démarrage: 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. Dernière heure de démarrage: non indiquée .. Type de démarrage: Automatique, en cours d'exécution.

• Dernier redémarrage de SQL Server - 9 mars 2018 06h27

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

• Serveur virtuel - Type: (HYPERVISOR)

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

Priorité 254: Rundate :

• Journal de bord du capitaine: stardate quelque chose et quelque chose ...

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

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

sp_Blitz @CheckServerInfo = 1;

Recherchez les avertissements concernant le fait que des nœuds de processeur et / ou de mémoire sont hors ligne. SQL Server Standard Edition ne voit que les 4 premiers sockets de processeur et vous avez peut-être configuré la machine virtuelle comme quelque chose comme 6 processeurs double cœur. Cela posera un problème similaire à la façon dont les 20-core-limits d'Enterprise Edition limitent la quantité de mémoire visible .

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

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

Mise à jour 2018/04/16 - confirmé. Vous avez attaché la sortie sp_Blitz (merci pour cela!) Et cela montre bien que vous avez des noeuds de processeur et de mémoire hors ligne. Quiconque a construit la machine virtuelle l'a configurée en tant que 12 processeurs à un seul cœur. SQL Server Standard Edition ne voit donc que les 4 premiers sockets (cœurs) et la mémoire qui leur est associée.

Pour résoudre ce problème, 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 - pour le moment, votre serveur SQL martèle les 4 premiers cœurs, mais c'est tout. Après ce correctif, il sera capable de travailler sur les 12 cœurs.

En tant qu'additif au plan d'action de Brent Ozar , je voulais partager les résultats. Comme Brent l'a noté, dans VMware, nous avions mal configuré la machine virtuelle avec 12 processeurs à cœur unique. Les 8 cœurs restants étant ainsi inaccessibles par SQL Server, le problème de mémoire décrit dans ma question initiale en a résulté. Nous avons placé nos services en mode maintenance la nuit dernière afin de reconfigurer la machine virtuelle de manière appropriée. Non seulement nous voyons la mémoire s'accroître de manière normale, mais, comme Brent l'a également laissé entendre, le nombre d'attentes a diminué de manière exponentielle et nos performances globales pour SQL Server ont explosé. Les configurations vNUMA sont désormais de joyeux petits composants qui se répartissent dans nos charges de travail.

Pour ceux qui pourraient utiliser VMware vSphere 6.5, voici la brève étape pour mener à bien l'action décrite par Brent.

1. 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 pour pouvoir ajuster les configurations du processeur et de la mémoire.

2. Dans le volet principal, accédez à Configure > VM hardware, cliquez sur le Editbouton 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 je suis Cores per Socketréglé sur 1. Compte tenu des limitations de SQL Server Standard Edition, il s'agit d'une mauvaise configuration.

   

3. Le correctif est aussi simple que d'ajuster la Cores per Socketvaleur. Dans notre cas, nous l’avons réglé 6pour que nous ayons 2 Sockets. Cela permet à SQL Server d'utiliser les 12 processeurs.

   

Une remarque importante: ne définissez pas la valeur sur où le Number of Coresou le Socketsserait un nombre impair. NUMA aime l'équilibre et doit, en règle générale, être divisible par 2. Par exemple, une configuration de 4 cœurs sur 3 sockets serait déséquilibrée. En fait, si vous exécutiez sp_Blitzce type de configuration, cela lancerait un avertissement à ce sujet.

La section 3.3 de l’ architecture de Microsoft SQL Server sur VMware vSphere (avertissement PDF) décrit cette opération en détail. Les pratiques décrites dans le livre blanc s'appliquent à la plupart des solutions de virtualisation sur site de SQL Server.

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

• Virtualisation de bases de données volumineuses - Planification de la capacité du processeur VMware

• Machine virtuelle vCPU et vNUMA Rightsizing - Règles empiriques

• Découplage des cœurs par socket de la topologie NUMA virtuelle dans vSphere 6.5

Je terminerai par 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'attentes. Au cours de nos heures de pointe, hier, nous avons connu une utilisation intensive du processeur et des conflits d'attentes. Après cette correction simple, nous avons décuplé nos performances. Même notre disque I / O a considérablement réduit. C'est un paramètre apparemment facilement négligé qui peut améliorer les performances virtuelles d'un ordre de grandeur. Au moins, nos ingénieurs l’ont négligé et ont laissé un moment de détente complet .

En outre, selon MSDN , la norme SQL Server est limitée à 64 Go de RAM. Nous avons résolu ce problème en scindant la base de données en plusieurs instances, mais votre situation pourrait ne pas le permettre.

Hmm 2016 semble avoir une limite de 128 Go, mais la division d'instance pourrait être une option quand même.