{"id":35292,"date":"2019-10-31T22:03:28","date_gmt":"2019-10-31T19:03:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory\/"},"modified":"2019-10-31T22:03:28","modified_gmt":"2019-10-31T19:03:28","slug":"analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory","title":{"rendered":"Analyse de performance des VM dans VMware vSphere. Partie 2 : M\u00e9moire","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Analyse
\n
\nPartie 1. Sur le CPU<\/a><\/noindex><\/p>\n

Dans cet article, nous allons parler des compteurs de performance de la m\u00e9moire vive (RAM) dans vSphere.
\nIl semble que la m\u00e9moire soit plus claire que le processeur : si des probl\u00e8mes 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\u00e9 de les r\u00e9soudre. Mais proc\u00e9dons \u00e9tape par \u00e9tape. <\/a><\/noindex><\/p>\n

Un peu de th\u00e9orie<\/h3>\n

\nLa m\u00e9moire vive des machines virtuelles provient de la m\u00e9moire du serveur sur lequel les VMs fonctionnent. C'est assez \u00e9vident :). Si la m\u00e9moire vive du serveur est insuffisante pour toutes les demandes, ESXi commence \u00e0 appliquer des techniques d'optimisation de la consommation de m\u00e9moire (memory reclamation techniques). Sinon, les syst\u00e8mes d'exploitation des VMs tomberaient avec des erreurs d'acc\u00e8s \u00e0 la RAM. <\/p>\n

Les techniques \u00e0 appliquer sont d\u00e9cid\u00e9es par ESXi en fonction de la charge de la m\u00e9moire vive :<\/p>\n

\u00c9tat de la m\u00e9moire<\/b><\/p>\n

Limite<\/b><\/p>\n

Actions<\/b><\/p>\n

Couverture d'ombre du soleil<\/p>\n

400 % de minFree<\/p>\n

Une fois la limite sup\u00e9rieure atteinte, les grandes pages de m\u00e9moire sont divis\u00e9es en petites (TPS fonctionne en mode standard).<\/p>\n

Effacer<\/p>\n

100 % de minFree<\/p>\n

Les grandes pages de m\u00e9moire sont divis\u00e9es en petites, la TPS fonctionne de mani\u00e8re forc\u00e9e.<\/p>\n

Soft<\/p>\n

64 % de minFree<\/p>\n

TPS + Balloon<\/p>\n

Difficile<\/p>\n

32 % de minFree<\/p>\n

TPS + Compress + Swap<\/p>\n

Faible<\/p>\n

16 % de minFree<\/p>\n

Compress + Swap + Block<\/p>\n

Source<\/a><\/noindex> <\/p>\n

minFree est la m\u00e9moire vive n\u00e9cessaire au fonctionnement de l'hyperviseur. <\/p>\n

Jusqu'\u00e0 ESXi 4.1 inclus, le minFree par d\u00e9faut \u00e9tait fixe \u2014 6 % de la capacit\u00e9 de m\u00e9moire vive du serveur (ce pourcentage pouvait \u00eatre modifi\u00e9 via l'option Mem.MinFreePct sur ESXi). Dans les versions plus r\u00e9centes, en raison de l'augmentation des volumes de m\u00e9moire sur les serveurs, le minFree est d\u00e9sormais calcul\u00e9 en fonction de la capacit\u00e9 de la m\u00e9moire de l'h\u00f4te, et non comme une valeur fixe en pourcentage. <\/p>\n

La valeur de minFree (par d\u00e9faut) est calcul\u00e9e comme suit :<\/p>\n

Pourcentage de m\u00e9moire r\u00e9serv\u00e9 pour minFree<\/b><\/p>\n

Plage de m\u00e9moire<\/b><\/p>\n

6%<\/p>\n

0-4 Go<\/p>\n

4%<\/p>\n

4-12 Go<\/p>\n

2%<\/p>\n

12-28 Go<\/p>\n

1%<\/p>\n

M\u00e9moire restante<\/p>\n

Source<\/a><\/noindex><\/p>\n

