• Synchroniser l'horloge depuis un serveur de temps
• Fonctionnement de la gestion de la mémoire (RAM)

3. Surveiller l'état CO-STOP du processeur (CPU)

Précédemment, avec VMware ESXi 2.x, pour qu'une machine virtuelle avec 4 vCPUs puisse être planifiée sur le processeur physique, il fallait attendre que 4 coeurs du processeur physique soient disponibles simultanément.
Ce qui retardait l'exécution pour ces machines virtuelles.

Depuis VMware ESXi 3.x, la planification est gérée par vCPU.
Ce qui signifie qu'une machine virtuelle avec 4 vCPUs peut être planifiée de façon fragmentée grâce au système de costop.
Par exemple, VMware ESXi pourra gérer l'exécution des 2 premiers vCPUs lorsque 2 coeurs du processeur physique sont disponibles, puis gère l'exécution des 2 autres coeurs (un par un si besoin), lorsque ceux-ci seront enfin disponibles.
L'hyperviseur VMware ESXi gèrera ensuite la synchronisation des résultats obtenus pour que le système d'exploitation invité pense que l'exécution s'est produite simultanément sur tous les coeurs (ce qui est requis en temps normal).

Ce système de costop permet de mieux utiliser le processeur physique et donc d'améliorer les performances de vos machines virtuelles.

