Hatte letzthin eine interessante Diskussion um welchen Faktor man die echten Cores in einem Host überprovisionieren kann. Ich dachte ich habe mal gelesen, dass Qemu das sehr gut kann. Mein Gesprächspartner meinte, dass ab einer Überprovisionierung von Faktor vier die Probleme anfangen. Wir selber haben einen Cluster mit drei Hosts mit AMD Epic Rome 32 Core mit je einem TB Memory. Darauf laufen 450 VM's und generieren einen Load von ca. 30% auf der CPU wie auch auf dem Memory. Wenn ich das jetzt mal hoch rechnen, bin ich schon sehr nach an der Faktor vier Grenze. Wie seht ihr das?
Überprovisionierungsrate CPU
- Thread starter Winet.maier
- Start date
qemu nutzt du nur wenn du nicht das CPU Profil host benutzt. Bei host ist es nativ KVM und der CPU Scheduler ist schon etwas besser als der vom ESXi.
Das mit Faktor 4 ist recht pauschal und passt oft, aber in Wirklichkeit hängt das von vielen Faktoren ab.
Hast du nur 1 vCPU VMs kannst du deutlich mehr überprovisionieren als wenn du dicke VMs hast, denn jede VM reserviert die zugewiesene Menge an Cores, auch wenn z.B. nur 10MHz Last erzeugt wird. Also muss eine 8 vCPU VM auch 8 Kerne oder Threads der CPU reservieren.
Wenn du Physikalisch CPUs mit vielen Cores hast kannst du auch besser überprovisionieren, da der CPU Scheduler mehr Cores hat um den Workload zu verteilen.
Die 8 vCPU VM bringt viel mehr Ungleichgewicht und die Zuordnung bei einer 16 Core CPU als bei einer 64 Core CPU.
Bei VMware gibts da die CPU Ready Zeiten, die einem gut zeigen wenn man es übertreibt. Bei HyperV kann man sich da Werte aus dem Perfmon rauszaubern, welche aber nicht ganz so sprechend sind wie die CPU Ready.
Auf Linux mit KVM habe ich noch keinen vergleichbaren Wert zum monitoren gefunden, aber die CPU Pressure sagt dir auch wenn da zu viele Anfragen kommen.
Das mit Faktor 4 ist recht pauschal und passt oft, aber in Wirklichkeit hängt das von vielen Faktoren ab.
Hast du nur 1 vCPU VMs kannst du deutlich mehr überprovisionieren als wenn du dicke VMs hast, denn jede VM reserviert die zugewiesene Menge an Cores, auch wenn z.B. nur 10MHz Last erzeugt wird. Also muss eine 8 vCPU VM auch 8 Kerne oder Threads der CPU reservieren.
Wenn du Physikalisch CPUs mit vielen Cores hast kannst du auch besser überprovisionieren, da der CPU Scheduler mehr Cores hat um den Workload zu verteilen.
Die 8 vCPU VM bringt viel mehr Ungleichgewicht und die Zuordnung bei einer 16 Core CPU als bei einer 64 Core CPU.
Bei VMware gibts da die CPU Ready Zeiten, die einem gut zeigen wenn man es übertreibt. Bei HyperV kann man sich da Werte aus dem Perfmon rauszaubern, welche aber nicht ganz so sprechend sind wie die CPU Ready.
Auf Linux mit KVM habe ich noch keinen vergleichbaren Wert zum monitoren gefunden, aber die CPU Pressure sagt dir auch wenn da zu viele Anfragen kommen.
Danke für Deine Antwort. Wir nutzen bei vielen VM's das Profil x86-64-v3-AES. Das hat den Grund, dass wir mal bei einem Update der Hosts nicht mehr migrieren konnten weil wir Epic Rom ausgewählt hatten und alle Hosts absolut identisch sind. Als wir dann auf AMD Epic umgestellt hatten funktionierte die Migration wieder. Das wir sehr viele Telefoniesystem hosten kommt ein Neustart resp. runterfahren nicht gut bei den Kunden an. wir haben uns deshalb dazu entschieden ein möglichst neutrales Profil zu wählen. Wir haben einfach zuviel schiss, dass wir wieder in so ein Problem laufen.
End of the day ist es somit fast unmöglich zu bestimmen, wann wir neue Hardware anschaffen müssen. Und das ist heikel, weil wir ja irgendwann einen Punkt erreichen, bei dem der Druck zu hoch wird. Im normalen Betrieb mit drei Hosts keine Problem, wenn aber Migrationen gemacht werden um Updates durchzuführen ist das eine ganz andere Geschichte, dann steig der Druck auf den Host um 50%.
Wenn alle CPUs im Cluster die gleiche Gernation haben (muss nicht das gleiche Modell sein) und die gleichen BIOS Einstellungen, dann kannst du einfach auf host umstellen/einstellen. Dann kannst du alle Features der CPU nutzen. Wenn du host nutzt und auf neue Server migrieren möchtest, geht das auch in der Regl im laufenden Betrieb, solange die Hersteller nicht mal wieder ein Feature in den CPUs ausgebaut haben.
Schau dir mal cat /proc/pressure/cpu an und dann einmal wenn du die 50% mehr Last drauf fährst.
Hier mal die Offizielle Dokumentation zu /proc/pressure/cpu
The “some” line indicates the share of time in which at least sometasks are stalled on a given resource.
The “full” line indicates the share of time in which all non-idletasks are stalled on a given resource simultaneously. In this stateactual CPU cycles are going to waste, and a workload that spendsextended time in this state is considered to be thrashing. This hassevere impact on performance, and it’s useful to distinguish thissituation from a state where some tasks are stalled but the CPU isstill doing productive work. As such, time spent in this subset of thestall state is tracked separately and exported in the “full” averages.
Wenn du bei Some etwas Pressure hast, solltest du das beobachten, bei Full kannst du das je nachdem wie hoch der Wert ist, auch in der VM deutlich spüren.
The “some” line indicates the share of time in which at least sometasks are stalled on a given resource.
The “full” line indicates the share of time in which all non-idletasks are stalled on a given resource simultaneously. In this stateactual CPU cycles are going to waste, and a workload that spendsextended time in this state is considered to be thrashing. This hassevere impact on performance, and it’s useful to distinguish thissituation from a state where some tasks are stalled but the CPU isstill doing productive work. As such, time spent in this subset of thestall state is tracked separately and exported in the “full” averages.
Wenn du bei Some etwas Pressure hast, solltest du das beobachten, bei Full kannst du das je nachdem wie hoch der Wert ist, auch in der VM deutlich spüren.
Da treten ab und zu Warteschlangen bei den VMs auf. Aber das ist normal bei Virtualisierung.