Par exemple, pour un serveur avec 128 Go de RAM, la valeur de MinFree serait la suivante :
\nMinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 Mo = 1,88 Go
\nLa valeur r\u00e9elle peut diff\u00e9rer de quelques centaines de Mo, cela d\u00e9pend du serveur et de la m\u00e9moire vive.<\/p>\n

Pourcentage de m\u00e9moire r\u00e9serv\u00e9 pour minFree<\/b><\/p>\n

Plage de m\u00e9moire<\/b><\/p>\n

Valeur pour 128 Go<\/b><\/p>\n

6%<\/p>\n

0-4 Go<\/p>\n

245,76 Mo<\/p>\n

4%<\/p>\n

4-12 Go<\/p>\n

327,68 Mo<\/p>\n

2%<\/p>\n

12-28 Go<\/p>\n

327,68 Mo<\/p>\n

1%<\/p>\n

M\u00e9moire restante (100 Go)<\/p>\n

1024 Mo<\/p>\n

\nEn g\u00e9n\u00e9ral, pour les environnements de production, seul un \u00e9tat \u00e9lev\u00e9 peut \u00eatre consid\u00e9r\u00e9 comme normal. Pour les environnements de test et de d\u00e9veloppement, les \u00e9tats clair \/ doux peuvent \u00eatre acceptables. Si la m\u00e9moire vive restante sur l'h\u00f4te est inf\u00e9rieure \u00e0 64 % de MinFree, il est certain que les VMs qui fonctionnent dessus rencontrent des probl\u00e8mes de performance.<\/p>\n

Dans chaque \u00e9tat, des techniques sp\u00e9cifiques de reclamation de m\u00e9moire sont appliqu\u00e9es, commen\u00e7ant par le TPS, qui impacte pratiquement pas la performance des VM, jusqu'au Swapping. Je vais vous en dire plus \u00e0 ce sujet. <\/p>\n

Transparent Page Sharing (TPS).<\/b> Le TPS est, en gros, la d\u00e9duplication des pages de m\u00e9moire vive des machines virtuelles sur le serveur.<\/p>\n

ESXi recherche des pages de m\u00e9moire vive identiques des machines virtuelles, en calculant et en comparant la somme de contr\u00f4le des pages, et supprime les duplicatas de pages en les rempla\u00e7ant par des r\u00e9f\u00e9rences \u00e0 une seule et m\u00eame page dans la m\u00e9moire physique du serveur. En cons\u00e9quence, la consommation de m\u00e9moire physique est r\u00e9duite et il est possible d'atteindre un certain surallocation de m\u00e9moire pratiquement sans baisse de performance.<\/p>\n

\"Analyse
\nSource<\/a><\/noindex><\/p>\n

Ce m\u00e9canisme ne fonctionne que pour des pages de m\u00e9moire de taille 4 Ko (petites pages). Les pages de 2 Mo (grandes pages) ne sont m\u00eame pas tent\u00e9es d'\u00eatre d\u00e9dupliqu\u00e9es par l'hyperviseur : la probabilit\u00e9 de trouver des pages identiques de cette taille est faible.<\/p>\n

