Vom kleinen vServer, der auch mal etwas machen wollte
Verfasst: 11.04.2017, 07:50
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.
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.