Différences entre les versions de « Esxi Gestion Memoire »

De BlaxWiki
Aller à la navigationAller à la recherche
 
Ligne 3 : Ligne 3 :
Tout au long du développe­ment des ver­sions de l’hyperviseur, VMware a inté­gré dif­férents types de fonc­tion­nal­ités, afin opti­miser l’utilisation de la mémoire et surtout de gérer l’espace mémoire physique en cas de con­tention suite, par exem­ple, à une perte de plusieurs serveurs ESXi.
Tout au long du développe­ment des ver­sions de l’hyperviseur, VMware a inté­gré dif­férents types de fonc­tion­nal­ités, afin opti­miser l’utilisation de la mémoire et surtout de gérer l’espace mémoire physique en cas de con­tention suite, par exem­ple, à une perte de plusieurs serveurs ESXi.


[[Fichier:./BENPERSO/files/Techno_memory1.png|400px|thumb|center]]
[[Fichier:Techno_memory1.png|400px|thumb|center]]


* Pre­mière tech­nolo­gie le TPS (Trans­par­ent Page Shar­ing) qui va être capa­ble d’analyser les pag­i­na­tions mémoires des VMs et con­solider les pag­i­na­tions iden­tiques en une. Elle se base sur  
* Pre­mière tech­nolo­gie le TPS (Trans­par­ent Page Shar­ing) qui va être capa­ble d’analyser les pag­i­na­tions mémoires des VMs et con­solider les pag­i­na­tions iden­tiques en une. Elle se base sur  

Version actuelle datée du 30 décembre 2020 à 11:02

Cette page concerne la gestion de la mémoire sous Esxi 5.0 (tiré de cette page)

Tout au long du développe­ment des ver­sions de l’hyperviseur, VMware a inté­gré dif­férents types de fonc­tion­nal­ités, afin opti­miser l’utilisation de la mémoire et surtout de gérer l’espace mémoire physique en cas de con­tention suite, par exem­ple, à une perte de plusieurs serveurs ESXi.

Erreur lors de la création de la vignette : Fichier manquant
  • Pre­mière tech­nolo­gie le TPS (Trans­par­ent Page Shar­ing) qui va être capa­ble d’analyser les pag­i­na­tions mémoires des VMs et con­solider les pag­i­na­tions iden­tiques en une. Elle se base sur

des pages de 2MB ou de 4KB lors qu’il y a une trop grande fragmentation.

  • Sec­onde tech­nolo­gie, le Bal­loon­ing, qui va forcer l’OS de la VM à swap­per dans son vmdk, grâce à un dri­ver, inté­gré dans les VMware Tools, qui va réclamer plus de mémoire. L’OS n’ayant

pas d’autre solu­tion que de swap­per dans son disque virtuel.

  • Troisième et nou­velle fonc­tion­nal­ité la com­pres­sion, qui va per­me­t­tre de com­presser à la hau­teur de 10 % de la mémoire physique.
  • Qua­trième et dernière fonc­tion­nal­ité le swap du VMK­er­nel. Lors du démar­rage d’une VM, un fichier swap est créé, par défaut dans le dossier du .vmx, de la taille de la mémoire allouée

moins la réser­va­tion. Ce fichier sera utiliser lorsque le VMK­er­nel a bal­looné toutes les VMs et s’il a besoin encore plus de mémoire physique à disposition. On peut égale­ment activer, dans ce cas-là, le swap cache sur SSD afin de prof­iter des faibles latences de ce type de stockage.

En résumé, si vous arrivé à ce point, soit votre archi­tec­ture est très mal con­cep­tu­al­isée, soit vous avez mis des lim­i­ta­tions sur les ressources mémoires de vos VMs…

Pour d'autres explications et le pdf de l'image ci-dessous : http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2017642

Erreur lors de la création de la vignette : Fichier manquant

Il y a égale­ment des expli­ca­tions liées aux graphiques dans le vCen­ter :

Erreur lors de la création de la vignette : Fichier manquant

Et à l’interprétation de la com­mande ESXTOP :

Erreur lors de la création de la vignette : Fichier manquant