Par d\u00e9faut, ESXi alloue de la m\u00e9moire aux grandes pages. La fragmentation des grandes pages en petites pages commence lorsque le seuil de l'\u00e9tat High est atteint et se produit de mani\u00e8re obligatoire quand l'\u00e9tat Clear est atteint (voir le tableau des \u00e9tats de l'hyperviseur).<\/p>\n

Cependant, si vous souhaitez que le TPS commence \u00e0 fonctionner sans attendre le remplissage de la m\u00e9moire de l'h\u00f4te, vous devez d\u00e9finir la valeur dans les options avanc\u00e9es ESXi \u201cMem.AllocGuestLargePage\u201d<\/i> \u00e0 0 (par d\u00e9faut 1). L'allocation de grandes pages de m\u00e9moire pour les machines virtuelles sera alors d\u00e9sactiv\u00e9e.<\/p>\n

Depuis d\u00e9cembre 2014, dans toutes les versions d'ESXi, le TPS entre les VM est d\u00e9sactiv\u00e9 par d\u00e9faut, car une vuln\u00e9rabilit\u00e9 a \u00e9t\u00e9 trouv\u00e9e, permettant th\u00e9oriquement d'acc\u00e9der \u00e0 la m\u00e9moire d'une autre VM depuis une seule VM. Plus de d\u00e9tails ici. Je n'ai pas rencontr\u00e9 d'informations sur la mise en \u0153uvre pratique de l'exploitation de la vuln\u00e9rabilit\u00e9 TPS.<\/p>\n

La politique du TPS est contr\u00f4l\u00e9e via l'option avanc\u00e9e \u201cMem.ShareForceSalting\u201d<\/i> dans ESXi :
\n0 \u2014 TPS Inter-VM. Le TPS fonctionne pour les pages de diff\u00e9rentes VM ;
\n1 \u2013 TPS pour les VM avec la m\u00eame valeur \u201csched.mem.pshare.salt\u201d dans le VMX ;
\n2 (par d\u00e9faut) \u2013 TPS Intra-VM. Le TPS fonctionne pour les pages \u00e0 l'int\u00e9rieur d'une VM.<\/p>\n

Il a clairement du sens de d\u00e9sactiver les grandes pages et d'activer le TPS Inter-VM sur des bancs d'essai. Cela peut aussi \u00eatre utilis\u00e9 pour des environnements avec un grand nombre de VM similaires. Par exemple, sur des environnements VDI, les \u00e9conomies de m\u00e9moire physique peuvent atteindre des dizaines de pourcents. <\/p>\n

Memory Ballooning.<\/b> Le Ballooning n'est plus une technique de gestion de la m\u00e9moire virtuelle aussi inoffensive et transparente pour le syst\u00e8me d'exploitation que le TPS. Mais avec une utilisation appropri\u00e9e, il est possible de vivre et m\u00eame de travailler avec le Ballooning.<\/p>\n

Avec les VMware Tools, un pilote sp\u00e9cial appel\u00e9 Balloon Driver (ou vmmemctl) est install\u00e9 sur la VM. Lorsque l'hyperviseur manque de m\u00e9moire physique et passe en \u00e9tat Soft, l'ESXi demande \u00e0 la VM de restituer la m\u00e9moire RAM inutilis\u00e9e via ce Balloon Driver. Ce dernier fonctionne au niveau du syst\u00e8me d'exploitation et demande de la m\u00e9moire libre. L'hyperviseur voit quelles pages de m\u00e9moire physique sont occup\u00e9es par le Balloon Driver, retire de la m\u00e9moire \u00e0 la machine virtuelle et la renvoie \u00e0 l'h\u00f4te. Il n'y a pas de probl\u00e8mes de fonctionnement du syst\u00e8me d'exploitation, car au niveau du syst\u00e8me d'exploitation, la m\u00e9moire est occup\u00e9e par le Balloon Driver. Par d\u00e9faut, le Balloon Driver peut r\u00e9cup\u00e9rer jusqu'\u00e0 65 % de la m\u00e9moire de la VM.<\/p>\n

Si les VMware Tools ne sont pas install\u00e9s sur la VM ou si le Ballooning est d\u00e9sactiv\u00e9 (ce que je ne recommande pas, mais cela existe KB<\/a><\/noindex>:), l'hyperviseur passe imm\u00e9diatement \u00e0 des techniques de pr\u00e9l\u00e8vement de m\u00e9moire plus rigoureuses. Conclusion : assurez-vous que les VMware Tools sont install\u00e9s sur la VM.<\/p>\n

\"Analyse
\nLe fonctionnement du Balloon Driver peut \u00eatre v\u00e9rifi\u00e9 depuis le syst\u00e8me d'exploitation via VMware Tools.<\/i>.<\/p>\n

Compression de m\u00e9moire.<\/b> Cette technique est appliqu\u00e9e lorsque l'ESXi atteint l'\u00e9tat Hard. Comme son nom l'indique, l'ESXi essaie de compresser des pages de m\u00e9moire RAM de 4 Ko \u00e0 2 Ko, lib\u00e9rant ainsi un peu d'espace dans la m\u00e9moire physique du serveur. Cette technique augmente consid\u00e9rablement le temps d'acc\u00e8s au contenu des pages de m\u00e9moire de la VM, car la page doit d'abord \u00eatre d\u00e9compress\u00e9e. Parfois, il n'est pas possible de compresser toutes les pages, et le processus lui-m\u00eame prend un certain temps. Par cons\u00e9quent, cette technique n'est pas tr\u00e8s efficace en pratique.<\/p>\n

Swap de m\u00e9moire.<\/b> Apr\u00e8s une courte phase de Compression de m\u00e9moire, l'ESXi passe pratiquement in\u00e9vitablement (si les VMs n'ont pas \u00e9t\u00e9 d\u00e9plac\u00e9es vers d'autres h\u00f4tes ou ne sont pas \u00e9teintes) au Swap. Et si la m\u00e9moire restante est tr\u00e8s faible (\u00e9tat Bas), l'hyperviseur cesse \u00e9galement d'allouer des pages de m\u00e9moire \u00e0 la VM, ce qui peut provoquer des probl\u00e8mes dans les syst\u00e8mes d'exploitation invit\u00e9s de la VM.<\/p>\n

Voici comment fonctionne l'\u00e9change. Lorsqu'une machine virtuelle est allum\u00e9e, un fichier avec l'extension .vswp est cr\u00e9\u00e9 pour elle. Sa taille est \u00e9gale \u00e0 la m\u00e9moire vive non r\u00e9serv\u00e9e de la VM : c'est la diff\u00e9rence entre la m\u00e9moire configur\u00e9e et la m\u00e9moire r\u00e9serv\u00e9e. Lorsque l'\u00e9change est actif, ESXi d\u00e9charge les pages de m\u00e9moire de la machine virtuelle dans ce fichier et commence \u00e0 travailler avec lui au lieu de la m\u00e9moire physique du serveur. Bien s\u00fbr, cette \"m\u00e9moire\" est plusieurs ordres de grandeur plus lente que la v\u00e9ritable m\u00e9moire, m\u00eame si le fichier .vswp se trouve sur un stockage rapide.<\/p>\n

Contrairement \u00e0 Ballooning, o\u00f9 des pages non utilis\u00e9es sont retir\u00e9es \u00e0 la VM, lors de l'\u00e9change, des pages qui sont activement utilis\u00e9es par le syst\u00e8me d'exploitation ou les applications \u00e0 l'int\u00e9rieur de la VM peuvent \u00eatre d\u00e9plac\u00e9es sur le disque. En cons\u00e9quence, la performance de la VM chute jusqu'\u00e0 devenir compl\u00e8tement gel\u00e9e. La VM fonctionne formellement et peut au moins \u00eatre correctement arr\u00eat\u00e9e depuis le syst\u00e8me d'exploitation. Si vous \u00eates patient \ud83d\ude09<\/p>\n

Si la VM a commenc\u00e9 \u00e0 utiliser l'\u00e9change, c'est une situation anormale qu'il est pr\u00e9f\u00e9rable d'\u00e9viter autant que possible.<\/p>\n

Les principaux compteurs de performance de la m\u00e9moire de la machine virtuelle<\/h3>\n

\nNous sommes enfin arriv\u00e9s au principal. Pour surveiller l'\u00e9tat de la m\u00e9moire dans la VM, il existe les compteurs suivants :<\/p>\n

Actif<\/b> \u2014 indique le volume de m\u00e9moire vive (Ko) auquel la VM a eu acc\u00e8s lors de la p\u00e9riode de mesure pr\u00e9c\u00e9dente.<\/p>\n

Utilisation<\/b> \u2014 m\u00eame chose que Active, mais en pourcentage de la m\u00e9moire vive configur\u00e9e de la VM. Calcul\u00e9 selon la formule suivante : active \u00f7 taille de la m\u00e9moire vive configur\u00e9e de la machine virtuelle.
\nUne forte utilisation et activit\u00e9 ne sont pas toujours des indicateurs de probl\u00e8mes de performance de la VM. Si la VM utilise agressivement la m\u00e9moire (au moins, y acc\u00e8de), cela ne signifie pas qu'il lui manque de la m\u00e9moire. C'est plut\u00f4t un signal pour examiner ce qui se passe dans le syst\u00e8me d'exploitation.
\nIl existe une alarme standard pour l'utilisation de la m\u00e9moire pour la VM :<\/p>\n

\"Analyse
\n
\nPartag\u00e9<\/b> \u2014 volume de m\u00e9moire vive de la VM, d\u00e9dupliqu\u00e9e \u00e0 l'aide de TPS (\u00e0 l'int\u00e9rieur de la VM ou entre les VMs).<\/p>\n