L'exécution sur un coeur peut être dans différents états : RUN, READY, WAIT ou COSTOP.
Pour commencer, lorsqu'une exécution doit être effectuée sur un coeur, celle-ci peut se trouver dans un état RUN (si un coeur est disponible) ou en état "READY" (s'il ne l'est pas).
Si l'exécution est dans un état READY, elle passera ensuite en état RUN.
Ensuite, cette exécution peut repasser en READY ou en COSTOP. L'exécution en COSTOP sera ensuite démarrée (co-start) plus tard pour entrer dans un état READY.
Une exécution en état RUN entrera en état WAIT si elle bloque sur une ressource (car celle-ci n'est pas disponible pour le moment).

Source : The CPU Scheduler in VMware vSphere 5.1 (pages 4 et 5).

Dans l'exemple 2 (que vous verrez dans la suite de ce tutoriel), nous utiliserons 3 machines virtuelles avec respectivement : 1 vCPU, 2 vCPUs et 4 vCPUs.
Comme vous pouvez le voir, certains vCPUs seront en état RUN, car des coeurs du processeur physique sont disponibles actuellement. Mais d'autres vCPUs seront en état READY, voire WAIT, en fonction de la disponibilité des coeurs du processeur physique.
Ceci est évidemment un exemple et varie en fonction des machines virtuelles tournant actuellement, de leurs nombres de coeurs et de la disponibilité des coeurs du processeur physique.

Pour illustrer ce système de CO-STOP, voici le graphique d'exécution multithread (multi-coeurs / multi vCPUs) de la machine virtuelle possédant 4 coeurs.

La machine virtuelle exécute les instructions de 2 coeurs grâce aux 2 coeurs disponibles actuellement sur le processeur physique.
Puis, l'exécution du 3ème coeur qui était en état READY précédemment sera exécutée sur le coeur qui vient de se libérer un peu plus tard.
Par contre, le 4ème coeur était déjà utilisé par une VM et en READY pour le vCPU d'une 2ème VM.
Lorsque la 2ème VM (avec 2 coeurs dans ce cas-ci) exécute ses instructions sur ce coeur, notre VM avec 4 coeurs aura son vCPU en état READY sur ce coeur.
Une fois que la 2ème VM aura terminé son exécution sur ce coeur, notre machine virtuelle pourra l'utiliser (d'où l'état RUN).

La valeur de CO-STOP correspond au temps qui s'est écoulé entre la fin de l'exécution du coeur le plus rapide et la fin de l'exécution du coeur le plus lent.

Source : pages 8 et 9 du lien cité précédemment.

3.1. Pas de CO-STOP avec les machines virtuelles possédant 1 vCPU

Comme vous l'aurez compris, le CO-STOP ne se produit que lorsque vous utilisez des machines virtuelles avec plusieurs coeurs.
Voici donc un 1er exemple avec 3 machines virtuelles possédant un vCPU chacun où vous verrez que le CO-STOP restera à 0.

Note : à nouveau, nous avons lancé le logiciel de stress test CPU sur ces machines virtuelles pour qu'elles utilisent leur processeur invité (vCPU) à 100%.

Si vous regardez le graphique d'utilisation du processeur (CPU) de votre hôte, vous verrez que le processeur invité (vCPU) de vos machines virtuelles est utilisé à 100% et dans notre cas, le processeur physique de notre serveur est utilisé à environ 75% (étant donné que 3 coeurs sont utilisés sur 4).

Activez le SSH sur votre hôte VMware ESXi et lancez la commande "esxtop".

Plain Text

esxtop

Comme vous pouvez le voir, les machines virtuelles restent en état RUN tout le temps étant donné que les coeurs du processeur physique sont toujours disponibles pour celles-ci.
Il n'y a pas d'attente (READY / %RDY) pour la raison citée précédemment ni de CO-STOP (%CSTP) étant donné que nos machines virtuelles ne possèdent qu'un vCPU chacune.

Pour l'utilisation du processeur et l'état READY (Prêt), vous pouvez aussi le voir dans le graphique de performance de votre machine virtuelle.
Mais la valeur du CO-STOP n'apparait pas ici.

3.2. Apparition du CO-STOP avec les machines virtuelles possédant plusieurs vCPUs

Pour ce 2ème exemple, nous allons utiliser 3 machines virtuelles avec respectivement : 1 vCPU, 2 vCPUs et 4 vCPUs.
Ce qui correspond aux graphiques présentés au début de l'étape 3 de ce tutoriel.

La VM 1 possède 1 vCPU.

La VM 2 possède 2 vCPUs.

La VM 3 possède 4 vCPUs.

Nous avons lancé à nouveau le logiciel de stress test CPU sur ces 3 machines virtuelles et vous pouvez voir que le processeur invité (vCPU) des machines virtuelles est utilisé à environ 50% (à cause de l'état READY (Prêt) expliqué à l'étape 2 de ce tutoriel).

A nouveau, pour voir la valeur du CO-STOP, activez le SSH sur votre hôte VMware ESXi (si ce n'est pas déjà fait) et utilisez la commande "esxtop".

Plain Text

esxtop

Comme vous pouvez le voir, du CO-STOP (%CSTP) apparait pour 2 machines virtuelles.
On comprend rapidement que les machines virtuelles affichées sont :

• la VM 3 avec 4 vCPUs, d'où le CO-STOP élevé étant donné que le délai entre la fin de l'exécution sur le coeur le plus rapide et celui le plus lent est le plus élevé.
• la VM 2 avec 2 vCPUs, d'où le CO-STOP qui apparait, mais qui est moins élevé que la VM précédente.
• la VM 1 avec 1 vCPU, d'où le CO-STOP qui reste à 0. En effet, il ne peut pas y avoir de délai entre l'exécution sur les différents coeurs étant donné que la machine virtuelle n'en utilise qu'un.

Source : Determining if multiple virtual CPUs are causing performance issues (1005362).

A nouveau, si vous regardez le graphique de performance CPU de vos machines, vous verrez l'utilisation du CPU et l'état "Prêt" apparaitre.
Mais, la valeur du CO-STOP n'apparaitra pas ici.

4. Alignement NUMA

Si vous possédez un serveur avec plusieurs coeurs et que celui-ci supporte la technologie NUMA, il est possible de gérer l'alignement NUMA pour que vos machines virtuelles bénéficient de meilleures performances.
En effet, lorsque vous possédez un serveur avec plusieurs processeurs physiques, ceux-ci ont accès plus rapidement à une banque mémoire (Memory Node) locale via un bus très rapide.
Même si ceux-ci peuvent aussi accéder aux autres banques de mémoire via des bus un peu moins rapides.

Dans ce cas-ci, vous pouvez voir que nous avons une machine virtuelle avec 4 vCPUs qui est correctement alignée sur la topologie NUMA du serveur physique.
En effet, l'hyperviseur VMware ESXi placera correctement les 4 vCPUs de notre machine virtuelle sur les coeurs d'un seul processeur (via le client NUMA) de façon à n'utiliser que la mémoire de la banque de mémoire (Memory Node) proche du processeur physique concerné.
Ainsi, les échanges entre les coeurs du processeur et la banque de mémoire seront très rapides étant donné que c'est le bus très rapide qui sera utilisé.

Par contre, si la machine virtuelle n'a pas conscience de la topologie NUMA du serveur physique, alors il se peut que les coeurs ne soient pas correctement assignés.
Dans ce cas-ci, l'hyperviseur VMware ESXi assignera peut-être 2 vCPUs sur un processeur physique et 2 vCPUs sur un autre processeur physique.
Ce qui aura pour conséquence d'utiliser de la mémoire dans 2 banques de mémoire et donc d'utiliser les bus très rapides et moins rapides.
Les performances de la machine virtuelle ne seront donc pas optimales.

Attention : activer l'ajout à chaud de CPU dans le matériel virtuel de votre machine virtuelle désactive le support du NUMA pour celle-ci.
Source : Utilisation de NUMA virtuel - VMware Docs.

Pour tenter de vous démontrer ceci, nous avons tenté de virtualiser VMware ESXi sous Unraid (qui permet d'émuler une topologie NUMA et de personnaliser d'autres options).
Pour ce tutoriel, nous avons donc créé une machine virtuelle sous Unraid avec :

• 8 processeurs logiques qui sont vus comme 2 processeurs séparés avec 4 coeurs chacun.
• 16 Go de mémoire vive.
• une topologie NUMA de 2 processeurs physiques avec une banque de mémoire de 8 Go chacune.

D'où l'apparition du fabricant QEMU sur laquelle repose le système de virtualisation d'Unraid.

Notez que VMware ESXi ne fonctionne pas correctement sous Unraid.
Les banques de données d'ESXi ne fonctionnent pas, dans notre cas.

Activez le protocole SSH de votre hyperviseur VMware ESXi.

Connectez-vous en SSH via PuTTY (par exemple).

Pour vérifier qu'une topologie NUMA est présente dans votre cas, utilisez la commande ci-dessous.

esxcli hardware memory get | grep NUMA

Dans notre cas, nous pouvons voir qu'il y a 2 noeuds NUMA.

NUMA Node Count: 2

Source : Solved: Re: How to check NUMA Node on ESXi host - VMware Technology Network VMTN.

Authentifiez-vous en tant que root et lancez la commande :

esxtop

Pour commencer, appuyez sur "m" pour afficher les informations concernant la mémoire NUMA.
En effet, en haut, vous verrez une ligne "NUMA" avec la quantité de mémoire des différentes banques de mémoire NUMA de votre serveur physique.
Dans notre cas, il y a 2 banques de mémoire de 8 Go chacune.

Appuyez sur "V" pour n'afficher que la liste des machines virtuelles dans le tableau.

Note : dans notre cas, étant donné que les banques de données ne fonctionnent pas avec cet hôte VMware ESXi virtualisé, nous n'avons pas de machine virtuelle qui s'affiche.

Appuyez sur "F" pour afficher ce menu et activez l'option "NUMA STATS = Numa Statistics" en appuyant sur "G".

Une astérisque (*) apparaitra à devant la ligne "G: NUMA STATS = Numa Statistics".
Appuyez sur Enter.

Pour vérifier qu'une machine virtuelle est correctement alignée, il suffit de vérifier si la valeur indiquée dans la colonne "N%L" est égale à 100%.
Si un tiret (-) s'affiche, c'est que la topologie NUMA n'est pas utilisée et si la valeur est inférieure à 100%, c'est que la machine n'est pas entièrement alignée par rapport à la topologie NUMA de votre serveur physique.