Analyse de performance des VM dans VMware vSphere. Partie 2 : Mémoire

Partie 1. Sur le CPU

Dans cet article, nous allons parler des compteurs de performance de la mémoire vive (RAM) dans vSphere.
Il semble que la mémoire soit plus claire que le processeur : si des problèmes de performance surviennent sur la VM, il est difficile de ne pas les remarquer. Cependant, une fois qu'ils apparaissent, il est beaucoup plus compliqué de les résoudre. Mais procédons étape par étape.

Un peu de théorie

La mémoire vive des machines virtuelles provient de la mémoire du serveur sur lequel les VMs fonctionnent. C'est assez évident :). Si la mémoire vive du serveur est insuffisante pour toutes les demandes, ESXi commence à appliquer des techniques d'optimisation de la consommation de mémoire (memory reclamation techniques). Sinon, les systèmes d'exploitation des VMs tomberaient avec des erreurs d'accès à la RAM.

Les techniques à appliquer sont décidées par ESXi en fonction de la charge de la mémoire vive :

État de la mémoire

Limite

Actions

Couverture d'ombre du soleil

400 % de minFree

Une fois la limite supérieure atteinte, les grandes pages de mémoire sont divisées en petites (TPS fonctionne en mode standard).

Effacer

100 % de minFree

Les grandes pages de mémoire sont divisées en petites, la TPS fonctionne de manière forcée.

Soft

64 % de minFree

TPS + Balloon

Difficile

32 % de minFree

TPS + Compress + Swap

Faible

16 % de minFree

Compress + Swap + Block

Source

minFree est la mémoire vive nécessaire au fonctionnement de l'hyperviseur.

Jusqu'à ESXi 4.1 inclus, le minFree par défaut était fixe — 6 % de la capacité de mémoire vive du serveur (ce pourcentage pouvait être modifié via l'option Mem.MinFreePct sur ESXi). Dans les versions plus récentes, en raison de l'augmentation des volumes de mémoire sur les serveurs, le minFree est désormais calculé en fonction de la capacité de la mémoire de l'hôte, et non comme une valeur fixe en pourcentage.

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

Pourcentage de mémoire réservé pour minFree

Plage de mémoire

6%

0-4 Go

4%

4-12 Go

2%

12-28 Go

1%

Mémoire restante

Source

Par exemple, pour un serveur avec 128 Go de RAM, la valeur de MinFree serait la suivante :
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 mémoire vive.

Pourcentage de mémoire réservé pour minFree

Plage de mémoire

Valeur pour 128 Go

6%

0-4 Go

245,76 Mo

4%

4-12 Go

327,68 Mo

2%

12-28 Go

327,68 Mo

1%

Mémoire restante (100 Go)

1024 Mo

En général, pour les environnements de production, seul un état élevé peut être considéré comme normal. Pour les environnements de test et de développement, les états clair / doux peuvent être acceptables. Si la mémoire vive restante sur l'hôte est inférieure à 64 % de MinFree, il est certain que les VMs qui fonctionnent dessus rencontrent des problèmes de performance.

Dans chaque état, des techniques spécifiques de reclamation de mémoire sont appliquées, commençant par le TPS, qui impacte pratiquement pas la performance des VM, jusqu'au Swapping. Je vais vous en dire plus à ce sujet.

Transparent Page Sharing (TPS). Le TPS est, en gros, la déduplication des pages de mémoire vive des machines virtuelles sur le serveur.

ESXi recherche des pages de mémoire vive identiques des machines virtuelles, en calculant et en comparant la somme de contrôle des pages, et supprime les duplicatas de pages en les remplaçant par des références à une seule et même page dans la mémoire physique du serveur. En conséquence, la consommation de mémoire physique est réduite et il est possible d'atteindre un certain surallocation de mémoire pratiquement sans baisse de performance.

Source

Ce mécanisme ne fonctionne que pour des pages de mémoire de taille 4 Ko (petites pages). Les pages de 2 Mo (grandes pages) ne sont même pas tentées d'être dédupliquées par l'hyperviseur : la probabilité de trouver des pages identiques de cette taille est faible.