Accord\u00e9<\/b> \u2014 volume de m\u00e9moire physique de l'h\u00f4te (Ko) qui a \u00e9t\u00e9 allou\u00e9 \u00e0 la VM. Inclut la m\u00e9moire partag\u00e9e.<\/p>\n

Consomm\u00e9<\/b> (Accord\u00e9 \u2014 Partag\u00e9) \u2014 volume de m\u00e9moire physique (Ko) que la VM consomme de l'h\u00f4te. N'inclut pas la m\u00e9moire partag\u00e9e.<\/p>\n

Si une partie de la m\u00e9moire de la VM est fournie non \u00e0 partir de la m\u00e9moire physique de l'h\u00f4te, mais \u00e0 partir d'un fichier de swap ou de la m\u00e9moire retir\u00e9e \u00e0 la VM via le Balloon Driver, ce volume n'est pas inclus dans les valeurs Accord\u00e9 et Consomm\u00e9.
\nDes valeurs \u00e9lev\u00e9es pour Granted et Consumed sont tout \u00e0 fait normales. Le syst\u00e8me d'exploitation prend progressivement de la m\u00e9moire 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\u00e9moire configur\u00e9e et y demeurent.<\/p>\n

Z\u00e9ro<\/b> - volume de la m\u00e9moire vive de la VM (Ko), qui contient des z\u00e9ros. Cette m\u00e9moire est consid\u00e9r\u00e9e par l'hyperviseur comme libre et peut \u00eatre attribu\u00e9e \u00e0 d'autres machines virtuelles. Une fois que le syst\u00e8me d'exploitation invit\u00e9 a \u00e9crit quelque chose dans cette m\u00e9moire mise \u00e0 z\u00e9ro, elle passe \u00e0 Consumed et ne revient plus.<\/p>\n

