7
Hyper-V CPU sizing
Hallo zusammen,
ich habe mir schon diverse Artikel zu diesem Thema durchgelesen, u.a. auch:
http://www.faq-o-matic.net/2011/01/26/hyper-v-sizing-virtuelle-und-echt ...
Mir bleibt dennoch eine Frage offen, die ich mir nicht selbst beantworten kann.
Bei FAQ-O-Matic steht bei Grundlage 4:1:
Das ist ein rein rechnerischer Vorgang, der besagt, dass ein LP problemlos vier CPUs für virtuelle Maschinen darstellen kann.
Anderreits steht aber auch, dass ein Server mit 4vCPUs nur Rechenzeit bekommt, wenn auch 4 LP zur Verfügung stehen.
Was genau bedeutet dies jetzt?
Ich habe einen Prozessor mit 4 Kernen und HT aktiviert, macht 8 LP.
Wenn meine VM jetzt 4 vCPUs hat, muss meine VM "warten" bis 4 LP frei sind, oder nur 1 LP, weil 1 LP vier vCPUs darstellen kann?
Gruße
ich habe mir schon diverse Artikel zu diesem Thema durchgelesen, u.a. auch:
http://www.faq-o-matic.net/2011/01/26/hyper-v-sizing-virtuelle-und-echt ...
Mir bleibt dennoch eine Frage offen, die ich mir nicht selbst beantworten kann.
Bei FAQ-O-Matic steht bei Grundlage 4:1:
Das ist ein rein rechnerischer Vorgang, der besagt, dass ein LP problemlos vier CPUs für virtuelle Maschinen darstellen kann.
Anderreits steht aber auch, dass ein Server mit 4vCPUs nur Rechenzeit bekommt, wenn auch 4 LP zur Verfügung stehen.
Was genau bedeutet dies jetzt?
Ich habe einen Prozessor mit 4 Kernen und HT aktiviert, macht 8 LP.
Wenn meine VM jetzt 4 vCPUs hat, muss meine VM "warten" bis 4 LP frei sind, oder nur 1 LP, weil 1 LP vier vCPUs darstellen kann?
Gruße
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 311456
Url: https://administrator.de/contentid/311456
Ausgedruckt am: 05.11.2024 um 04:11 Uhr
7 Kommentare
Neuester Kommentar
Moin,
auch mit 4 CPUs kannst du Aufgaben nicht auf verschiedene Prozesse aufteilen - höchstens auf Threads (d.h. Teileinheiten EINES Prozesses!) und auch das nicht beliebig.
Von daher kannst du 1, 2 oder 512 CPUs haben (im selben Rechner), ob HT oder nicht, ob single oder multi-core -> alles egal, es wird nur genau EIN Prozess zur Zeit darauf laufen (dieser Prozess kann eben eine VM sein). Vorteil bei mehreren CPUs ist das eben - so das entsprechende System das unterstützt - die Arbeit eines Prozesses auf die CPUs verteilt werden kann. Nehme ich z.B.
$var1 = 2+3;
$var2 = 5+1;
kann ich mit 2 CPUs beides gleichzeitig rechnen lassen (dabei können das ja beliebig komplexe Threads werden - z.B. ein Thread der auf dem Netzwerk horcht während ein anderer Thread irgendwelche Clients bedient). Nimmst du aber schon was simples wie
$var1 = 2+3;
$var2 = $var1+1;
dann fällt auf das es hier schon nicht parallel berechnet werden kann. Du MUSST warten bis das erste Ergebnis steht bevor du das zweite anfangen kannst. Hier würden dann von deinen 8 LP 7 im idle laufen und 1 arbeiten...
Würdest du jetzt noch versuchen verschiedene Prozesse zu nutzen wird das ganze deutlich übler. Ab jetzt hast du dein memory-management drin. Das sorgt dafür das sich ein Programm nicht dafür interessiert an welcher Stelle es im RAM liegt. Dein Programm geht erst mal davon aus das es den gesamten RAM für sich hat. D.h. im Maschinencode greiffe ich dann auf irgendwelche Resourcen zu usw. Nehmen wir jetzt an ich würde - weil ich mehr als 1 CPU habe - 2 Programme wirklich gleichzeitig laufen lassen dann habe ich ja das Problem das die Resourcen geteilt werden müssten. Was machst du z.B. mit der Tastatur wenn du 2 Browser gleichzeitig aktiv hättest? Für welches von beiden Fenstern gilt denn der Tastendruck? Und wenn Browser 1 sagt er möchte von der Adresse 50000h lesen (weil der ja glaubt alles gehört ihm) - aber browser 2 auch bei 50000h irgendwelche Daten hinterlegt hat, wessen Daten sind denn wirklich da?
--> Daher: Du hast immer nur genau EIN aktives Programm und dieses kann ggf. mehrere Threads enthalten...
Schönen Gruß,
Mike
auch mit 4 CPUs kannst du Aufgaben nicht auf verschiedene Prozesse aufteilen - höchstens auf Threads (d.h. Teileinheiten EINES Prozesses!) und auch das nicht beliebig.
Von daher kannst du 1, 2 oder 512 CPUs haben (im selben Rechner), ob HT oder nicht, ob single oder multi-core -> alles egal, es wird nur genau EIN Prozess zur Zeit darauf laufen (dieser Prozess kann eben eine VM sein). Vorteil bei mehreren CPUs ist das eben - so das entsprechende System das unterstützt - die Arbeit eines Prozesses auf die CPUs verteilt werden kann. Nehme ich z.B.
$var1 = 2+3;
$var2 = 5+1;
kann ich mit 2 CPUs beides gleichzeitig rechnen lassen (dabei können das ja beliebig komplexe Threads werden - z.B. ein Thread der auf dem Netzwerk horcht während ein anderer Thread irgendwelche Clients bedient). Nimmst du aber schon was simples wie
$var1 = 2+3;
$var2 = $var1+1;
dann fällt auf das es hier schon nicht parallel berechnet werden kann. Du MUSST warten bis das erste Ergebnis steht bevor du das zweite anfangen kannst. Hier würden dann von deinen 8 LP 7 im idle laufen und 1 arbeiten...
Würdest du jetzt noch versuchen verschiedene Prozesse zu nutzen wird das ganze deutlich übler. Ab jetzt hast du dein memory-management drin. Das sorgt dafür das sich ein Programm nicht dafür interessiert an welcher Stelle es im RAM liegt. Dein Programm geht erst mal davon aus das es den gesamten RAM für sich hat. D.h. im Maschinencode greiffe ich dann auf irgendwelche Resourcen zu usw. Nehmen wir jetzt an ich würde - weil ich mehr als 1 CPU habe - 2 Programme wirklich gleichzeitig laufen lassen dann habe ich ja das Problem das die Resourcen geteilt werden müssten. Was machst du z.B. mit der Tastatur wenn du 2 Browser gleichzeitig aktiv hättest? Für welches von beiden Fenstern gilt denn der Tastendruck? Und wenn Browser 1 sagt er möchte von der Adresse 50000h lesen (weil der ja glaubt alles gehört ihm) - aber browser 2 auch bei 50000h irgendwelche Daten hinterlegt hat, wessen Daten sind denn wirklich da?
--> Daher: Du hast immer nur genau EIN aktives Programm und dieses kann ggf. mehrere Threads enthalten...
Schönen Gruß,
Mike
ist ohnehin eher klingonische Mathematik sobald mal Hyperthreading ins Spiel kommt... 5% aller Anwendungen, die parallel reechnen können schaffen auch 8x soviel Arbeit auf einem 8-Core Prozessor der in Wirklichkeit 4 Kerne + Hyperthreading macht. Der Media concept MP4 Enconder kann das und der Windows Media Encoder in der X64 Edition. Abseits davon ist das eine gigantische Mogelpackung die von etlichen Rechenzentrumsbetreibern einfach ausgeschaltet wird um Skalierungseffekte überschaubar und linear berechenbar zu haben.
Denn je nach "Vollständigkeit" und "Autonomiefähigkeit" der einzelnen Prozessorkerne hat man dann so Zustände daß doppelt soviel CPU Kerne dank HT eben überhaupt nicht doppelt soviel Performance ergibt sondern je nach CPU-Aufbau 10-75% an Mehrgewinn hat.
Denn je nach "Vollständigkeit" und "Autonomiefähigkeit" der einzelnen Prozessorkerne hat man dann so Zustände daß doppelt soviel CPU Kerne dank HT eben überhaupt nicht doppelt soviel Performance ergibt sondern je nach CPU-Aufbau 10-75% an Mehrgewinn hat.
Danke für Eure Antworten.
Und wie viele vCores muss ich einer VM geben, damit diese dann auch die Leistung eines Kernes hat?
1 vCore?
Gerade vor dem Hintergrund mit 4:1 oder 8:1.
Und wie viele vCores muss ich einer VM geben, damit diese dann auch die Leistung eines Kernes hat?
1 vCore?
Gerade vor dem Hintergrund mit 4:1 oder 8:1.
Grundsätzlich:
1 vCPU kann die Leistung von einem Kern haben, sofern keine anderen VMs diesen Kern brauchen.
Wir lasssen jetzt der Einfachheit mal HT in der Betrachtung weg
Du hast 4 Kerne. 4 VMs mit je 1 vCPU bekommen jeweils einen Kern zu 100% haben damit die native Leistung eines Kerns (Das Hyper-V selber auch etwas braucht und daher effektiv eher 95% rauskommt lassen wir in der Betrachtung auch erstmal weg.)
Wenn Du jetzt 8 VMs mit je einer 1 vCPU hast und alle unter Vollast rechnen bekommt jede vCPU nur noch 50% der Leistung eines Kerns, da Sie sich den Kern mt einer anderen VM teilen muß.
Wenn die VM mehr als eine vCPU hat, dann muß sie tatsächlich warten, bis auf dem Host genügend physische Kerne zur Verfügung stehen.
D.h. auf einem stark ausgelasteten Host mit mehr vCPUs als physischen CPUs kommen VMs mit mehr vCPUs seltener dran als VMs mit weniger vCPUs, weil die mit mehr auf die selteneren Fälle warten müssen, wo genügend physische Kerne frei sind.
Das trifft aber nur auf die Fälle zu, wo die CPU Auslastung des Hostes recht hoch ist.
Meistens wird davon ausgegangen, daß die meisten VMs vor sich hindümpeln, deswegen die 4:1 Regel. Wenn Du weist, daß da nur vollausgelastete SQL Server draufkommen, dann sollte man besser 1:1 planen.
1 vCPU kann die Leistung von einem Kern haben, sofern keine anderen VMs diesen Kern brauchen.
Wir lasssen jetzt der Einfachheit mal HT in der Betrachtung weg
Du hast 4 Kerne. 4 VMs mit je 1 vCPU bekommen jeweils einen Kern zu 100% haben damit die native Leistung eines Kerns (Das Hyper-V selber auch etwas braucht und daher effektiv eher 95% rauskommt lassen wir in der Betrachtung auch erstmal weg.)
Wenn Du jetzt 8 VMs mit je einer 1 vCPU hast und alle unter Vollast rechnen bekommt jede vCPU nur noch 50% der Leistung eines Kerns, da Sie sich den Kern mt einer anderen VM teilen muß.
Wenn die VM mehr als eine vCPU hat, dann muß sie tatsächlich warten, bis auf dem Host genügend physische Kerne zur Verfügung stehen.
D.h. auf einem stark ausgelasteten Host mit mehr vCPUs als physischen CPUs kommen VMs mit mehr vCPUs seltener dran als VMs mit weniger vCPUs, weil die mit mehr auf die selteneren Fälle warten müssen, wo genügend physische Kerne frei sind.
Das trifft aber nur auf die Fälle zu, wo die CPU Auslastung des Hostes recht hoch ist.
Meistens wird davon ausgegangen, daß die meisten VMs vor sich hindümpeln, deswegen die 4:1 Regel. Wenn Du weist, daß da nur vollausgelastete SQL Server draufkommen, dann sollte man besser 1:1 planen.
Du hast 4 Kerne. 4 VMs mit je 1 vCPU bekommen jeweils einen Kern zu 100% haben damit die native Leistung eines Kerns (Das Hyper-V selber auch etwas braucht und daher effektiv eher 95% rauskommt lassen wir in der Betrachtung auch erstmal weg.)
Wenn Du jetzt 8 VMs mit je einer 1 vCPU hast und alle unter Vollast rechnen bekommt jede vCPU nur noch 50% der Leistung eines Kerns, da Sie sich den Kern mt einer anderen VM teilen muß.
Wenn Du jetzt 8 VMs mit je einer 1 vCPU hast und alle unter Vollast rechnen bekommt jede vCPU nur noch 50% der Leistung eines Kerns, da Sie sich den Kern mt einer anderen VM teilen muß.
Ist da nicht ein Denkfehler? Die VM bekommt weiterhin 100% der Leistung des Kerns, jedoch dauert es länger, bis der Kern für sie frei ist, da die Leistung in Zeitschlitzen verteilt wird.
Oder mache ich seit Jahren was falsch?
Nein machst Du nicht, es ist nur eine Frage der Abstraktionsgenauigkeit.
Wenn man nur einen einzelnen Zeitschlitz selber betrachtet, bekommt die VM natürlich 100% der Leistung.
Wenn ich aber nur noch 50% der vorhandenen Zeitschlitze bekomme, entspricht das letztendlich, über einen Zeitraum gerechnet der deutlich länger als ein einzelner Zeitschlitz ist, 50% er Leistung eines CPU Kerns.
Wenn man nur einen einzelnen Zeitschlitz selber betrachtet, bekommt die VM natürlich 100% der Leistung.
Wenn ich aber nur noch 50% der vorhandenen Zeitschlitze bekomme, entspricht das letztendlich, über einen Zeitraum gerechnet der deutlich länger als ein einzelner Zeitschlitz ist, 50% er Leistung eines CPU Kerns.
Zitat von @AndreasHoster:
Nein machst Du nicht, es ist nur eine Frage der Abstraktionsgenauigkeit.
Wenn man nur einen einzelnen Zeitschlitz selber betrachtet, bekommt die VM natürlich 100% der Leistung.
Wenn ich aber nur noch 50% der vorhandenen Zeitschlitze bekomme, entspricht das letztendlich, über einen Zeitraum gerechnet der deutlich länger als ein einzelner Zeitschlitz ist, 50% er Leistung eines CPU Kerns.
Nein machst Du nicht, es ist nur eine Frage der Abstraktionsgenauigkeit.
Wenn man nur einen einzelnen Zeitschlitz selber betrachtet, bekommt die VM natürlich 100% der Leistung.
Wenn ich aber nur noch 50% der vorhandenen Zeitschlitze bekomme, entspricht das letztendlich, über einen Zeitraum gerechnet der deutlich länger als ein einzelner Zeitschlitz ist, 50% er Leistung eines CPU Kerns.
Dann war es eher ein Kommunikationsfehler meinerseits. Deine Aussage stimmt natürlich.
