Analyse des performances des machines virtuelles dans VMware vSphere. Partie 2: Mémoire

Partie 1. À propos du CPU
Partie 3. À propos du stockage

Dans cet article, nous parlerons des compteurs de performances RAM dans vSphere.
Il semble que la mémoire soit de plus en plus sans ambiguïté qu'avec le processeur: s'il y a des problèmes de performances sur la VM, il est difficile de ne pas les remarquer. Mais s'ils apparaissent, les traiter est beaucoup plus difficile. Mais tout d'abord.

Un peu de théorie

La RAM des machines virtuelles est extraite de la mémoire du serveur sur lequel les VM s'exécutent. C'est assez évident :). Si la RAM du serveur n'est pas suffisante pour tout le monde, ESXi commence à appliquer des techniques de récupération de mémoire. Sinon, les systèmes d'exploitation VM se bloqueraient avec des erreurs d'accès à la RAM.

Quelles techniques utiliser ESXi décide en fonction de la charge de RAM:
Source

minFree est la RAM nécessaire au fonctionnement de l'hyperviseur.

Avant ESXi 4.1 inclus, minFree était fixé par défaut - 6% de la RAM du serveur (le pourcentage pouvait être modifié via l'option Mem.MinFreePct sur ESXi). Dans les versions ultérieures, en raison de l'augmentation des volumes de mémoire sur les serveurs minFree, il a commencé à être calculé en fonction de la taille de la mémoire de l'hôte, et non en tant que valeur de pourcentage fixe.

La valeur minFree (par défaut) est calculée comme suit:
Source

Par exemple, pour un serveur avec 128 Go de RAM, la valeur MinFree serait:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 Mo = 1,88 Go
La valeur réelle peut différer de quelques centaines de Mo, cela dépend du serveur et de la RAM.


En règle générale, pour les peuplements productifs, seul Elevé peut être considéré comme normal. Pour les bancs d'essai et de développement, des conditions claires / douces peuvent être acceptables. S'il reste moins de 64% MinFree de RAM sur l'hôte, les machines virtuelles exécutées sur celui-ci rencontreront certainement des problèmes de performances.

Dans chaque état, certaines techniques de récupération de mémoire sont appliquées à partir de TPS, ce qui n'affecte pratiquement pas les performances de la machine virtuelle, se terminant par Swapping. Je vais vous en dire plus à leur sujet.

Partage de page transparent (TPS). TPS est, en gros, la déduplication des pages de RAM des machines virtuelles sur un serveur.

ESXi recherche des pages identiques de RAM de machine virtuelle, compte et compare la somme de hachage des pages et supprime les pages en double, en les remplaçant par des liens vers la même page dans la mémoire physique du serveur. En conséquence, la consommation de mémoire physique est réduite, et une certaine réabonnement de la mémoire peut être obtenue avec peu ou pas de perte de performances.


Source

Ce mécanisme ne fonctionne que pour les pages de 4 ko (petites pages). Pages de 2 Mo de taille (grandes pages) l'hyperviseur n'essaie même pas de dédupliquer: la chance de trouver des pages identiques de cette taille n'est pas grande.

Par défaut, ESXi alloue de la mémoire aux grandes pages. La division de grandes pages en petites pages commence lorsque le seuil de l'état Haut est atteint et est forcée lorsque l'état Effacer est atteint (voir le tableau des états de l'hyperviseur).

Si vous voulez que TPS commence à fonctionner sans attendre que la RAM hôte se remplisse, dans Advanced Options ESXi, vous devez définir la valeur «Mem.AllocGuestLargePage» sur 0 (la valeur par défaut est 1). Ensuite, l'allocation de grandes pages de mémoire pour les machines virtuelles sera désactivée.

Depuis décembre 2014, dans toutes les versions d'ESXi, le TPS entre les VM a été désactivé par défaut, car une vulnérabilité a été trouvée qui permet théoriquement d'accéder à la RAM d'une autre VM à partir d'une VM. Détails ici. Informations sur la mise en œuvre pratique de l'exploitation de la vulnérabilité TPS que je n'ai pas rencontrées.

La politique TPS est contrôlée via l'option avancée «Mem.ShareForceSalting» sur ESXi:
0 - TPS inter-VM. TPS fonctionne pour les pages de différentes VM;
1 - TPS pour VM avec la même valeur «sched.mem.pshare.salt» dans VMX;
2 (par défaut) - TPS intra-VM. TPS fonctionne pour les pages à l'intérieur d'une machine virtuelle.

Il est certainement judicieux de désactiver les grandes pages et d'activer Inter-VM TPS sur les bancs de test. Il peut également être utilisé pour des stands avec un grand nombre de VM du même type. Par exemple, sur les supports avec VDI, les économies de mémoire physique peuvent atteindre des dizaines de pour cent.

Ballon de mémoire. La montgolfière n'est plus une technique aussi inoffensive et transparente pour le système d'exploitation VM que TPS. Mais avec une utilisation appropriée avec Ballooning, vous pouvez vivre et même travailler.

Avec Vmware Tools, un pilote spécial est installé sur la machine virtuelle, appelé Balloon Driver (alias vmmemctl). Lorsque l'hyperviseur commence à manquer de mémoire physique et passe à l'état Soft, ESXi demande à la machine virtuelle de renvoyer la RAM inutilisée via ce pilote de ballon. Le pilote, à son tour, fonctionne au niveau du système d'exploitation et lui demande de la mémoire libre. L'hyperviseur voit quelles pages de mémoire physique Balloon Driver a prises, prend la mémoire de la machine virtuelle et la retourne à l'hôte. Il n'y a aucun problème avec le fonctionnement du système d'exploitation, car au niveau du système d'exploitation, la mémoire est occupée par le pilote de ballon. Par défaut, Balloon Driver peut occuper jusqu'à 65% de la mémoire de la machine virtuelle.

Si VMware Tools n'est pas installé sur la machine virtuelle ou si la bulle est désactivée (je ne le recommande pas, mais il y a KB :), l'hyperviseur bascule immédiatement vers des méthodes plus strictes de suppression de mémoire. Conclusion: assurez-vous que VMware Tools sur la machine virtuelle l'est.


Le fonctionnement de Balloon Driver peut être vérifié à partir du système d'exploitation via VMware Tools .

Compression mémoire Cette technique est utilisée lorsque ESXi atteint Hard. Comme son nom l'indique, ESXi essaie de compresser 4 Ko de pages RAM en 2 Ko et ainsi libérer de l'espace dans la mémoire physique du serveur. Cette technique augmente considérablement le temps d'accès au contenu des pages de la mémoire RAM de la VM, car la page doit d'abord être nettoyée. Parfois, toutes les pages ne peuvent pas être compressées et le processus lui-même prend un certain temps. Par conséquent, cette technique n'est pas très efficace en pratique.

Échange de mémoire. Après une courte phase, la compression de mémoire ESXi est presque inévitablement (si les machines virtuelles ne sont pas allées sur d'autres hôtes ou ne se sont pas arrêtées) passe au Swapping. Et s'il reste très peu de mémoire (état bas), l'hyperviseur arrête également d'allouer des pages de mémoire de machine virtuelle, ce qui peut provoquer des problèmes dans les machines virtuelles invitées.

Voici comment fonctionne le swapping. Lorsque vous allumez la machine virtuelle, un fichier avec l'extension .vswp est créé pour elle. En taille, elle est égale à la RAM non réservée de la VM: c'est la différence entre la mémoire configurée et la mémoire réservée. Lorsque vous travaillez avec Swapping, ESXi décharge les pages de mémoire de la machine virtuelle dans ce fichier et commence à travailler avec lui au lieu de la mémoire physique du serveur. Bien sûr, une telle mémoire "RAM" est plus lente de plusieurs ordres de grandeur que la mémoire réelle, même si .vswp est en stockage rapide.

Contrairement à Ballooning, lorsque des pages inutilisées sont sélectionnées à partir d'une machine virtuelle, les pages qui sont activement utilisées par le système d'exploitation ou les applications à l'intérieur de la machine virtuelle peuvent aller sur le disque pendant l'échange. Par conséquent, les performances de la machine virtuelle diminuent jusqu'à ce qu'elle se bloque. La VM fonctionne officiellement et au moins elle peut être correctement désactivée du système d'exploitation. Si vous serez patient;)

Si les machines virtuelles sont passées à Swap, il s'agit d'une situation anormale qu'il vaut mieux éviter si possible.

Compteurs de performances de base de la mémoire de la machine virtuelle

Nous sommes donc arrivés à l'essentiel. Pour surveiller l'état de la mémoire dans la machine virtuelle, les compteurs suivants sont disponibles:

Actif - indique la quantité de RAM (kilo-octets) à laquelle la machine virtuelle a accédé au cours de la période de mesure précédente.

L'utilisation est identique à Active, mais en pourcentage de la mémoire de la VM configurée. Il est calculé à l'aide de la formule suivante: taille de mémoire active ÷ machine virtuelle configurée.
Une utilisation élevée et active, respectivement, ne sont pas toujours révélatrices de problèmes de performances des machines virtuelles. Si une machine virtuelle utilise de manière agressive la mémoire (au moins y accède), cela ne signifie pas qu'il n'y a pas assez de mémoire. C'est plutôt l'occasion de voir ce qui se passe dans le système d'exploitation.
Il existe une alarme standard sur l'utilisation de la mémoire pour les machines virtuelles:



Partagé - la quantité de RAM dans une machine virtuelle dédupliquée à l'aide de TPS (à l'intérieur d'une machine virtuelle ou entre machines virtuelles).

Accordé - la quantité de mémoire physique de l'hôte (kilo-octets) qui a été donnée à la machine virtuelle. Comprend partagé.

Consommé (accordé - partagé) - la quantité de mémoire physique (kilo-octets) que la machine virtuelle consomme de l'hôte. N'inclut pas Shared.

Si une partie de la mémoire de la machine virtuelle n'est pas allouée à partir de la mémoire physique de l'hôte, mais du fichier d'échange ou que la mémoire a été prise à partir de la machine virtuelle via le pilote de ballon, ce montant n'est pas pris en compte dans Accordé et Consommé.
Les valeurs élevées de Accordé et Consommé sont parfaitement normales. Le système d'exploitation retire progressivement la mémoire de l'hyperviseur et ne rend pas. Au fil du temps, avec une machine virtuelle fonctionnant activement, les valeurs de ces compteurs approchent la quantité de mémoire configurée et y restent.

Zéro - la quantité de RAM dans la machine virtuelle (kilo-octets), qui contient des zéros. Cette mémoire est considérée comme un hyperviseur libre et peut être donnée à d'autres machines virtuelles. Après que l'OS invité l'ait reçu, il a écrit quelque chose dans la mémoire nulle, il va à Consumed et ne revient pas.

Surcharge réservée - la quantité de RAM dans la VM, (Ko) réservée par l'hyperviseur pour que la VM fonctionne. C'est une petite quantité, mais elle doit être disponible sur l'hôte, sinon la VM ne démarrera pas.

Ballon - la quantité de RAM (Ko) saisie sur la machine virtuelle à l'aide du pilote de ballon.

Compressé - la quantité de RAM (Ko) qui a pu être compressée.

Swapped - la quantité de RAM (Ko) qui, par manque de mémoire physique sur le serveur, s'est déplacée sur le disque.
Les compteurs de ballons et autres techniques de récupération de mémoire sont nuls.

Voici à quoi ressemble le graphique avec les compteurs de mémoire d'une machine virtuelle fonctionnant normalement avec 150 Go de RAM.



Sur le graphique ci-dessous, la machine virtuelle a des problèmes évidents. Le graphique montre que pour cette machine virtuelle, toutes les techniques décrites pour travailler avec la RAM ont été utilisées. Le ballon pour cette machine virtuelle est beaucoup plus grand que consommé. En fait, la VM est probablement morte que vivante.

ESXTOP

Comme avec le CPU, si vous voulez évaluer rapidement la situation sur l'hôte, ainsi que sa dynamique avec un intervalle allant jusqu'à 2 secondes, cela vaut la peine d'utiliser ESXTOP.

L'écran de mémoire ESXTOP est appelé avec la touche «m» et ressemble à ceci (champs B, D, H, J, K, L, O sélectionnés):



Les paramètres suivants nous intéresseront:

Mem overcommit avg - la valeur moyenne d'un sur-abonnement mémoire sur un hôte pendant 1, 5 et 15 minutes. Si au-dessus de zéro, c'est l'occasion de voir ce qui se passe, mais pas toujours un indicateur de la présence de problèmes.

Dans les lignes PMEM / MB et VMKMEM / MB - informations sur la mémoire physique du serveur et la mémoire disponible pour VMkernel. De l'intéressant ici, vous pouvez voir la valeur minfree (en Mo), l'état de l'hôte de la mémoire (dans notre cas, élevé).

Dans la ligne NUMA / MB, vous pouvez voir la répartition de la RAM par NUMA-nœuds (sockets). Dans cet exemple, la répartition est inégale, ce qui en principe n'est pas très bon.

Voici un résumé des statistiques du serveur pour les techniques de récupération de mémoire:

PSHARE / MB est les statistiques TPS;

SWAP / MB - statistiques sur l'utilisation de Swap;

ZIP / MB - statistiques de compression des pages mémoire;

MEMCTL / MB - Statistiques d'utilisation du pilote de ballon.

Pour les machines virtuelles individuelles, nous pouvons être intéressés par les informations suivantes. J'ai caché les noms des VM pour ne pas embarrasser le public :). Si la métrique ESXTOP est la même que le compteur dans vSphere, je cite le compteur correspondant.

MEMSZ est la quantité de mémoire configurée sur la machine virtuelle (Mo).
MEMSZ = GRANT + MCTLSZ + SWCUR + intact.

SUBVENTION - Accordée en Mo.

TCHD - Actif en Mo.

MCTL? - est installé sur VM Balloon Driver.

MCTLSZ - Ballon en MB.

MCTLGT est la quantité de RAM (Mo) qu'ESXi souhaite supprimer de la machine virtuelle via le pilote de ballon (cible Memctl).

MCTLMAX - la quantité maximale de RAM (Mo) qu'ESXi peut supprimer de la machine virtuelle via le pilote de ballon.

SWCUR - la quantité actuelle de RAM (Mo) donnée à la machine virtuelle à partir du fichier d'échange.

SWGT - la quantité de RAM (Mo) qu'ESXi veut donner aux VM à partir d'un fichier Swap (Swap Target).

Également via ESXTOP, vous pouvez voir des informations plus détaillées sur la topologie NUMA VM. Pour ce faire, sélectionnez les champs D, G:



NHN - nœuds NUMA sur lesquels se trouve la machine virtuelle. Ici, vous pouvez immédiatement remarquer un vm large qui ne tient pas sur un nœud NUMA.

NRMEM - combien de mégaoctets de mémoire la VM prend du nœud NUMA distant.

NLMEM - combien de mégaoctets de mémoire la VM prend du nœud NUMA local.

N% L - pourcentage de mémoire VM sur le nœud NUMA local (si moins de 80%, des problèmes de performances peuvent survenir).

Mémoire sur l'hyperviseur

Si les compteurs CPU sur l'hyperviseur ne sont généralement pas d'un intérêt particulier, alors la situation est inverse avec la mémoire. Une utilisation élevée de la mémoire sur la machine virtuelle n'indique pas toujours un problème de performances, mais une utilisation élevée de la mémoire sur l'hyperviseur démarre simplement le technicien de gestion de la mémoire et provoque des problèmes avec les performances de la machine virtuelle. Les alarmes d'utilisation de la mémoire hôte doivent être surveillées et les machines virtuelles ne doivent pas entrer dans Swap.

Annuler

Si la machine virtuelle entre dans Swap, ses performances sont considérablement réduites. Les traces de montgolfière et de compression disparaissent rapidement après l'apparition de RAM libre sur l'hôte, mais la machine virtuelle n'est pas pressée de revenir de Swap à la RAM du serveur.
Avant ESXi 6.0, le seul moyen fiable et rapide de retirer les machines virtuelles de Swap était de redémarrer (plus précisément, d'activer / désactiver le conteneur). À partir d'ESXi 6.0, un moyen pas si officiel, mais fonctionnel et fiable pour sortir les machines virtuelles de Swap est apparu. Lors d'une des conférences, j'ai réussi à parler avec l'un des ingénieurs VMware responsable du Planificateur de CPU. Il a confirmé que la méthode fonctionne et est assez sûre. D'après notre expérience, aucun problème avec lui n'a également été constaté.

Duncan Epping a décrit les commandes réelles de sortie des machines virtuelles à partir de Swap. Je ne répéterai pas la description détaillée, donne juste un exemple de son utilisation. Comme on peut le voir sur la capture d'écran, un certain temps après l'exécution des commandes Swap spécifiées sur la machine virtuelle disparaît.

Conseils pour gérer la RAM sur ESXi

En conclusion, je vais vous donner quelques conseils pour vous aider à éviter les problèmes de performances des VM dus à la RAM:

• Évitez de sursouscrire en RAM dans les clusters productifs. Il est toujours conseillé d'avoir environ 20-30% de mémoire libre dans le cluster, afin que DRS (et l'administrateur) ait de la marge de manœuvre, et que les machines virtuelles ne passent pas à Swap pendant la migration. N'oubliez pas non plus la marge de tolérance aux pannes. Il est désagréable lorsque, lorsqu'un serveur tombe en panne et que la machine virtuelle est redémarrée à l'aide de HA, certaines machines passent également à Swap.
• Dans les infrastructures hautement consolidées, essayez de NE PAS créer de machines virtuelles avec plus de la moitié de la mémoire hôte. Ceci, encore une fois, aidera DRS à distribuer les machines virtuelles entre les serveurs de cluster sans aucun problème. Cette règle, bien sûr, n'est pas universelle :).
• Attention à l'alarme d'utilisation de la mémoire de l'hôte.
• N'oubliez pas de mettre VMware Tools sur la machine virtuelle et de ne pas désactiver la montgolfière.
• Pensez à activer Inter-VM TPS et à désactiver les grandes pages dans les environnements VDI et de test.
• Si la machine virtuelle rencontre des problèmes de performances, vérifiez si elle utilise de la mémoire à partir d'un nœud NUMA distant.
• Retirez les machines virtuelles de Swap le plus rapidement possible! Entre autres choses, si la VM est en Swap, pour des raisons évidentes, le système de stockage en souffre.

C'est tout pour la RAM. Vous trouverez ci-dessous des articles connexes pour ceux qui souhaitent approfondir les détails. Le prochain article sera consacré à l'histoire.