Reserved Overhead<\/b> - volume de la m\u00e9moire vive de la VM (Ko) r\u00e9serv\u00e9 par l'hyperviseur pour le fonctionnement de la VM. C'est un petit volume, mais il doit absolument \u00eatre disponible sur l'h\u00f4te, sinon la VM ne d\u00e9marrera pas.<\/p>\n

Balloon<\/b> - volume de la m\u00e9moire vive (Ko) pr\u00e9lev\u00e9 sur la VM \u00e0 l'aide du Balloon Driver.<\/p>\n

Compressed<\/b> - volume de la m\u00e9moire vive (Ko) qui a pu \u00eatre compress\u00e9.<\/p>\n

Swapped<\/b> - volume de la m\u00e9moire vive (Ko) qui, en raison du manque de m\u00e9moire physique sur le serveur, a \u00e9t\u00e9 d\u00e9plac\u00e9 sur le disque.
\nBalloon et les autres compteurs des techniques de r\u00e9cup\u00e9ration de m\u00e9moire sont \u00e0 z\u00e9ro.<\/p>\n

Voici \u00e0 quoi ressemble le graphique avec les compteurs de m\u00e9moire d'une VM fonctionnant normalement avec 150 Go de m\u00e9moire vive.<\/p>\n

\"Analyse
\n
\nSur le graphique ci-dessous, la VM pr\u00e9sente des probl\u00e8mes \u00e9vidents. En dessous du graphique, il est clair que toutes les techniques de gestion de m\u00e9moire d\u00e9crites ont \u00e9t\u00e9 utilis\u00e9es pour cette VM. Le Balloon pour cette VM est nettement sup\u00e9rieur \u00e0 Consumed. En fait, la VM est plus probablement morte que vivante. <\/p>\n

\"Analyse
\n<\/p>\n

ESXTOP<\/h3>\n

