Memory Overcommitment, Ballooning, Swapping etc.

[pirx]

Hallo,

bisher haben wir in unserer VMware Umgebung auf Memory Overcommitment im großen Stiel verzichtet. D.h. wir haben versucht nicht mehr vRAM an die VMs zu vergeben als physisch in den Hosts verbaut ist. Dazu kommt das Ziel den Ausfall eines Host abfangen zu können.

Der aktuelle Cluster setzt sich zusammen aus 10 Hosts a 256 GB RAM. Soll der Ausfall von einem Host abgefangen werden, sollten also nicht mehr als ~2,25 TB den VMs zugeteilt werden. Nun kam es zu Verzögerungen mit dem Aufbau eines neuen Cluster und der aktuelle Cluster muss nun etwas mehr Last tragen als geplant. Wenn ich mir die Zahlen im vCOPS und vCenter anschaue, werde ich aber nicht ganz schlau, wie die aktuelle Lage tatsächlich ist.

Zum Einen weiß ich, dass die VMs bei uns i.d.R. zu groß angelegt werden. Dies kommt aus den Anforderungen des Fachbereichs und wir haben praktisch keine Möglichkeit ein "right sizing" durchzuführen. Daher sieht man an den Graphen, das active RAM im Cluster nur bei rund 300-350 GB liegt.

Letzte Woche habe ich Patches auf den Hosts eingespielt, wobei immer ein Host aus dem Cluster in Maint. Mode gesetzt und rebootet wurde (+FW Updates). Dabei habe ich mir die MEM Statistiken angeschaut und war überrascht, dass neben Ballooning auch Hypervisor Swapping eingesetzt hat - was ja böse ist Dazu gab es entsprechende Warnungen vom vCenter.

Code: Alles auswählen

Alarm Definition:
([Yellow metric Is above 90%; Red metric Is above 95%])
 
Current values for metric/state:
 Metric Memory Usage = 98%


Mir ist nicht klar warum Swapping eingesetzt hat. Aus meiner Sicht hätten genug Reserven noch zur Verfügung gestanden, Consumed RAM war immer unter Total Capacity. Oder der benötigte Speicher hätte komplett durch Ballooning frei gemacht werden können.

Mir geht es um 3 Punkte:

- warum wurde in der Situation geswappt?
- wie muss ich die aktuelle Overcommitment Situation einschätzen?
- nach was schaue ich in der Zukunft? Ich habe bisher gedacht, dass das active RAM der Wert ist, der Überwacht werden soll. Das würde aber bedeuten, dass ich z.B. in der Cluster Ressorce Ansicht bei allen Host bei 100% wäre und permanent Alarme aktiv wären.



Cluster Ressourcen Übersicht:

http://s7.directupload.net/file/d/3284/qpp2x2yh_png.htm

Memory Graphen:

http://s14.directupload.net/file/d/3284 ... 2c_png.htm

[JMcClane]

Active RAM ist ein Wert der angibt wie viele Bits in Zeitraum X bewegt wurden. Da die meisten Betriebssysteme aber auch so noch Caches einsetzen und Programme auch im Speicher verbleiben die gerade nichts zu tun haben, sagt der Wert nur etwas über die RAM Aktivität, aber nicht über die Belegung aus.
Memory Usage auf dem Host sagt wie viel RAM dein Host belegt hat. Wenn der Wert über 90% liegt dauert es nicht mehr lange bis zum Balooning und Swapping.

[MarcelMertens]

Kannst du mal schauen wie hoch deine SwapIn Rate war?
Einmal geswappter Speicher bleibt solange auf der Disk bis er wieder benötigt wurde. Da das bei dir wohl nicht der Fall ist, geht auch der SwapOut Counter nicht zurück.

Was ich nicht verstehe wieso die Spikes (immerhin >250-300GB) nach Unten bei Consumed/Granted Memory genau dann auftreten wenn ein Host neugebootet wird.
Normalerweise dürfte sich der Wert bei einem Hostreboot gar nicht verändern. Oder wurde zum Hostreboot auch VMs heruntergefahren?

Einzige Erklärung die ich derzeit habe:
- Du hast so wie es aussieht teilweise 2 Host gleichzeitig im Wartungsmodus gehabt. Zeigen zumindest die drei Unterschiedlichen Level im Provisioned/und Total Diagramm.
(2,7TB -> Kein Host, 2,4TB -> Ein Host -> 2,2TB -> Zwei Hosts)
Ballooning und Swapping erfolgt fast immer bevor ein zweiter Host im Wartungsmodus war.

[pirx]

Swap In Rate:

http://s14.directupload.net/file/d/3284 ... ty_png.htm

VMs wurden nicht rebootet, es waren ganz normale vMotion Aktionen um die VMs der Hosts die in Maint. Mode versetzt wurden zu verschieben.

Das 2 Hosts gleichzeitig im Maint. Mode waren kann ich mir nicht vorstellen, ich habe immer einen nach dem anderen gepatcht und bin erst in den Update Tab im vSphere Client gegangen, nach dem der andere Host wieder oben war und VMs schon wieder durch DRS zurückgeschoben wurden. Muss man vielleicht nach 5 extra Denkminuten einlegen? Nomalerweise führe ich das Update für einen kompletten Cluster aus, dann wird ja ein Host nach dem anderen gepatcht. Durch die Firmware Updates habe ich das hier manuell durchgeführt.

Die Swap Out Peaks decken sich zeitlich auch nicht mit dem "absacken" des Provisioned/Total RAM.

http://s7.directupload.net/file/d/3284/9prgjb5w_png.htm

[MarcelMertens]

Wenn man dem Graph trauen kann waren bei der gelben Markierung jeweils zwei Hosts im Maint. Mode. anders kann ich mir das nicht erklären:

[pirx]

Wenn man dem Graph trauen kann waren bei der gelben Markierung jeweils zwei Hosts im Maint. Mode. anders kann ich mir das nicht erklären:

Erklären kann ich es mir auch nicht, aber die Swap Out Rate ist davor schon angestiegen. Von daher muss es davon schon eine Ursache für das Swapping gegeben haben.

[pirx]

Ups, irgendwas stimmt mit der zeitlichen Darstellung bei den Graphen nicht. Das ganze noch mal. Ändert aber nichts daran, dass Swapping eingesetzt hat bevor 2 Hosts vermeintlich in Main.Mode versetzt wurden.