Par défaut, ESXi alloue de la mémoire aux grandes pages. La fragmentation des grandes pages en petites pages commence lorsque le seuil de l'état High est atteint et se produit de manière obligatoire quand l'état Clear est atteint (voir le tableau des états de l'hyperviseur).

Cependant, si vous souhaitez que le TPS commence à fonctionner sans attendre le remplissage de la mémoire de l'hôte, vous devez définir la valeur dans les options avancées ESXi “Mem.AllocGuestLargePage” à 0 (par défaut 1). L'allocation de grandes pages de mémoire pour les machines virtuelles sera alors désactivée.

Depuis décembre 2014, dans toutes les versions d'ESXi, le TPS entre les VM est désactivé par défaut, car une vulnérabilité a été trouvée, permettant théoriquement d'accéder à la mémoire d'une autre VM depuis une seule VM. Plus de détails ici. Je n'ai pas rencontré d'informations sur la mise en œuvre pratique de l'exploitation de la vulnérabilité TPS.

La politique du TPS est contrôlée via l'option avancée “Mem.ShareForceSalting” dans ESXi :
0 — TPS Inter-VM. Le TPS fonctionne pour les pages de différentes VM ;
1 – TPS pour les VM avec la même valeur “sched.mem.pshare.salt” dans le VMX ;
2 (par défaut) – TPS Intra-VM. Le TPS fonctionne pour les pages à l'intérieur d'une VM.

Il a clairement du sens de désactiver les grandes pages et d'activer le TPS Inter-VM sur des bancs d'essai. Cela peut aussi être utilisé pour des environnements avec un grand nombre de VM similaires. Par exemple, sur des environnements VDI, les économies de mémoire physique peuvent atteindre des dizaines de pourcents.

Memory Ballooning. Le Ballooning n'est plus une technique de gestion de la mémoire virtuelle aussi inoffensive et transparente pour le système d'exploitation que le TPS. Mais avec une utilisation appropriée, il est possible de vivre et même de travailler avec le Ballooning.

Avec les VMware Tools, un pilote spécial appelé Balloon Driver (ou vmmemctl) est installé sur la VM. Lorsque l'hyperviseur manque de mémoire physique et passe en état Soft, l'ESXi demande à la VM de restituer la mémoire RAM inutilisée via ce Balloon Driver. Ce dernier fonctionne au niveau du système d'exploitation et demande de la mémoire libre. L'hyperviseur voit quelles pages de mémoire physique sont occupées par le Balloon Driver, retire de la mémoire à la machine virtuelle et la renvoie à l'hôte. Il n'y a pas de problèmes de fonctionnement du système d'exploitation, car au niveau du système d'exploitation, la mémoire est occupée par le Balloon Driver. Par défaut, le Balloon Driver peut récupérer jusqu'à 65 % de la mémoire de la VM.

Si les VMware Tools ne sont pas installés sur la VM ou si le Ballooning est désactivé (ce que je ne recommande pas, mais cela existe KB:), l'hyperviseur passe immédiatement à des techniques de prélèvement de mémoire plus rigoureuses. Conclusion : assurez-vous que les VMware Tools sont installés sur la VM.

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

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

Swap de mémoire. Après une courte phase de Compression de mémoire, l'ESXi passe pratiquement inévitablement (si les VMs n'ont pas été déplacées vers d'autres hôtes ou ne sont pas éteintes) au Swap. Et si la mémoire restante est très faible (état Bas), l'hyperviseur cesse également d'allouer des pages de mémoire à la VM, ce qui peut provoquer des problèmes dans les systèmes d'exploitation invités de la VM.

Voici comment fonctionne l'échange. Lorsqu'une machine virtuelle est allumée, un fichier avec l'extension .vswp est créé pour elle. Sa taille est égale à la mémoire vive 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 l'échange est actif, 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, cette "mémoire" est plusieurs ordres de grandeur plus lente que la véritable mémoire, même si le fichier .vswp se trouve sur un stockage rapide.

Contrairement à Ballooning, où des pages non utilisées sont retirées à la VM, lors de l'échange, des pages qui sont activement utilisées par le système d'exploitation ou les applications à l'intérieur de la VM peuvent être déplacées sur le disque. En conséquence, la performance de la VM chute jusqu'à devenir complètement gelée. La VM fonctionne formellement et peut au moins être correctement arrêtée depuis le système d'exploitation. Si vous êtes patient 😉

Si la VM a commencé à utiliser l'échange, c'est une situation anormale qu'il est préférable d'éviter autant que possible.

Les principaux compteurs de performance de la mémoire de la machine virtuelle

Nous sommes enfin arrivés au principal. Pour surveiller l'état de la mémoire dans la VM, il existe les compteurs suivants :

Actif — indique le volume de mémoire vive (Ko) auquel la VM a eu accès lors de la période de mesure précédente.

Utilisation — même chose que Active, mais en pourcentage de la mémoire vive configurée de la VM. Calculé selon la formule suivante : active ÷ taille de la mémoire vive configurée de la machine virtuelle.
Une forte utilisation et activité ne sont pas toujours des indicateurs de problèmes de performance de la VM. Si la VM utilise agressivement la mémoire (au moins, y accède), cela ne signifie pas qu'il lui manque de la mémoire. C'est plutôt un signal pour examiner ce qui se passe dans le système d'exploitation.
Il existe une alarme standard pour l'utilisation de la mémoire pour la VM :

Partagé — volume de mémoire vive de la VM, dédupliquée à l'aide de TPS (à l'intérieur de la VM ou entre les VMs).