\nComme pour le CPU, si nous voulons \u00e9valuer rapidement la situation sur l'h\u00f4te, ainsi que sa dynamique par intervalles de 2 secondes, il est conseill\u00e9 d'utiliser ESXTOP.<\/p>\n

L'\u00e9cran ESXTOP pour la m\u00e9moire est appel\u00e9 avec la touche \u00ab m \u00bb et ressemble \u00e0 ceci (les champs B,D,H,J,K,L,O ont \u00e9t\u00e9 s\u00e9lectionn\u00e9s) :<\/p>\n

\"Analyse
\n
\nLes param\u00e8tres suivants seront int\u00e9ressants pour nous : <\/p>\n

Mem overcommit avg<\/b> - la valeur moyenne de sur-allocation de m\u00e9moire sur l'h\u00f4te sur 1, 5 et 15 minutes. Si elle est sup\u00e9rieure \u00e0 z\u00e9ro, cela peut \u00eatre un motif d'examen de la situation, mais ce n'est pas toujours un indicateur de probl\u00e8me.<\/p>\n

Dans les lignes PMEM\/MB<\/b> et VMKMEM\/MB<\/b> - informations sur la m\u00e9moire physique du serveur et la m\u00e9moire disponible pour le VMkernel. De ce qui est int\u00e9ressant, on peut voir la valeur minfree (en Mo), l'\u00e9tat de la m\u00e9moire de l'h\u00f4te (dans notre cas, \u00e9lev\u00e9).<\/p>\n

Dans la ligne NUMA\/MB<\/b> on peut voir la r\u00e9partition de la m\u00e9moire vive selon les n\u0153uds NUMA (sockets). Dans cet exemple, la r\u00e9partition est in\u00e9gale, ce qui n'est pas vraiment id\u00e9al.<\/p>\n

Voici les statistiques globales du serveur concernant les techniques de r\u00e9cup\u00e9ration de m\u00e9moire :<\/p>\n

PSHARE\/MO<\/b> \u2014 c'est la statistique TPS ;<\/p>\n

SWAP\/MO<\/b> \u2014 la statistique d'utilisation du Swap ;<\/p>\n

ZIP\/MO<\/b> \u2014 la statistique de compression des pages m\u00e9moire ;<\/p>\n

MEMCTL\/MO<\/b> \u2014 la statistique d'utilisation du Balloon Driver.<\/p>\n

Pour chaque VM, nous pourrions \u00eatre int\u00e9ress\u00e9s par les informations suivantes. J'ai cach\u00e9 les noms des VM pour ne pas d\u00e9ranger le public :). Si la m\u00e9trique ESXTOP est similaire au compteur dans vSphere, je fournis le compteur correspondant. <\/p>\n

MEMSZ<\/b> \u2014 volume de la m\u00e9moire configur\u00e9 sur la VM (Mo).
\nMEMSZ = GRANT + MCTLSZ + SWCUR + untouched.<\/p>\n

GRANT<\/b> \u2014 Granted en Mo.<\/p>\n

TCHD<\/b> \u2014 Actif en Mo.<\/p>\n

MCTL?<\/b> \u2014 si le Balloon Driver est install\u00e9 sur la VM.<\/p>\n

MCTLSZ<\/b> \u2014 Balloon en Mo.<\/p>\n

MCTLGT<\/b> \u2014 volume de m\u00e9moire vive (Mo) qu'ESXi souhaite retirer de la VM via le Balloon Driver (Memctl Target).<\/p>\n

MCTLMAX<\/b> \u2014 volume maximal de m\u00e9moire vive (Mo) qu'ESXi peut retirer de la VM via le Balloon Driver.<\/p>\n

SWCUR<\/b> \u2014 volume actuel de m\u00e9moire vive (Mo) allou\u00e9 \u00e0 la VM \u00e0 partir du fichier Swap. <\/p>\n

SWGT<\/b> \u2014 volume de m\u00e9moire vive (Mo) qu'ESXi souhaite allouer \u00e0 la VM \u00e0 partir du fichier Swap (Swap Target).<\/p>\n

