Option "CPU limit"

[MisterDeeds]

Hallo zusammen

Ich habe einen PVE Host mit welchem ich eine VDI Umgebung für 70 Windows Maschinen realisiere. Der Host selbst hat zwei Intel(R) Xeon(R) Gold 6242R CPU @ 3.10GHz. Alle Maschinen haben zwischen 8 und 16 vCPU Kerne. Alle haben den Type "host". Nun wollte ich das "CPU limit" festlegen, damit eine VM nicht den ganzen Host blockieren kann. Leider erschliesst sich mir die Berechnung aber nicht. Hättet ihr eine Tipp für mich auf welchen Wert dieses sinnvoll gesetzt werden kann?


Vielen Dank und beste Grüsse

 

[Dunuin]

Soweit ich das verstanden habe kannst du mit "CPU Limit" die Summe der Auslastung deiner vCPUs begrenzen. Also gibst du z.B. "4" an bei einer VM mit 8 vCPUs, dann können alle 8 vCPUs in der Summe nur 400% CPU-Zeit verbrauchen. Also z.B. 8 vCPUs mit 50% Auslastung, 4 mit 100% Auslastung oder 6 vCPUs mit 66% Auslastung etc.
Außerdem kann das wohl in Scripten ganz praktisch sein, weil die Anzahl der zugewiesenen Sockets/Cores/vCPUs nicht während der Laufzeit geändert werden kann (Änderungen dort werden erst beim nächsten Start der VM übernommen) was bei CPU Limit aber schon gehen soll (also ganz ähnlich wie beim Ballooning wo der VM ja auch im laufenden Betrieb RAM entzogen werden kann). So könnte man sich dann wohl ein Script schreiben was die CPU-Auslastung aller VMs überwacht und dann einzelne VMs drosselt, wenn z.B. der Host an seine Grenzen stößt. Oder man könnte ein Script schreiben was die CPU-Auslastung der VMs protokolliert und jeder VM kurzzeitig volle Leistung ermöglicht aber die Leistung dann dynamisch drosselt, wenn eine VM für zu lange zu viel CPU-Leistung beansprucht...um z.B. gegen Cryptomining vorzugehen.

Das im Wiki hast du gelesen?:

With the cpulimit (“Host CPU Time”) option you can limit how much CPU time the whole VM can use on the host. It is a floating point value representing CPU time in percent, so 1.0 is equal to 100%, 2.5 to 250% and so on. If a single process would fully use one single core it would have 100% CPU Time usage. If a VM with four cores utilizes all its cores fully it would theoretically use 400%. In reality the usage may be even a bit higher as Qemu can have additional threads for VM peripherals besides the vCPU core ones. This setting can be useful if a VM should have multiple vCPUs, as it runs a few processes in parallel, but the VM as a whole should not be able to run all vCPUs at 100% at the same time. Using a specific example: lets say we have a VM which would profit from having 8 vCPUs, but at no time all of those 8 cores should run at full load - as this would make the server so overloaded that other VMs and CTs would get to less CPU. So, we set the cpulimit limit to 4.0 (=400%). If all cores do the same heavy work they would all get 50% of a real host cores CPU time. But, if only 4 would do work they could still get almost 100% of a real core each.

VMs can, depending on their configuration, use additional threads e.g., for networking or IO operations but also live migration. Thus a VM can show up to use more CPU time than just its virtual CPUs could use. To ensure that a VM never uses more CPU time than virtual CPUs assigned set the cpulimit setting to the same value as the total core count.

 

[Falk R.]

Wenn du 70 VMs 8 Cores gibst, sind das 540 vCPUs. Das bei 40 Cores/ 80 Threads, dann wird keiner vernünftig arbeiten können. Bei einer so hohen Überbuchung wirst du mit sehr hohen CPU Wartezeiten belohnt.
Wieso benötigst du so viele vCPUs?

 

[MisterDeeds]