Accordé — volume de mémoire physique de l'hôte (Ko) qui a été alloué à la VM. Inclut la mémoire partagée.

Consommé (Accordé — Partagé) — volume de mémoire physique (Ko) que la VM consomme de l'hôte. N'inclut pas la mémoire partagée.

Si une partie de la mémoire de la VM est fournie non à partir de la mémoire physique de l'hôte, mais à partir d'un fichier de swap ou de la mémoire retirée à la VM via le Balloon Driver, ce volume n'est pas inclus dans les valeurs Accordé et Consommé.
Des valeurs élevées pour Granted et Consumed sont tout à fait normales. Le système d'exploitation prend progressivement de la mémoire au niveau de l'hyperviseur et ne la restitue pas. Avec le temps, pour une VM en fonctionnement actif, les valeurs de ces compteurs approchent le volume de mémoire configurée et y demeurent.

Zéro - volume de la mémoire vive de la VM (Ko), qui contient des zéros. Cette mémoire est considérée par l'hyperviseur comme libre et peut être attribuée à d'autres machines virtuelles. Une fois que le système d'exploitation invité a écrit quelque chose dans cette mémoire mise à zéro, elle passe à Consumed et ne revient plus.

Reserved Overhead - volume de la mémoire vive de la VM (Ko) réservé par l'hyperviseur pour le fonctionnement de la VM. C'est un petit volume, mais il doit absolument être disponible sur l'hôte, sinon la VM ne démarrera pas.

Balloon - volume de la mémoire vive (Ko) prélevé sur la VM à l'aide du Balloon Driver.

Compressed - volume de la mémoire vive (Ko) qui a pu être compressé.

Swapped - volume de la mémoire vive (Ko) qui, en raison du manque de mémoire physique sur le serveur, a été déplacé sur le disque.
Balloon et les autres compteurs des techniques de récupération de mémoire sont à zéro.

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

Sur le graphique ci-dessous, la VM présente des problèmes évidents. En dessous du graphique, il est clair que toutes les techniques de gestion de mémoire décrites ont été utilisées pour cette VM. Le Balloon pour cette VM est nettement supérieur à Consumed. En fait, la VM est plus probablement morte que vivante.

ESXTOP

Comme pour le CPU, si nous voulons évaluer rapidement la situation sur l'hôte, ainsi que sa dynamique par intervalles de 2 secondes, il est conseillé d'utiliser ESXTOP.

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

Les paramètres suivants seront intéressants pour nous :

Mem overcommit avg - la valeur moyenne de sur-allocation de mémoire sur l'hôte sur 1, 5 et 15 minutes. Si elle est supérieure à zéro, cela peut être un motif d'examen de la situation, mais ce n'est pas toujours un indicateur de problème.

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

Dans la ligne NUMA/MB on peut voir la répartition de la mémoire vive selon les nœuds NUMA (sockets). Dans cet exemple, la répartition est inégale, ce qui n'est pas vraiment idéal.

Voici les statistiques globales du serveur concernant les techniques de récupération de mémoire :

PSHARE/MO — c'est la statistique TPS ;

SWAP/MO — la statistique d'utilisation du Swap ;

ZIP/MO — la statistique de compression des pages mémoire ;

MEMCTL/MO — la statistique d'utilisation du Balloon Driver.

Pour chaque VM, nous pourrions être intéressés par les informations suivantes. J'ai caché les noms des VM pour ne pas déranger le public :). Si la métrique ESXTOP est similaire au compteur dans vSphere, je fournis le compteur correspondant.

MEMSZ — volume de la mémoire configuré sur la VM (Mo).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.

GRANT — Granted en Mo.

TCHD — Actif en Mo.

MCTL? — si le Balloon Driver est installé sur la VM.

MCTLSZ — Balloon en Mo.

MCTLGT — volume de mémoire vive (Mo) qu'ESXi souhaite retirer de la VM via le Balloon Driver (Memctl Target).

MCTLMAX — volume maximal de mémoire vive (Mo) qu'ESXi peut retirer de la VM via le Balloon Driver.

SWCUR — volume actuel de mémoire vive (Mo) alloué à la VM à partir du fichier Swap.

SWGT — volume de mémoire vive (Mo) qu'ESXi souhaite allouer à la VM à partir du fichier Swap (Swap Target).

Avec ESXTOP, on peut également voir des informations plus détaillées sur la topologie NUMA de la VM. Pour cela, il faut sélectionner les champs D,G :

NHN – Noeuds NUMA sur lesquels la VM est située. On peut ainsi remarquer immédiatement les VM larges qui ne tiennent pas sur un seul noeud NUMA.

NRMEM – combien de mégaoctets de mémoire la VM prend depuis un noeud NUMA distant.

