Vom kleinen vServer, der auch mal etwas machen wollte

[~thc]

Seit ich auf einem ESXi 5.5 neben den zwei Hauptservern (Win2K8R2 und Debian) einen dritten, "kleineren" Server für eine MS SQL Datenbankanwendung installiert hatte, plagten mich Performancesorgen des neuen Servers. Die Anmeldung selbst, der Start der Einzelplatz-Applikation, der Start des SQL-Managements - alles dauerte manchmal ewig. Und manchmal nicht.

Zunächst hatte ich angenommen, dass die Energie-Einstellungen des Hosts und die Win2K12R2-VM sich nicht vertragen. Nach dem Umstellen schien der Server auch flüssig zu laufen, aber da hatte ich mich zu früh gefreut.

Schließlich habe ich in der VM den Ressourcenmonitor und auf dem ESXi die Performacne-Diagramme mitlaufen lassen. Dabei sah ich dann, dass die Co-Stop-Werte durch die Decke gingen. Also hatte ich das Multicore-vCPU-Scheduling im Verdacht. Zumal ich auf einem anderen 5.0 zwei Single-vCPU-Win8.1-VMs habe, die nicht solche Zicken machen. Ich habe die VM auf eine vCPU umgestellt und dachte, so nun habe ich es aber...

Nein, hatte ich nicht. Das Anmelden und Starten dauert ewig - und dann den ganzen Tag über nicht mehr. Manchmal war es auch am nächsten Tag noch schnell. Aber spätestens nach zwei oder drei Tagen dauerte es wieder ewig.

Schließlich habe ich überlegt, woran mich das Erscheinungsbild am ehesten erinnert. Früher konnte man unter Windows 3.1 und 95 mehr Anwendungen laden, als der Hauptspeicher eigentlich her gab. Beim Task wechseln auf eine Anwendung, die schon auf die Platte ausgelagert worden war, dauerte es ewig, bis sie zur Verfügung stand.

Bei 32 GB vorhandenem pRAM hatte ich den beiden großen VMs je 16 GB vRAM gegönnt - und der kleinen auch 8 GB. Durchaus mit der Absicht, dass der ESXi sich das mit dem Overcommitment schon zurechtlegt. Tut er auch - nur nicht so, wie ich es erwartet hatte. Im "esxtop" konnte ich es in den Memory-Statistiken unter "SWTGT" und "SWCUR" sehen.

Die beiden großen VMs drängten im Alltag die kleine nach und nach aus dem pRAM - da die Linux-VM das vRAM zum Teil als Disk-Buffer nutzt, hatte ich angenommen, dass die kleine SQL-VM sich dagegen durchsetzt. Im Alltag trat aber genau das Gegenteil ein. Das Einlesen aus der Swapdatei führte dann zu den hohen Co-Stop-Werten.

Ich habe der Linux-VM 4 GB weggenommen - damit kann die kleine SQL-VM nicht mehr so weit aus dem pRAM gedrängt werden. Und zwei vCPUs hat sie jetzt auch wieder.

Wenn man Memory-Overcommitment einsetzt, sollte man bedenken, wie oft alle VMs das vRAM nutzen und ob die möglicherweise auf die Platte ausgelagerten vRAM-Bereiche im Alltag nicht stören.

[Supi]

Ohne Angaben zu pCPU und vCPU des Serves und der VM's ist es schwierig, das weiter zu kommentieren.
(Ist es denn überhaupt gewollt?)
Zum Memomey Overcommitment / TPS:
https://lonesysadmin.net/2015/02/01/lat ... watch-ram/

Das ist per Default seit 2015 nicht mehr aktiv. Auch durch die Reduktion sind also 40GB bzw. 36 definiert, bei 32GB vorhandenen RAM.
Gehe erst mal davon aus, dass der ESXi auch mal 1-1,5GB intern benötigt.
Rund sind also nur 30GB verfügbar. Wo soll der ESXi also viel Ram umverteilen? Bei 3 VM's?
Die VM Tools werden in allen 3 VM's versuchen, Ram freizumachen, damit kein Swapping mehr nötig ist. Und hier schein der die VM mit dem SQL Server am ehesten zu sagen, ok, der SQL kann vom Ram reduzieren, mache ich.
So ganz einfach ausgedrückt.

Teste doch mal, das du max 30-32GB Ram vergibst, wie es sich da verteilt.
Ebenso nicht bei 4 pCPU einer VM 4cpu's geben.

[~thc]

Erst mal zu Klärung: Das Problem an sich - die Performance der kleinen SQL-VM - ist gelöst. Durch die Beschränkung der beiden großen VMs auf 28 GB vRAM bekommt die kleine genug ab.

Ich wollte nur dokumentieren, dass ein Memory Overcommitment auch anders funktionieren kann, als man es erwartet. Und Auswirkungen haben kann (Co-Stop-Spitzen), die man eher nicht erwartet.

Wenn man die Verteilung von pRAM dem ESXi mit seiner Logik überlässt, kann es sein, dass er diesen Job (durchaus nachvollziehbar) anders macht, als man es gerne hätte.