Soweit ich das verstanden habe kannst du mit "CPU Limit" die Summe der Auslastung deiner vCPUs begrenzen. Also gibst du z.B. "4" an bei einer VM mit 8 vCPUs, dann können alle 8 vCPUs in der Summe nur 400% CPU-Zeit verbrauchen. Also z.B. 8 vCPUs mit 50% Auslastung, 4 mit 100% Auslastung oder 6 vCPUs mit 66% Auslastung etc.
Außerdem kann das wohl in Scripten ganz praktisch sein, weil die Anzahl der zugewiesenen Sockets/Cores/vCPUs nicht während der Laufzeit geändert werden kann (Änderungen dort werden erst beim nächsten Start der VM übernommen) was bei CPU Limit aber schon gehen soll (also ganz ähnlich wie beim Ballooning wo der VM ja auch im laufenden Betrieb RAM entzogen werden kann). So könnte man sich dann wohl ein Script schreiben was die CPU-Auslastung aller VMs überwacht und dann einzelne VMs drosselt, wenn z.B. der Host an seine Grenzen stößt. Oder man könnte ein Script schreiben was die CPU-Auslastung der VMs protokolliert und jeder VM kurzzeitig volle Leistung ermöglicht aber die Leistung dann dynamisch drosselt, wenn eine VM für zu lange zu viel CPU-Leistung beansprucht...um z.B. gegen Cryptomining vorzugehen.

Das im Wiki hast du gelesen?:

Vielen Dank für die ausführliche Antwort. Den Eintrag im Wiki habe ich gesehen, jedoch war es für mich nicht verständlich. Dank deiner Erklärung, kann ich jedoch mehr damit anfragen. Ich werde es testen, wie sich die Performance entsprechend verhält.

 

[MisterDeeds]

Wenn du 70 VMs 8 Cores gibst, sind das 540 vCPUs. Das bei 40 Cores/ 80 Threads, dann wird keiner vernünftig arbeiten können. Bei einer so hohen Überbuchung wirst du mit sehr hohen CPU Wartezeiten belohnt.
Wieso benötigst du so viele vCPUs?

Diese Aussage ist so aber nicht korrekt. vCPU sind ja nicht identisch zu den vorhandenen Threads der physischen CPU. Die Berechnung ist (gemäss meiner Recherche) wie folgt: (40 Threads x 20 Cores) x 2 CPU = 1600 vCPU

Wir nutzen die VMs für CAD Workstation welche nebst Grafik auch CPU intensive Prozesse ausführen müssen

 

[Dunuin]

Diese Aussage ist so aber nicht korrekt. vCPU sind ja nicht identisch zu den vorhandenen Threads der physischen CPU. Die Berechnung ist (gemäss meiner Recherche) wie folgt: (40 Threads x 20 Cores) x 2 CPU = 1600 vCPU

Wir nutzen die VMs für CAD Workstation welche nebst Grafik auch CPU intensive Prozesse ausführen müssen

Je mehr vCPU du aber jedem Thread/Core verpasst, desto mehr kommt die CPU ins Stottern, wenn sie zwischen all den vCPUs hypervisen soll. Eine CPU, die nur 1 vCPU pro physischem Core zugeordnet hat, muss halt nie warten, da der Core immer verfügbar ist. Bei physischen Threads sieht es schon wieder anders aus. Die 2 Threads eines Cores teilen sich ja die selbe Hardware und das meiste kann nicht parallel getan werden. Es arbeitet halt meist nur 1 Thread zur Zeit und wenn der Thread mal warten muss, weil z.B. erst Daten aus dem RAM geladen werden müssen, damit der Core weiterrechnen kann, wird halt der andere Thread in der Zwischenzeit abgearbeitet. Daher ist eine 40-Thread-20-Cores-CPU auch nicht doppelt so schnell wie eine 20-Thread-20-Cores-CPU ohne Hyperthreading sondern vielleicht 10-50% schneller. Am Ende haben halt beide nur 20 Cores, nur kann die CPU mit Hyperthreading diese 20 Kerne halt effizienter auslasten, da die Wartezeiten sinnvoll gefüllt werden können.
Ganz ähnlich läuft das mit vCPUs. Hast du 2 vCPUs pro Thread, dann kann immer nur einer der beiden vCPUs zur Zeit etwas tun und die andere vCPU muss warten. Hast du da dann sogar 20 vCPUs pro Thread dann arbeitet nur eine vCPU und alle anderen 19 müssen warten. Je mehr vCPUs warten müssen, desto schlechter die Latenz. Hier gilt also je weniger vCPUs du einem physischem Thread zuteilst, desto besser. Und dann nicht vergessen das Threads ja selbst auch schon warten müssen. Du packst also 40 vCPUs auf jeden physischen Core, also arbeiten immer nur 1-2 vCPUs und die andere 38-39 müssen warten. Deine vCPUs sind also quasi pausenlos nur am Warten das mal der Core frei wird damit sie auch mal rechnen dürfen.