NLMEM – combien de mégaoctets de mémoire la VM prend depuis un noeud NUMA local.

N%L – pourcentage de mémoire de la VM sur le noeud NUMA local (si inférieur à 80 % — des problèmes de performance peuvent survenir).

Mémoire sur l'hyperviseur

Alors que les compteurs de CPU de l'hyperviseur ne sont généralement pas très intéressants, la situation avec la mémoire est différente. Une utilisation élevée de la mémoire sur la VM ne signifie pas toujours un problème de performance, mais une utilisation élevée de la mémoire sur l'hyperviseur déclenche les techniques de gestion de la mémoire et cause des problèmes de performance sur la VM. Il faut surveiller les alarmes d'utilisation de la mémoire de l'hôte et éviter que les VM n'entrent dans le Swap.

Unsquer

Si la VM est entrée dans le Swap, ses performances diminuent fortement. Les traces de Ballooning et de compression disparaissent rapidement après l'apparition de mémoire vive libre sur l'hôte, mais la machine virtuelle ne se dépêche pas de revenir du Swap à la mémoire vive du serveur.
Jusqu'à la version ESXi 6.0, la seule méthode fiable et rapide pour sortir une VM du Swap était le redémarrage (plus précisément, l'arrêt/redémarrage du conteneur). À partir de la version ESXi 6.0, une méthode, bien que non officielle, mais fonctionnelle et fiable, a été introduite pour sortir une VM du Swap. Lors d'une des conférences, j'ai eu l'occasion de discuter avec l'un des ingénieurs de VMware en charge de l'ordonnanceur CPU. Il a confirmé que cette méthode est tout à fait opérationnelle et sûre. À notre expérience, il n'y a eu aucun problème à ce sujet.

Commandes pour sortir une VM du Swap décrit Duncan Epping. Je ne vais pas répéter une description détaillée, je vais simplement donner un exemple de son utilisation. Comme vous pouvez le voir sur la capture d'écran, après un certain temps, la commande mentionnée fait disparaître le Swap de la VM.

Conseils pour gérer la mémoire vive sur ESXi

Enfin, voici quelques conseils qui vous aideront à éviter des problèmes de performance des VM dus à la mémoire vive :

• Évitez la sursouscription de la mémoire vive dans les clusters de production. Il est préférable de toujours avoir environ 20-30 % de mémoire libre dans le cluster, afin que le DRS (et l'administrateur) ait de la marge de manœuvre, et que lors de la migration des VM, celles-ci ne tombent pas dans le Swap. N'oubliez pas non plus la réserve pour la tolérance aux pannes. C'est désagréable lorsqu'un serveur tombe en panne et que les VM redémarrées par HA se retrouvent dans le Swap.
• Dans des infrastructures avec une haute consolidation, essayez de NE PAS créer de VM avec plus de la moitié de la mémoire de l'hôte. Cela aidera le DRS à répartir sans problème les machines virtuelles entre les serveurs du cluster. Cette règle, bien sûr, n'est pas universelle :).
• Surveillez l'alarme d'utilisation de la mémoire de l'hôte.
• N'oubliez pas d'installer VMware Tools sur les VM et de ne pas désactiver le Ballooning.
• Envisagez d'activer l'Inter-VM TPS et de désactiver les Large Pages dans les environnements VDI et de test.
• Si une VM rencontre des problèmes de performance, vérifiez si elle utilise de la mémoire d'un nœud NUMA distant.
• Sortez les VM du Swap aussi vite que possible ! Par ailleurs, si une VM est dans le Swap, la SAN souffre pour des raisons évidentes.

C'est tout ce que j'avais à dire sur la mémoire vive. Ci-dessous, des articles sur le sujet pour ceux qui souhaitent approfondir. Le prochain article sera dédié au stockage.

Liens utileshttp://www.yellow-bricks.com/2015/03/02/what-happens-at-which-vsphere-memory-state/
http://www.yellow-bricks.com/2013/06/14/how-does-mem-minfreepct-work-with-vsphere-5-0-and-up/
https://www.vladan.fr/vmware-transparent-page-sharing-tps-explained/
http://www.yellow-bricks.com/2016/06/02/memory-pages-swapped-can-unswap/
https://kb.vmware.com/s/article/1002586
https://www.vladan.fr/what-is-vmware-memory-ballooning/
https://kb.vmware.com/s/article/2080735
https://kb.vmware.com/s/article/2017642
https://labs.vmware.com/vmtj/vmware-esx-memory-resource-management-swap
https://blogs.vmware.com/vsphere/2013/10/understanding-vsphere-active-memory.html
https://www.vmware.com/support/developer/converter-sdk/conv51_apireference/memory_counters.html
https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-65-monitoring-performance-guide.pdf

Source : habr.com