Dans cet article, nous parlerons des compteurs de performance de la mémoire vive (RAM) dans vSphere.
Il semble qu'avec la mémoire tout soit plus clair qu'avec le processeur : si une VM a des problèmes de performances, difficile de ne pas les remarquer. Mais s'ils apparaissent, il est beaucoup plus difficile de les traiter. Mais avant tout.
Un peu de théorie
La RAM des machines virtuelles est prélevée sur la mémoire du serveur sur lequel les VM tournent. C'est assez évident :). Si la RAM du serveur n'est pas suffisante pour tout le monde, ESXi commence à utiliser des techniques de récupération de mémoire pour optimiser la consommation de RAM. Sinon, les systèmes d'exploitation VM planteraient avec des erreurs d'accès à la RAM.
Quelles techniques utiliser ESXi décide en fonction de la charge de RAM :
État de la mémoire
Frontière
Activité
Haute
400 % de minGratuit
Après avoir atteint la limite supérieure, les grandes pages de mémoire sont divisées en petites (TPS fonctionne en mode standard).
Effacer
100 % de minGratuit
Les grandes pages de mémoire sont divisées en petites, TPS est obligé de fonctionner.
Doux / Pastel
64 % de minGratuit
TPS + Ballon
Dur
32 % de minGratuit
TPS + Compresser + Échanger
Faible
16 % de minGratuit
Compresser + Échanger + Bloquer
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 de la taille de la mémoire sur les serveurs, minFree a commencé à être calculé en fonction de la quantité de mémoire de l'hôte et non en pourcentage fixe.
La valeur 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
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.
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
Habituellement, pour les peuplements productifs, seul l'état élevé peut être considéré comme normal. Pour les bancs de test et de développement, les états Clear/Soft peuvent être acceptables. Si la RAM sur l'hôte est inférieure à 64 % MinFree, les machines virtuelles qui y sont exécutées ont définitivement des problèmes de performances.
Dans chaque état, certaines techniques de récupération de mémoire sont appliquées, en commençant par TPS, qui n'affecte pratiquement pas les performances de la VM, et en terminant par Swapping. Je vais vous en dire plus à leur sujet.
Partage de page transparent (TPS). TPS est, grosso modo, la déduplication des pages mémoire d'une machine virtuelle sur un serveur.
ESXi recherche des pages identiques de RAM de machine virtuelle en comptant et en comparant 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. Par conséquent, la consommation de mémoire physique est réduite et une sursouscription de mémoire peut être obtenue avec peu ou pas de dégradation des performances.
Ce mécanisme ne fonctionne que pour les pages mémoire de 4 Ko (petites pages). L'hyperviseur ne cherche même pas à dédupliquer les pages de 2 Mo (grandes pages) : la chance de retrouver des pages identiques de cette taille n'est pas grande.
Par défaut, ESXi alloue de la mémoire aux grandes pages. La décomposition de grandes pages en petites pages commence lorsque le seuil d'état Haut est atteint et est forcée lorsque l'état Effacer est atteint (voir le tableau des états de l'hyperviseur).
Si vous souhaitez que TPS commence à fonctionner sans attendre que la RAM de l'hôte se remplisse, dans Options avancées ESXi, vous devez définir la valeur "Mem.AllocGuestLargePage" à 0 (1 par défaut). 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 VM a été désactivé par défaut, car une vulnérabilité a été trouvée qui permet théoriquement l'accès d'une VM à la RAM d'une autre VM. Détails ici. Je n'ai pas trouvé d'informations sur la mise en œuvre pratique de l'exploitation de la vulnérabilité TPS.
Politique TPS contrôlée via l'option avancée "Mem.ShareForceSalting" sur ESXi :
0 - TPS inter-VM. TPS fonctionne pour les pages de différentes machines virtuelles ;
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 de la VM.
Il est tout à fait logique de désactiver les pages volumineuses et d'activer le TPS inter-VM sur les bancs de test. Il peut également être utilisé pour les stands avec un grand nombre de VM du même type. Par exemple, sur les stands avec VDI, les économies de mémoire physique peuvent atteindre des dizaines de pour cent.
gonflement de la mémoire. Le gonflage n'est plus une technique aussi inoffensive et transparente pour le système d'exploitation VM que TPS. Mais avec une application appropriée, vous pouvez vivre et même travailler avec le ballon.
Avec Vmware Tools, un pilote spécial appelé Balloon Driver (alias vmmemctl) est installé sur la machine virtuelle. Lorsque l'hyperviseur commence à manquer de mémoire physique et passe à l'état Soft, ESXi demande à la machine virtuelle de récupérer 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 le pilote de ballon a occupées, prend la mémoire de la machine virtuelle et la restitue à 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 que le gonflage est désactivé (je ne le recommande pas, mais il existe :), l'hyperviseur passe immédiatement à des techniques de suppression de mémoire plus strictes. Conclusion : assurez-vous que VMware Tools se trouve sur la VM.
Le fonctionnement du pilote de ballon peut être vérifié à partir du système d'exploitation via VMware Tools.
compression de la mémoire. Cette technique est utilisée lorsqu'ESXi atteint l'état Hard. Comme son nom l'indique, ESXi tente de réduire une page de 4 Ko de RAM à 2 Ko et ainsi de libérer de l'espace sur la mémoire physique du serveur. Cette technique augmente significativement le temps d'accès au contenu des pages de la VM RAM, puisque la page doit d'abord être décompressée. Parfois, toutes les pages ne peuvent pas être compressées et le processus lui-même prend un certain temps. Cette technique n'est donc pas très efficace en pratique.
échange de mémoire. Après une courte phase de compression de la mémoire, ESXi passera presque inévitablement (si les machines virtuelles ne sont pas parties pour d'autres hôtes ou éteintes) en échange. Et s'il reste très peu de mémoire (état bas), alors l'hyperviseur arrête également d'allouer des pages mémoire à la VM, ce qui peut causer des problèmes dans l'OS invité de la VM.
Voici comment fonctionne l'échange. Lorsque vous activez une machine virtuelle, un fichier avec l'extension .vswp est créé pour celle-ci. Elle est égale en taille à 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 Swapping est en cours d'exécution, ESXi décharge les pages de mémoire de la machine virtuelle dans ce fichier et commence à travailler avec celui-ci au lieu de la mémoire physique du serveur. Bien sûr, une telle mémoire "opérative" est plusieurs ordres de grandeur plus lente que la vraie, même si .vswp repose sur un stockage rapide.
Contrairement à Ballooning, lorsque des pages inutilisées sont extraites de la VM, avec Swapping, les 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 vers le disque. En conséquence, les performances de la machine virtuelle chutent au point de geler. La VM fonctionne formellement et au moins elle peut être correctement désactivée à partir du système d'exploitation. Si vous êtes 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 la mémoire de la VM clé
Nous sommes donc arrivés à l'essentiel. Pour surveiller l'état de la mémoire dans la VM, il existe les compteurs suivants :
Actif — indique la quantité de RAM (Ko) à laquelle la VM a eu accès au cours de la période de mesure précédente.
Utilisation - identique à Actif, mais en pourcentage de la RAM configurée de la VM. Calculé à l'aide de la formule suivante : taille de la mémoire configurée de la machine virtuelle active ÷.
L'utilisation élevée et l'activité, respectivement, ne sont pas toujours un indicateur de problèmes de performances de VM. Si la machine virtuelle utilise la mémoire de manière agressive (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 l'OS.
Il existe une alarme d'utilisation de la mémoire standard pour les VM :
Owned - la quantité de RAM VM dédupliquée à l'aide de TPS (à l'intérieur de la VM ou entre VM).
Certes - la quantité de mémoire physique de l'hôte (Ko) qui a été attribuée à la VM. Comprend Partagé.
Consommé (Accordé - Partagé) - la quantité de mémoire physique (Ko) que la VM consomme de l'hôte. N'inclut pas Partagé.
Si une partie de la mémoire de la VM provient non pas de la mémoire physique de l'hôte, mais du fichier d'échange, ou si la mémoire est prélevée de la VM via le Balloon Driver, cette quantité n'est pas prise en compte dans Granted et Consumed.
Les valeurs accordées et consommées élevées sont parfaitement normales. Le système d'exploitation prend progressivement de la mémoire à l'hyperviseur et ne la restitue pas. Au fil du temps, dans une machine virtuelle en cours d'exécution, les valeurs de ces compteurs se rapprochent de la quantité de mémoire configurée et y restent.
Zero — la quantité de VM RAM (Ko), qui contient des zéros. Cette mémoire est considérée comme libre par l'hyperviseur et peut être donnée à d'autres machines virtuelles. Une fois que le système d'exploitation invité a écrit quelque chose dans la mémoire mise à zéro, il passe en consommation et ne revient pas.
Frais généraux réservés — la quantité de RAM VM, (Ko) réservée par l'hyperviseur pour le fonctionnement de la VM. 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 VM à l'aide du Balloon Driver.
Comprimé - la quantité de RAM (Ko) qui a été compressée.
Échangé - la quantité de RAM (Ko) qui, en raison d'un manque de mémoire physique sur le serveur, a été déplacée vers le disque.
Les compteurs de gonflage et d'autres techniques de récupération de mémoire sont à zéro.
Voici à quoi ressemble le graphique avec les compteurs de mémoire pour une machine virtuelle fonctionnant normalement avec 150 Go de RAM.
Dans le graphique ci-dessous, la VM a des problèmes évidents. Sous le graphique, vous pouvez voir 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 Consumed. En fait, la VM est plus morte que vivante.
ESXTOP
Comme pour le CPU, si nous voulons évaluer rapidement la situation sur l'hôte, ainsi que sa dynamique avec un intervalle allant jusqu'à 2 secondes, nous devons utiliser ESXTOP.
L'écran ESXTOP by Memory est appelé avec la touche "m" et se présente comme suit (les champs B, D, H, J, K, L, O sont sélectionnés) :
Les paramètres suivants nous intéresseront :
Mémoire moyenne surchargée - la valeur moyenne de sursouscription mémoire sur l'hôte pendant 1, 5 et 15 minutes. S'il est supérieur à zéro, c'est une occasion de voir ce qui se passe, mais pas toujours un indicateur de problèmes.
En lignes PMEM/MO и VMKMEM/Mo - des 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 de minfree (en Mo), l'état de l'hôte en mémoire (dans notre cas, élevé).
En ligne NUMA/Mo vous pouvez voir la répartition de la RAM par nœuds NUMA (sockets). Dans cet exemple, la répartition est inégale, ce qui, en principe, n'est pas très bon.
Voici les statistiques générales du serveur sur les techniques de récupération de mémoire :
PSHARE/Mo sont des statistiques TPS ;
SWAP/Mo - Statistiques d'utilisation des swaps ;
Code postal/Mo — statistiques de compression des pages mémoire ;
MEMCTL/Mo — Statistiques d'utilisation du pilote de ballon.
Pour les machines virtuelles individuelles, les informations suivantes peuvent nous intéresser. J'ai caché les noms des VM pour ne pas confondre le public :). Si la métrique ESXTOP est similaire au compteur dans vSphere, je donne le compteur correspondant.
MEMSZ — la quantité de mémoire configurée sur la VM (Mo).
MEMSZ = GRANT + MCTLSZ + SWCUR + intact.
SUBVENTION — Accordé à MB.
TCHD — Actif en Mo.
MCTL ? - si Balloon Driver est installé sur la VM.
MCTLSZ — Ballon à MB.
MCTLGT — la quantité de RAM (Mo) qu'ESXi veut prélever de la VM via Balloon Driver (Memctl Target).
MCTLMAX - la quantité maximale de RAM (Mo) qu'ESXi peut prendre de la VM via le pilote de ballon.
SWCUR — la quantité actuelle de RAM (Mo) allouée à la VM à partir du fichier Swap.
S.W.G.T. - la quantité de RAM (Mo) qu'ESXi veut donner à la VM à partir du fichier Swap (Swap Target).
De plus, via ESXTOP, vous pouvez voir des informations plus détaillées sur la topologie NUMA de la machine virtuelle. Pour cela, sélectionnez les champs D, G :
RHN – Nœuds NUMA sur lesquels se trouve la machine virtuelle. Ici, vous pouvez immédiatement remarquer une vm large, qui ne tient pas sur un nœud NUMA.
NRMEM - combien de mégaoctets de mémoire la machine virtuelle prend du nœud NUMA distant.
NLMEM - combien de mégaoctets de mémoire la machine virtuelle prend du nœud NUMA local.
N%L – pourcentage de mémoire VM sur le nœud NUMA local (si inférieur à 80 %, des problèmes de performances peuvent survenir).
Mémoire sur l'hyperviseur
Si les compteurs CPU de l'hyperviseur ne présentent généralement pas d'intérêt particulier, la situation est inversée avec la mémoire. Une utilisation élevée de la mémoire sur une machine virtuelle n'indique pas toujours un problème de performances, mais une utilisation élevée de la mémoire sur un hyperviseur déclenche des techniques de gestion de la mémoire et entraîne des problèmes de performances dans la machine virtuelle. Les alarmes d'utilisation de la mémoire de l'hôte doivent être surveillées pour empêcher la machine virtuelle d'entrer dans Swap.
Annuler la permutation
Si une VM est en Swap, ses performances sont fortement réduites. Les traces de gonflage 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 sortir une machine virtuelle de Swap était de redémarrer (pour être plus précis, éteindre/allumer le conteneur). À partir d'ESXi 6.0, bien que pas tout à fait officiel, un moyen fonctionnel et fiable de supprimer une machine virtuelle de Swap est apparu. Lors d'une des conférences, j'ai pu discuter avec l'un des ingénieurs de VMware en charge de CPU Scheduler. Il a confirmé que la méthode est tout à fait efficace et sûre. D'après notre expérience, il n'y avait aucun problème non plus.
Les commandes réelles pour supprimer la VM du Swap Duncan Epping. Je ne vais pas répéter une description détaillée, juste donner un exemple de son utilisation. Comme vous pouvez le voir sur la capture d'écran, quelque temps après l'exécution des commandes spécifiées, Swap disparaît sur la VM.
Conseils de gestion de la mémoire ESXi
Enfin, voici quelques conseils qui vous aideront à éviter les problèmes de performances des VM dus à la RAM :
- Évitez la sursouscription de la mémoire dans les clusters productifs. Il est souhaitable de toujours disposer d'environ 20 à 30 % de mémoire libre dans le cluster afin que DRS (et l'administrateur) aient une marge de manœuvre et que les machines virtuelles ne passent pas en mode Swap pendant la migration. N'oubliez pas non plus la marge de tolérance aux pannes. C'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 en mode 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. Cela aidera à nouveau DRS à distribuer les machines virtuelles sur les serveurs du cluster sans aucun problème. 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 la VM et ne désactivez pas le Ballooning.
- Envisagez d'activer Inter-VM TPS et de désactiver les pages volumineuses dans les environnements VDI et de test.
- Si la machine virtuelle rencontre des problèmes de performances, vérifiez si elle utilise la mémoire d'un nœud NUMA distant.
- Sortez votre VM de Swap le plus rapidement possible ! Entre autres, si la VM est en Swap, pour des raisons évidentes, le système de stockage en pâtit.
C'est tout pour moi à propos de la RAM. Vous trouverez ci-dessous un article connexe pour ceux qui souhaitent approfondir les détails. Le prochain article sera consacré à storadzh.
Liens utiles
Source: habr.com