Wenn man optimistisch ist können bei 80 Threads dann vielleicht 60 vCPUs mit je 100% Auslastung laufen. Hast du dann 1600 vCPUs verteilt, darf jede vCPU im Schnitt also nur noch 1600/60 = 3,75% CPU-Auslastung haben. Du hast also sehr wahrscheinlich viel zu viele vCPUs auf der Hardware laufen.

 

[Falk R.]

Was die meisten auch nicht auf dem Schirm haben, du kannst schon sehr lange Warteschlangen haben ohne die CPU von der Leitung annähernd auszulasten. Bei einer Office VDI gibts 1 vCPU. Für etwas mehr wie exzessives Excel oder Viso gibts 2 vCPUs. Normalerweise ganz selten mehr als 3 oder 4 vCPUs. Die mit 4 haben alle ein CAD Programm am laufen.

Muss man aber immer von Fall zu Fall genau checken und dann sizen.

 

[MisterDeeds]

Hallo zusammen und vielen Dank für die ausführlichen Antworten und Inputs. Das stimmt natürlich, somit könnte es sogar vorkommen, dass wenn eine Maschine mehr vCPU besitzt diese dann langsamer ist, da sie immer auf den Slot warten muss, wo alle Kerne zur Verfügung stehen. Da muss ich wohl nochmal über die Bücher... Ohnehin danke für die Inputs!

 

[Falk R.]

Oder du fragst jemanden, der das schon mal gemacht hat.

 

[MisterDeeds]

ja das wäre sicher am einfachsten... aber eben jemand zu finden der genau mein Setup bereits im Betrieb hat, ist ein Ding der Unmöglichkeiit. Die Dimensionierung von VDI ist ja so individuell wie jedes Setup selbst. In meinem Fall ist die Hardware (2x Intel Xeon 6242R) und die Anzahl VMs (68 Stk.) fix gegeben. Also beispielsweise, dass ein vCPU auf einen CPU Thread kommt ist schon mal nicht möglich. Ich kann also nur mit den vCPUs und dem CPU Limit hantieren.

Ich habe einen halben Tag lang meinen eigenen CPU gemonitort (läuft ebenfalls auf einer VM). Ich habe diverse Programme am laufen (u.a. XAMPP, PHPStorm, Photoshop, Teams, Skype, OneDrive, Chrome etc.). und ansonsten normal weitergearbeitet. Die Auslastung des CPU lag bei durchschnittlich bei 10-12%.

In der aktuellen Konfiguration habe ich den VMs neu folgende Zuteilung gegeben:
32 VM mit 4 vCPU (CPU Limit 3)
24 VMs mit 6 vCPU (CPU Limit 5)
12 VMs mit 8 vCPU (CPU Limit 7)
-------------------------------
Somit Total 368 vCPU. Gerechnet mit der von Dunuin genannten Formel: 368 vCPU / 60 vCPUs mit je 100% Auslastung = 16.3% CPU-Auslastung (noch ohne Limit). So sollten keine Leistungseinbussen entstehen und mit CPU Limit sogar noch etwas Luft nach oben sein, falls einige VMs dann kurzzeitig doch mehr Leistung beziehen.

Danke soweit für eure Inputs und bin gespannt auf allfällige Rückmeldungen.

Beste Grüsse

 

[itNGO]

Hi,
ich muss hier mal einsteigen, weil ich da was nicht ganz verstehe.
Du gibst also der VM 4 "virtuelle" Kerne, sagst aber das diese nur 3 "echte" Kerne benutzen darf. Wäre es da nicht nicht direkt einfacher das auf 3:3 zu setzen? Das limitiert doch auch nicht mehr oder weniger?

 

[MisterDeeds]

Also CPU Limit ist für mich auch neu. Aber das Limit ist Fliesskommawert der die CPU-Zeit in Prozent angibt. D. h. 1,0 entspricht 100 %, 2,5 -> 250 % und so weiter. Wie es Dunuin hier beschreibt: https://forum.proxmox.com/threads/option-cpu-limit.101266/post-436894

 

[itNGO]

Also CPU Limit ist für mich auch neu. Aber das Limit ist Fliesskommawert der die CPU-Zeit in Prozent angibt. D. h. 1,0 entspricht 100 %, 2,5 -> 250 % und so weiter. Wie es Dunuin hier beschreibt: https://forum.proxmox.com/threads/option-cpu-limit.101266/post-436894

