Lors du dépannage des problèmes de performances du processeur sur les serveurs SQL virtualisés exécutés sur VMware, l'une des premières choses que je fais est de vérifier que la configuration de la machine virtuelle n'est pas un facteur contributif au problème de performances. Là où un serveur physique dispose de 100 % des ressources disponibles dédiées au système d'exploitation, ce n'est pas le cas d'une machine virtuelle. Par conséquent, examiner quelques éléments de base à l'avance élimine le dépannage du mauvais problème et la perte de temps. Dans le passé, j'ai blogué sur l'importance pour les DBA d'avoir un accès en lecture seule à Virtual Center for VMware pour le dépannage de base des problèmes de performances. Cependant, même sans accès au centre virtuel, il est toujours possible de trouver des informations de base à l'intérieur de Windows qui pourraient entraîner des problèmes potentiels au niveau de l'hôte qui affectent les performances.
Chaque machine virtuelle VMware possède deux groupes de compteurs de performances dans Windows qui sont ajoutés lorsque les outils VMware sont installés sur l'invité; Processeur VM et mémoire VM. Ces compteurs de performances sont l'une des premières choses que je regarde chaque fois que je travaille avec une machine virtuelle sur VMware, car ils vous donnent un aperçu des ressources que la machine virtuelle reçoit de l'hyperviseur. Le groupe VM Processor a les compteurs suivants :
- % de temps processeur
- Vitesse effective de la machine virtuelle en MHz
- Vitesse du processeur hôte en MHz
- Limite en MHz
- Réservation en MHz
- Partages
Sur un invité VM qui affiche un processeur\% de temps processeur élevé dans le gestionnaire de tâches ou perfmon, la vérification des compteurs du processeur VM donnera un compte rendu précis des allocations de ressources réelles que l'invité VM reçoit. Si la vitesse du processeur hôte en MHz est de 3000 et que l'invité dispose de 8 processeurs virtuels, la vitesse effective maximale de la VM est de 24000 MHz et le compteur Effective VM Speed in MHz indiquera si la VM obtient réellement les ressources de l'hôte. Habituellement, lorsque c'est le cas, vous devrez commencer à examiner les informations au niveau de l'hôte pour diagnostiquer plus avant la cause première du problème. Mais lors d'un engagement récent avec un client, cela ne s'est pas avéré être le cas.
Dans ce cas, la machine virtuelle cliente correspondait à la configuration décrite ci-dessus et avait une vitesse effective maximale de 24 000 MHz, mais le compteur de vitesse effective de la machine virtuelle en MHz n'atteignait en moyenne qu'environ 6 900 MHz avec le temps du processeur de pourcentage Windows de la machine virtuelle fixé à près de 100 %. Regarder juste en dessous du compteur Effective VM Speed in MHz a révélé la cause du problème :la limite en MHz était de 7000, ce qui signifie que la VM avait un plafond configuré d'utilisation du processeur à 7000 MHz dans ESX, donc elle était constamment limitée par l'hyperviseur sous charge.
L'explication en était que cette VM particulière avait été utilisée à des fins de test dans une preuve de concept et était à l'origine colocalisée sur un hôte VM occupé ; les administrateurs de VM ne voulaient pas qu'une charge de travail inconnue cause des problèmes de performances sur cet hôte. Ainsi, pour s'assurer que cela n'aurait pas d'impact négatif sur les charges de travail de production réelles sur l'hôte pendant le POC, il a été limité pour n'autoriser que 7000 MHz de CPU ou l'équivalent de 2 1/3 cœurs physiques sur l'hôte. En fin de compte, la suppression de la limite de CPU VM dans ESX a éliminé les problèmes de CPU élevés dans Windows, et les problèmes de performances rencontrés par le client ont disparu.
Le groupe de compteurs de mémoire VM est tout aussi important que le groupe de processeurs VM pour identifier les problèmes de performances potentiels pour SQL Server. Le groupe de compteurs de mémoire VM contient les compteurs suivants :
- Mémoire active en Mo
- Mémoire gonflée en Mo
- Limite de mémoire en Mo
- Mémoire mappée en Mo
- Surcharge mémoire en Mo
- Réservation de mémoire en Mo
- Mémoire partagée en Mo
- Mémoire partagée enregistrée en Mo
- Partages de mémoire
- Mémoire échangée en Mo
- Mémoire utilisée en Mo
Parmi ces compteurs, ceux que j'examine spécifiquement sont la mémoire gonflée en Mo et la mémoire échangée en Mo, qui doivent toutes deux être nulles pour les charges de travail SQL Server. Le compteur Mémoire gonflée en Mo indique la quantité de mémoire récupérée de la machine virtuelle invitée par le pilote de gonflage en raison d'une surcharge de mémoire sur l'hôte, ce qui obligera SQL Server à réduire l'utilisation de la mémoire pour répondre à la pression de la mémoire dans Windows causée par le pilote de gonflage. gonfler pour retirer de la mémoire de la machine virtuelle. Le compteur Mémoire échangée en Mo suit la quantité de mémoire paginée sur le disque par l'hyperviseur hôte en raison d'une surcharge de mémoire sur l'hôte qui n'a pas pu être résolue en gonflant les invités VM avec le pilote de gonflage. Le guide des meilleures pratiques de VMware pour SQL Server recommande d'utiliser des réservations pour garantir que SQL Server ne soit pas gonflé ou paginé pour des raisons de performances, mais de nombreux administrateurs de machines virtuelles hésitent à définir des réservations statiques car cela réduit la flexibilité environnementale.
Des outils de surveillance, comme SentryOne V Sentry, peuvent également vous aider. Considérez le cas où vous n'avez peut-être pas un accès direct à vCenter, mais quelqu'un peut configurer une surveillance en votre nom. Vous pouvez désormais obtenir une excellente visualisation et un aperçu des problèmes de processeur, de mémoire et même de disque - au niveau de l'invité et de l'hôte - et de tout l'historique qui l'accompagne également. Sur le tableau de bord ci-dessous, vous pouvez voir les métriques de l'hôte sur la gauche (y compris les pannes du processeur pour le co-stop et le temps de disponibilité) et les métriques de l'invité sur la droite :
Pour essayer cette fonctionnalité et d'autres fonctionnalités de SentryOne, vous pouvez télécharger une version d'essai gratuite.
Conclusion
Lors du dépannage de problèmes de performances sur des serveurs SQL virtualisés sur VMware, il est important d'examiner le problème d'un point de vue holistique au lieu d'effectuer un dépannage « réflexe » en utilisant uniquement des informations limitées. Les compteurs spécifiques à VMware dans Performance Monitor peuvent être un excellent moyen de vérifier rapidement que la machine virtuelle obtient les allocations de ressources de base de l'hôte, avant de prendre d'autres mesures pour résoudre le problème.