Avec ESXTOP, on peut \u00e9galement voir des informations plus d\u00e9taill\u00e9es sur la topologie NUMA de la VM. Pour cela, il faut s\u00e9lectionner les champs D,G :<\/p>\n

\"Analyse
\n
\nNHN<\/b> \u2013 Noeuds NUMA sur lesquels la VM est situ\u00e9e. On peut ainsi remarquer imm\u00e9diatement les VM larges qui ne tiennent pas sur un seul noeud NUMA.<\/p>\n

NRMEM<\/b> \u2013 combien de m\u00e9gaoctets de m\u00e9moire la VM prend depuis un noeud NUMA distant.<\/p>\n

NLMEM<\/b> \u2013 combien de m\u00e9gaoctets de m\u00e9moire la VM prend depuis un noeud NUMA local.<\/p>\n

N%L<\/b> \u2013 pourcentage de m\u00e9moire de la VM sur le noeud NUMA local (si inf\u00e9rieur \u00e0 80 % \u2014 des probl\u00e8mes de performance peuvent survenir).<\/p>\n

M\u00e9moire sur l'hyperviseur<\/h3>\n

\nAlors que les compteurs de CPU de l'hyperviseur ne sont g\u00e9n\u00e9ralement pas tr\u00e8s int\u00e9ressants, la situation avec la m\u00e9moire est diff\u00e9rente. Une utilisation \u00e9lev\u00e9e de la m\u00e9moire sur la VM ne signifie pas toujours un probl\u00e8me de performance, mais une utilisation \u00e9lev\u00e9e de la m\u00e9moire sur l'hyperviseur d\u00e9clenche les techniques de gestion de la m\u00e9moire et cause des probl\u00e8mes de performance sur la VM. Il faut surveiller les alarmes d'utilisation de la m\u00e9moire de l'h\u00f4te et \u00e9viter que les VM n'entrent dans le Swap.<\/p>\n

\"Analyse
\n
\n\"Analyse
\n<\/p>\n

Unsquer<\/h3>\n

\nSi la VM est entr\u00e9e dans le Swap, ses performances diminuent fortement. Les traces de Ballooning et de compression disparaissent rapidement apr\u00e8s l'apparition de m\u00e9moire vive libre sur l'h\u00f4te, mais la machine virtuelle ne se d\u00e9p\u00eache pas de revenir du Swap \u00e0 la m\u00e9moire vive du serveur.
\nJusqu'\u00e0 la version ESXi 6.0, la seule m\u00e9thode fiable et rapide pour sortir une VM du Swap \u00e9tait le red\u00e9marrage (plus pr\u00e9cis\u00e9ment, l'arr\u00eat\/red\u00e9marrage du conteneur). \u00c0 partir de la version ESXi 6.0, une m\u00e9thode, bien que non officielle, mais fonctionnelle et fiable, a \u00e9t\u00e9 introduite pour sortir une VM du Swap. Lors d'une des conf\u00e9rences, j'ai eu l'occasion de discuter avec l'un des ing\u00e9nieurs de VMware en charge de l'ordonnanceur CPU. Il a confirm\u00e9 que cette m\u00e9thode est tout \u00e0 fait op\u00e9rationnelle et s\u00fbre. \u00c0 notre exp\u00e9rience, il n'y a eu aucun probl\u00e8me \u00e0 ce sujet.<\/p>\n

Commandes pour sortir une VM du Swap d\u00e9crit<\/a><\/noindex> Duncan Epping. Je ne vais pas r\u00e9p\u00e9ter une description d\u00e9taill\u00e9e, je vais simplement donner un exemple de son utilisation. Comme vous pouvez le voir sur la capture d'\u00e9cran, apr\u00e8s un certain temps, la commande mentionn\u00e9e fait dispara\u00eetre le Swap de la VM.<\/p>\n

\"Analyse
\n<\/p>\n

Conseils pour g\u00e9rer la m\u00e9moire vive sur ESXi<\/h3>\n

\nEnfin, voici quelques conseils qui vous aideront \u00e0 \u00e9viter des probl\u00e8mes de performance des VM dus \u00e0 la m\u00e9moire vive :<\/p>\n