Dann ist 3 also ein Limit von 300% was sinngemäss 3 "echten" Kernen entspricht, wenn diese denn im Host vorhanden sind.
Also ist es doch immer noch nicht so "richtig" sinnvoll 4-Kerne in die VM zu stecken die nur die Leistung von 3 Kernen nutzen dürfen?
Wo ist da für den Gast der Benefit, wenn alle 4 Kerne dampf geben, ist das doch dann nicht schneller, als wenn 3 Kerne dampf geben?
Da verknotet es sich bei mir grad im Kopf.

 

[Dunuin]

Laut Wiki kann das manchmal Vorteile haben. Sagen wir du hast 4 Datenbanken in einer VM aber jede Datenbank will nur 50% CPU Zeit.
Dann könnte man der VM 4 vCPUs geben aber das CPU limit auf 300% setzen. Dann dürfen die 4 KErne zusammen zwar auch nur maximal 300% CPU Zeit nutzen, es können aber weiterhin 4 Prozesse parallel bearbeitet werden.

3 vCPUs ohne CPU Limit (also quasi mit 300% Limit):
DB1 + DB2 + DB3 tun was je 50% CPU-Zeit und DB4 muss warten, da die VM ja nur 3 Threads parallel abarbeiten kann (150% CPU Zeit in Summe).
Sind die 3 DBs dann fertig darf DB4 dann mit 50% CPU-Zeit arbeiten.

4 vCPUs mit 300% Limit:
Alle 4 DBs können parallel mit 50% CPU-Zeit arbeiten (also 200% CPU-Zeit in der Summe) und keine DB muss warten.
Würden die DBs jetzt aber plötzlich mal eine Operation haben die viel mehr CPU-Zeit als sonst braucht (Tabellen-Aufräum-Task oder so) und jede DB gerne 100% CPU-Zeit hätte, dann wären die 4 DBs halt auf je 66% CPU-Zeit gedrosselt, dass da in der Summe nur die Leistung von 3 CPUs benutzt werden kann.
So kann man dann für eine VM das Multitasking verbessern ohne die Gefahr zu haben, dass da eine VM den ganzen anderen VMs die Leistung raubt.

 

[itNGO]

@Dunuin, das Prinzip hab ich verstanden, vielen Dank für die ausführliche Erklärung. Eine Frage hab ich aber trotzdem noch dazu.
Wenn man Context-Switching dabei mit in Betracht zieht, ist das im Zweifel doch eher "mehr" Stress für den Hypervisor bzw. Host-Prozessor oder?

 

[Dunuin]

@Dunuin, das Prinzip hab ich verstanden, vielen Dank für die ausführliche Erklärung. Eine Frage hab ich aber trotzdem noch dazu.
Wenn man Context-Switching dabei mit in Betracht zieht, ist das im Zweifel doch eher "mehr" Stress für den Hypervisor bzw. Host-Prozessor oder?

Ja. Sinn macht das mit CPU Limit wohl echt nur in Ausnahmefällen. Am interessantesten finde ich das mit dem CPU Limit wie gesagt noch für Scripts, wenn man es wirklich nutzen kann um die VM dynamisch während der Laufzeit zu drosseln.

 

[Falk R.]

In der aktuellen Konfiguration habe ich den VMs neu folgende Zuteilung gegeben:
32 VM mit 4 vCPU (CPU Limit 3)
24 VMs mit 6 vCPU (CPU Limit 5)
12 VMs mit 8 vCPU (CPU Limit 7)
-------------------------------
Somit Total 368 vCPU. Gerechnet mit der von Dunuin genannten Formel: 368 vCPU / 60 vCPUs mit je 100% Auslastung = 16.3% CPU-Auslastung (noch ohne Limit). So sollten keine Leistungseinbussen entstehen und mit CPU Limit sogar noch etwas Luft nach oben sein, falls einige VMs dann kurzzeitig doch mehr Leistung beziehen.

Hi, das war recht vereinfacht dargestellt. Leider ist das Thema CPU Scheduler bei der Virtualisiserung etwas komplexer.
Bevor ich alles erkläre, erst mal allgemeingültige Empfehlungen für sizings ohne Leistungseinbußen:
- 1vCPU VMs vCPU/CPU 4:1
- 2vCPU VMs vCPU/CPU 2,5:1
- 4vCPU VMs vCPU/CPU 1,6:1
Das ganze kann man natürlich noch etwas aufweichen, wenn die CPU sehr viele Kerne hat und man mit gewissen Performanceeinbußen leben kann.

