Lorsque ESX 5 et Hyper-V dans Windows Server 2012 ont publié et modifié les limitations qui existaient auparavant pour les tailles de machines virtuelles, j'ai su presque immédiatement que nous verrions davantage de charges de travail SQL Server à grande échelle commencer à être virtualisées. J'ai travaillé avec un certain nombre de clients au cours de l'année dernière qui virtualisaient des serveurs SQL de 16 à 32 cœurs pour diverses raisons, des stratégies de reprise après sinistre simplifiées qui correspondaient au reste de l'entreprise, à la consolidation et à la réduction du coût total de possession sur du matériel plus récent. plates-formes. L'une des raisons du changement d'évolutivité avec ESX 5+ était l'introduction de NUMA virtuel (vNUMA) pour les invités étendus qui dépassaient la taille d'un nœud NUMA matériel individuel. Avec vNUMA, la machine virtuelle invitée est optimisée pour correspondre à la topologie matérielle NUMA, permettant au système d'exploitation invité et à toutes les applications compatibles NUMA, telles que SQL Server, qui s'exécutent sur la machine virtuelle de tirer parti des optimisations de performances NUMA, comme s'ils étaient s'exécutant sur un serveur physique.
Dans VMware, une topologie vNUMA est disponible sur la version matérielle 8 ou supérieure et est configurée par défaut si le nombre de vCPU est supérieur à huit pour l'invité. Il est également possible de configurer manuellement la topologie vNUMA pour une machine virtuelle à l'aide d'options de configuration avancées, ce qui peut être utile pour les machines virtuelles qui ont plus de mémoire allouée qu'un nœud NUMA physique ne peut en fournir, mais qui utilisent toujours huit vCPU ou moins. Pour la plupart, les paramètres de configuration par défaut fonctionnent pour la majorité des machines virtuelles que j'ai examinées au cours des dernières années, mais il existe certains scénarios où la topologie vNUMA par défaut n'est pas idéale et la configuration manuelle peut offrir certains avantages. Récemment, je travaillais avec un client avec un certain nombre de 32 machines virtuelles vCPU SQL Server avec 512 Go de RAM allouées, effectuant des réglages de performances où la topologie vNUMA n'était pas proche de ce qui était attendu.
Les serveurs hôtes de VM dans cet environnement étaient constitués de quatre processeurs socket E5-4650 à huit cœurs et de 1 To de RAM, chacun dédié à une seule VM SQL Server dans le cadre d'opérations typiques, mais avec une capacité disponible pour soutenir deux VM en cas de panne. Avec cette disposition matérielle, il y a quatre nœuds NUMA, un par socket, et la configuration de machine virtuelle attendue aurait également 4 nœuds vNUMA qui lui seraient présentés pour une configuration à 32 vCPU. Cependant, ce que j'ai trouvé en regardant les DMV dans SQL Server, c'est que ce n'était pas le cas :
Figure 1 – Configuration vNUMA incorrecte
Comme vous pouvez probablement le voir dans l'image, quelque chose ne va vraiment pas avec la configuration NUMA sur ce serveur. Il y a quatre nœuds de mémoire dans SQLOS et un seul nœud CPU, avec tous les vCPU qui y sont alloués. Pour être parfaitement honnête, cela m'a époustouflé quand je l'ai vu car cela allait à l'encontre de tout ce que je savais sur la façon dont SQLOS configurait les structures internes au démarrage de l'instance. Après avoir fouillé un peu dans les fichiers ErrorLog, Performance Monitor et Windows Task Manager, j'ai téléchargé une copie de CoreInfo à partir de SysInternals et j'ai jeté un coup d'œil à la disposition NUMA signalée à Windows.
Carte processeur logique vers socket :********———————— Socket 0
——–********—————- Socket 1
—————-********——– Prise 2
————————******** Prise 3
Mappage du processeur logique vers le nœud NUMA :
******************************** Nœud NUMA 0
La sortie CoreInfo a confirmé que la VM présente les 32 vCPU sous 4 sockets différents, mais a ensuite regroupé les 32 vCPU dans NUMA Node 0. En regardant les compteurs de performances Windows Server 2012 sur la VM, j'ai pu voir dans le groupe de compteurs NUMA Node Memory, que 4 nœuds de mémoire NUMA ont été présentés au système d'exploitation avec la mémoire uniformément répartie sur les nœuds. Tout cela correspondait à ce que je voyais dans SQLOS, et je pouvais également dire à partir des entrées ERRORLOG de démarrage que le masque de processeur pour le nœud masquait tous les processeurs disponibles dans le nœud de processeur 0, mais quatre grands allocateurs de page étaient en cours de création, un pour chaque nœud de mémoire.
22/09/2013 05:03:37,Serveur,Inconnu,Configuration du nœud :nœud 0 :Masque CPU :0x00000000ffffffff:0 Masque CPU actif :0x00000000ffffffff:0. Ce message fournit une description de la configuration NUMA pour cet ordinateur. Il s'agit d'un message d'information uniquement. Aucune action de l'utilisateur n'est requise.22/09/2013 05:03:37,Serveur,Inconnu,Cette instance de SQL Server a signalé pour la dernière fois l'utilisation d'un ID de processus de 1596 le 22/09/2013 05:00:25 (local) 22/09/2013 10:00:25 AM (UTC). Il s'agit d'un message d'information uniquement; aucune action de l'utilisateur n'est requise.
09/22/2013 05:03:35,Server,Unknown,Large Page allouée :32 Mo
09/22/2013 05:03:35,Server,Unknown,Large Page allouée :32 Mo
22/09/2013 05:03:35,Serveur,Inconnu,Grande page allouée :32Mo
22/09/2013 05:03:35,Serveur,Inconnu,Grande page allouée :32 Mo
22/09/2013 05:03:35,Serveur,Inconnu,Utilisation des pages verrouillées dans le gestionnaire de mémoire.
22/09/2013 05:03:35,Serveur,Inconnu,Détecté 524287 Mo de RAM. Ceci est un message informatif; aucune action de l'utilisateur n'est requise.
22/09/2013 05:03:35,Serveur,Inconnu,SQL Server démarre à la base de priorité normale (=7). Il s'agit d'un message d'information uniquement. Aucune action de l'utilisateur n'est requise.
22/09/2013 05:03:35,Serveur,Inconnu,SQL Server a détecté 4 sockets avec 8 cœurs par socket et 8 processeurs logiques par socket 32 processeurs logiques au total ; utilisant 32 processeurs logiques basés sur les licences SQL Server. Ceci est un message informatif; Aucune action de l'utilisateur n'est requise.
À ce stade, j'étais sûr qu'il s'agissait de quelque chose lié à la configuration de la machine virtuelle, mais je ne pouvais pas identifier précisément le problème, car je n'avais jamais vu ce comportement sur d'autres machines virtuelles SQL Server larges que j'avais assistées. clients sur VMware ESX 5+ autrefois. Après avoir apporté quelques modifications à la configuration d'un serveur de VM de test disponible, seul aucun d'entre eux n'a corrigé la configuration vNUMA présentée dans la VM. Après avoir appelé le support VMware, il nous a été demandé de désactiver la fonction de connexion à chaud vCPU pour la machine virtuelle de test et de voir si cela corrigeait le problème. Avec hotplug désactivé sur la VM, la sortie CoreInfo a confirmé que le mappage vNUMA des processeurs pour la VM était désormais correct :
Carte processeur logique vers socket :********———————— Socket 0
——–********—————- Socket 1
—————-********——– Prise 2
————————******** Prise 3
Mappage du processeur logique vers le nœud NUMA :
********———————— Nœud NUMA 0
——–********————— - Nœud NUMA 1
—————-********——– Nœud NUMA 2
————————******** Nœud NUMA 3
Ce comportement est en fait documenté dans l'article VMware KB, (vNUMA est désactivé si le hotplug VCPU est activé), d'octobre 2013. Il s'agissait de la première machine virtuelle large pour SQL Server avec laquelle j'avais travaillé où le hotplug vCPU était activé, et c'est pas une configuration typique à laquelle je m'attendrais pour une machine virtuelle à 32 vCPU, mais faisait partie du modèle standard utilisé par le client et affectait leur serveur SQL.
Effets de la désactivation de vNUMA
La désactivation de vNUMA comme celle-ci pourrait avoir un certain nombre d'effets sur une charge de travail, mais il existe deux problèmes spécifiques qui pourraient affecter spécifiquement SQL Server dans ce type de configuration. La première est que le serveur pourrait avoir des problèmes avec les accumulations d'attente CMEMTHREAD car 32 vCPU sont alloués à un seul nœud NUMA, et le partitionnement par défaut pour les objets mémoire dans SQLOS est par nœud NUMA. Ce problème spécifique a été documenté par Bob Dorr dans le groupe CSS de Microsoft sur leur article de blog SQL Server 2008/2008 R2 sur des machines plus récentes avec plus de 8 processeurs présentés par nœud NUMA peut nécessiter l'indicateur de trace 8048. Dans le cadre de l'examen des statistiques d'attente sur la machine virtuelle avec le client, j'ai noté que CMEMTHREAD était leur deuxième type d'attente le plus élevé, ce qui est anormal d'après mon expérience et m'a amené à examiner la configuration SQLOS NUMA illustrée à la figure 1 ci-dessus. Dans ce cas, l'indicateur de trace n'est pas la solution, la suppression du hotplug vCPU de la configuration de la machine virtuelle résout le problème.
Le deuxième problème qui affecterait spécifiquement SQL Server si vous utilisez une version non corrigée est associé à la gestion de la mémoire NUMA dans SQLOS et à la façon dont SQLOS suit et gère les pages Away pendant la phase initiale de montée en puissance de la mémoire après le démarrage de l'instance. Ce comportement a été documenté par Bob Dorr dans le billet de blog CSS, How It Works:SQL Server (NUMA Local, Foreign and Away Memory Blocks). Essentiellement, lorsque SQLOS tente une allocation de mémoire de nœud local lors de la montée en puissance initiale, si l'adresse mémoire renvoyée provient d'un nœud de mémoire différent, la page est ajoutée à la liste Away, et une autre tentative d'allocation de mémoire locale se produit, et le processus se répète jusqu'à ce que une allocation de mémoire locale réussit ou la cible de mémoire du serveur est atteinte. Étant donné que les trois quarts de la mémoire de nos instances existent sur des nœuds NUMA sans aucun planificateur, cela crée une condition de performances dégradées lors de la montée en puissance initiale de la mémoire pour l'instance. Les mises à jour récentes ont modifié le comportement de l'allocation de mémoire lors de la montée en puissance initiale pour ne tenter l'allocation de mémoire locale qu'un nombre fixe de fois (le nombre spécifique n'est pas documenté) avant d'utiliser la mémoire étrangère pour continuer le traitement. Ces mises à jour sont documentées dans KB #2819662, CORRECTIF :Problèmes de performances de SQL Server dans les environnements NUMA.
Résumé
Pour les machines virtuelles étendues, définies comme ayant plus de 8 vCPU, il est souhaitable que vNUMA soit transmis à la machine virtuelle par l'hyperviseur pour permettre à Windows et SQL Server d'exploiter les optimisations NUMA dans leur base de code. Par conséquent, ces machines virtuelles plus larges ne doivent pas avoir la configuration hotplug vCPU activée, car cela est incompatible avec vNUMA et peut entraîner une dégradation des performances de SQL Server lorsqu'il est virtualisé.
