Comments on: [PSH] The big -overcommit- score

By: Hyper-V, “it’sdagood”

Hyper-V, “it’sdagood” — Mon, 20 Feb 2012 09:50:04 +0000

[...] What we liked the most was improved performance with support for dynamic memory, which “cleverly” talk on the equivalent (on a far principle) to the ballooning, whereas in our opinion, performance increase should rather address th mechanisms of low layer memory management, like TPS, Memory Compression, Swaping, features that have direct impact on financial cost of memory hardware (just read the very good post from hypervisor about the gain offered by theses VMware features : [PSH] The big -overcommit- score) [...]

By: Hyper-V, « saylebien »

Hyper-V, « saylebien » — Mon, 20 Feb 2012 09:27:28 +0000

[...] Là ce qui nous a le plus amusé a été le improved performance with support for dynamic memory, qui parle « habilement » de l’équivalent (sur un principe lointain) au ballooning, alors qu’à notre avis, une augmentation des performances devrait plutôt aborder des mécanismes de gestion de mémoire en couche basse, comme TPS, Memory Compression, Swaping, des fonctionnalités qui ont un impact direct sur le coût financier matériel au niveau de la mémoire (il n’y a qu’a lire le très bon billet d’hypervisor sur le gain qu’offre ces fonctionnalités VMware : [PSH] The big -overcommit- score) [...]

By: NiTRo

NiTRo — Tue, 10 Jan 2012 14:36:10 +0000

l’overhead ne dépend que du nombre de vcpu et de la quantité de ram allouée (et de l’option hot add mais c’est un détail)

By: Tntteam

Tntteam — Tue, 10 Jan 2012 14:30:20 +0000

Ok thanks, je comprenais pas pourquoi mes résultats étaient si éloignés des votres (en %).
Oui on taille toutes les VM juste comme il faut, 0 résa 0 overcommit, ça réduit l’overhead.

By: NiTRo

NiTRo — Tue, 10 Jan 2012 13:30:42 +0000

@Tntteam Ca veut dire que tu fais 25Go d’économie sur 300Go, donc soit tu fais beaucoup de réservation soit tu fais peu d’overcommit

By: Tntteam

Tntteam — Tue, 10 Jan 2012 09:59:30 +0000

Ah ok, bon ben voila mes résultats :

Get-View -ViewType VirtualMachine -Property Config,Summary,Runtime|?{$_.Runtime.PowerState -eq “PoweredOn” -and $_.Runtime.ConnectionState -eq “connected”}|%{$_.Config.Hardware.MemoryMB}|Measure-Object -Sum

Count : 104
Average : 240,384615384615
Sum : 25000
Maximum : 3142
Minimum : -170
Property :

Count : 104
Average :
Sum : 295848
Maximum :
Minimum :
Property :

Incompréhensible pour moi o_O

By: NiTRo

NiTRo — Mon, 09 Jan 2012 11:23:33 +0000

@VMprisme Merci pour ton feedback

@Tntteam C’est tout à fait normal si ces vm consomment toute la ram qui leur est allouée car avec l’overhead en plus ça te fait une consommation supérieure à la valeur allouée. Ça arrive souvent sur des serveurs à base de Nehalem avec la VMM par défaut à cause des large pages par exemple.

By: Tntteam

Tntteam — Mon, 09 Jan 2012 10:53:27 +0000

J’ai un peu de mal à avaler que ce calcul là soit négatif sur beaucoup de VM :

$_.Config.Hardware.MemoryMB – $_.Summary.QuickStats.HostMemoryUsage

Ca fausse un peu le résultat final non ?

By: VMprisme

VMprisme — Mon, 09 Jan 2012 09:29:05 +0000

Un petit test sur ma plateforme me donne 1To d’économisé pour 3To total sur une infra de 1100 VMs.

Il est vrai qu’il est interréssant d’avoir des chiffres à donner c’est toujours plus parlant que des ” j’estime que … “