Normalerweise male ich das immer auf zum erklären, ich hoffe man versteht es auch so.
Zum vorstellen ein ganz simples Setup 1CPU mit 4 Kernen und 4 VMs, 2x 2vCPU, 2x 1vCPU
Der Server hat jetzt 4 Kerne zur Verfügung, jede VM benötigt für jede kleinste Berechnung immer die eingestelle vCPU Anzahl an physikalischen Kernen.
Es rechnet eine 2vCPU VM und eine 1vCPU VM, dann kommt die zweite 2vCPU VM und landet in der Warteschlange, da nur 1 Kern frei ist.
eine Nanosekunde später kommt die zweite 1vCPU VM und könnte ja theoretisch den freinen Kern nutzen. aber die landet hinter der 2vCPU VM in der Warteschlange, da die Anfrage ja etwas später kam. Die cpu Last spielt dabei keine Rolle, wenn die VMs nur minimale Berechnungen machen.
Jetzt hast du ein einfaches Beispiel wie Warteschlangen auf der CPU entstehen. Umso mehr vCPUs eine VM hat, umso eher entstehen Warteschlangen. Wenn du viele 8vCPU VMs auf einen 64Core Epyc loslässt, bekommst du deutlich bessere Werte als wenn du 2 Server mit je 2x 16 Core hast. Eine CPU mit vielen Kernen kann da ganz anders skalieren.
Ich haben Kunden auf einen 2 Knoten Cluster migriert (je 1x 64Core). Wenn dann ein Server aus ist und alles auf einer Maschine läuft, sind die Latenzen immer noch deutlich besser als vorher, bei 5 Servern mit je 20 Kernen.
Hperthreading kann man ja auch noch mit einem Faktor von ca. 1:1,6 einkalkulieren.

Wie du siehst ist so ein Sizing doch komplexer als viele denken. Es gibt sehr viele Variablen zu beachten.

Jetzt zu deinen VDIs. Ich nehme mal als Beispiel einen Kunden aus dem Fahrzeugbau mit recht komplexen 3D Modellen. Die CAD VDIs haben fast alle 4vCPUs, ein paar weinge Leute Weltweit haben 5-6 vCPUs. Prüfe mal ob deine VMs tatsächlich so viele Kerne benötigen.
Mit Limits arbeiten würde ich gar nicht, da du durch das Sizing mit vielen VCPUs künstlich ausbremst und das Limit vermutlich nie zum Tragen kommt.

Wenn ein CAD User sich wegen der Performance beschwert, hat der bestimmt nix dagegen, das seine Maschine einen Reboot machen muss wenn er mehr Performance benötigt, die er dann direkt bekommt.

Gruß Falk

 

[MisterDeeds]

Hallo Falk

Vielen Dank für die ausführliche Antwort! Das ist echt spannend zu hören und nun wird auch das Bild etwas klarer.

Da wäre wohl AMD Epyc effektiv die bessere Wahl... Der einzige Wermutstropfen ist halt dort, dass die AMD Systeme keine Intel Optane Persistent Memory unterstützen und AMD keine wirkliche Alternative dazu hat. Standard DDR4 ECC RAM sind sowohl neu als auch gebraucht mit grosser Speicherkapazität sehr teuer... Nun gut, dass steht ja sowieso nicht zur Debatte, aber nett darüber zu fantasieren

Ich werde es nun so machen, dass standardmässig alle VMs 4 vCPU haben und ich das Limit weg lasse. Sollte dann eine Maschine effektiv mehr CPU Leistung benötigen teile ich diese fix zu und lasse ihn rebooten.

Vielen Dank allen fürs Mitdiskutieren und die tollen Antworten.

Eine besinnliche Zeit und beste Grüsse

 

[Falk R.]

Darf ich mal fragen was du mit dem PMem machen möchtest?
Ich habe mal einen Performancetest mit PMEM gemacht, das Limit war immer die CPU. Die 512GB PMEM und beim zweiten Test, die 4 Kioxia 7,68 TB NVMe haben 2 Mio IOPs geliefert. Bottleneck also immer die 32Threads der CPU.
PMEM ist eigentlich nur gut als reiner Write Cache.
Und wir lernen wieder, das CPU Sizing ist entscheidend.