Hyper-V Host unausgeglichene CPU-Auslastung

[Chiller0tis 0]

Hallo zusammen, ich bin schon mehrere male auf dieses Forum gestoßen, konnte mier hier die ein odere andere Lösung für ein Problem finden und nun habe ich aktuell selbst ein Problem und hoffe das einer mir hierbei helfen kann.   aktuell untersuche ich bei uns in der Hyper-V (inkl. FailoverCluster) Umgebung warum es bei unseren RDP-Sitzungen zu Performance Problemen kommt. Dabei bin ich auf einem unserer Hyper-V Hosts auf eine Aufälligkeit in der CPU Auslastung im Task Manager gestoßen. Kurz ein wenig Hintergrund Infos: Server: Dell PowerEdge R640 CPU: 2x Xeon Gold 5115 (10 Kerne / 20 Threads) RAM: 767 GB BS: Windows Server 2016 Datacenter Laufende VM´s: 15 Aktuell   3x dieser darauf laufenden VM´s werden über RDP zum Produktiven Arbeiten genutzt. Im Schnitt sind pro Server jeweils 23 Nutzer am arbeiten. Die Konfiguration der Server ist identisch und wie folgt: RAM: Dynamisch 4GB - 60GB vCPU: 12 VHDX: Liegt auf einer NetApp AFF200 All-Flash   Wie oben bereits erwähnt, ist mir einen Auffäligkeit im Task-Manager aufgefallen, welche ich mir zur Zeit noch nicht erklären kann. Aktuell ist nur Prozessor 1 inkl. seiner Kerne stark ausgelastet. Prozessor 2 hat auffälig weniger zu tun. Mich interessiert nun sehr, warum die Last nicht gleichmäßig auf beide Prozessoren sowie deren Kerne verteilt wird? Habe ich hier einen Denkfehler oder liegt es evlt. an einer falschen Konfiguration meiner Seits? Für jeden Tipp bzw. Hilfe wäre ich sehr Dankbar! :)   Grüße Chiller0tis

bearbeitet 14. April 2021 von Chiller0tis

[Nobbyaushb 1.484]

Wenn du wirklich wissen willst, was wer wo wann macht sind die MS Hilfsmittel das falsche Werkzeug

 

Lade die mal die Testversion vom Veeam One herunter und installiere den, entweder auf dem Cluster oder separat - egal

 

Je nach bereits verwendeter Edition hast du bereits eine Lizenz - das bringt mich zu der Frage, womit wird gesichert?

https://www.veeam.com/de/downloads.html

 

[testperson 1.728]

Hi,

 

der Taskmanager ist eines der schlechtesten Tools bzgl. "Performance Messung" / "Bewertung" / "Monitoring" am HyperV. An der Stelle _könnte_ es sein, dass der Taskmanager einfach nur den Core Scheduler widerspiegelt: https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/manage-hyper-v-scheduler-types

 

Was ist denn auf den Terminalservern langsam und wie äußert sich das? Bei Terminalservern wäre ich spontan schon mal kein Freund von CPUs mit "so niedrigem" Takt. Je nach Anwendung spürt man das halt direkt. Ebenso würde ich auf dynamic Memory verzichten. 12 vCPUs pro Terminalserver schein mir - ohne weitere Infos - als zu viel des Guten. Ebenso sind - bei "meinen Anwendungen" - 23 User pro Terminalserver zu viel. Ich halte mich i.d.R. an mehrere schlanke VMs wie wenige "Monster VMs".

 

Generell würde ich bei der Perfomance "unten" anfangen:

 

• Im BIOS ist alles auf max Performance und min Energiesparen?
• Die Hosts sind ebenfalls auf "Höchstleistung"?
• Die VMs laufen auch auf "Höchstleistung"?

Jetzt wäre die Frage, was ist wann langsam und wie äußert es sich? Ggfs. wäre "Fair Share" noch ein zu prüfender Ansatz.

 

Gruß

Jan

 

[NilsK 2.968]

Moin,

 

ich stimme den anderen zu - der Taskmanager taugt hier nicht als Diagnosewerkzeug.

 

Ohne an dieser Stelle tiefer rein gehen zu können, folgende Spontanhinweise:

• Dynamic Memory kann man machen - sollte man aber nur tun, wenn man weiß, was man da tut. In diesem Szenario würde ich es weglassen, zumindest wenn es bekannte Performanceprobleme gibt.
• 12 vCPUs bei 10 physischen Cores ist keine gute Idee. Bleib bei max. 8 pro VM, besser noch drunter, solange es keine echte Analyse gibt, die dir eine höhere Ausstattung in genau diesem Setting nahelegt. Irgendeine Physik muss die virtuellen CPUs ja nun mal versorgen.

In vergleichbaren Settings hat sich die (völlig unnötige) CPU-Überbuchung als Performancebremse herausgestellt. Muss hier nicht so sein, kann aber.

 

Edit: Nee, da hatte ich mich verguckt. Dieser Verdacht wird so nicht zutreffen. Trotzdem werden 12 vCPUs mit großer Sicherheit unnötig und damit zu viel sein.

 

Gruß, Nils

 

bearbeitet 14. April 2021 von NilsK

[Chiller0tis 0]

Zitat

Je nach bereits verwendeter Edition hast du bereits eine Lizenz - das bringt mich zu der Frage, womit wird gesichert?

https://www.veeam.com/de/downloads.html

Wir sichern unsere Umgebung komplett mit Veeam Backup & Replication. Auf Veeam One bin ich heute auch gestoßen und werde schauen dass ich dies in den nächsten Tagen bei uns installiert bekomme.

 

Zitat

Hi,

 

der Taskmanager ist eines der schlechtesten Tools bzgl. "Performance Messung" / "Bewertung" / "Monitoring" am HyperV. An der Stelle _könnte_ es sein, dass der Taskmanager einfach nur den Core Scheduler widerspiegelt: https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/manage-hyper-v-scheduler-types

Zum Monitoren der CPU-Auslastung auf dem Host nutze ich zur Zeit den Performance Monitor (Hypver-V Hypervisor Logical Processor / % Total Run Time / _Total sowie Hypver-V Hypervisor Virtual Processor / % Total Run Time / _Total).+

Bei den VM´s nutze ich folgende Werte (Performance Monitor innerhalb der VM):

• Processor / % Processor Time / _Total

Bin auf dem Umstand im Task-Manager gestoßen und konnte mir nicht erklären warum dies verhalten so ist, deshalb eben die Anfrage. Werde mir den Artikel durchlesen

Zitat

• Im BIOS ist alles auf max Performance und min Energiesparen?
• Die Hosts sind ebenfalls auf "Höchstleistung"?
• Die VMs laufen auch auf "Höchstleistung"?

Werde ich mir anschauen und ggf. anpassen.

 

Auf der RDP-Umgebung auf welche unsere Mitarbeiter Arbeiten, arbeiten diese mit den üblichen Officen Anwendungen (Outlook/Word/Excel) sowie unserer Kern-Software, welche wiederum die Office-Anwendungen vorraussetzt. Wir haben insgesamt 7 von diesen Servern, also insgesamt arbeiten in dieser RDP-Collection um die 180 Mitarbeiter pro Tag. Wir haben die Vermutung dass durch diese Schiere Anzahl an Desktops natürlich auch ein nicht unerheblicher Teil der Grafik durch die CPU abgearbeitet werden muss. Diesbezüglich sind wir schon dabei dedizierte Karten anzuschaufen und diese in den Servern einzubauen

Wie viele Nutzer arbeiten denn bei euch pro Umgebung?

bearbeitet 14. April 2021 von Chiller0tis

[testperson 1.728]

vor 22 Minuten schrieb Chiller0tis:

Wir haben die Vermutung dass durch diese Schiere Anzahl an Desktops natürlich auch ein nicht unerheblicher Teil der Grafik durch die CPU abgearbeitet werden muss.

Da kann es ggfs. helfen, in den verschiedenen Programmen (Office, Browser, Teams, ...) - idealerweise per GPO - die "Grafik Hardwarebeschleunigung" zu deaktivieren. Bei Office ist es mittlerweile auf Terminalservern AFAIK per Default aus. Es kann aber nicht schaden, das trotzdem per GPO zu deaktivieren.

 

  

vor 9 Minuten schrieb Chiller0tis:

Diesbezüglich sind wir schon dabei dedizierte Karten anzuschaufen und diese in den Servern einzubauen.

 

AFAIK könnt ihr euch das (unter Hyper-V und plain RDS) sparen: KB4570006: Update to disable and remove the RemoteFX vGPU component in Windows (microsoft.com)

Zitat

Timeline

• Deprecation: RemoteFX vGPU was removed with the release of Windows 10, version 1809 and Windows Server 2019.
• Disablement: RemoteFX vGPU was disabled in all applicable Windows platforms in the July 2020 Windows security updates (July 14, 2020).
• Removal: RemoteFX vGPU will be removed from all applicable Windows platforms in the April 2021 Windows security updates (April 13, 2021)

 

vor 17 Minuten schrieb Chiller0tis:

Wir haben insgesamt 7 von diesen Servern, also insgesamt arbeiten in dieser RDP-Collection um die 180 Mitarbeiter pro Tag.

Oben bist du noch bei 3 Servern mit je 23 Usern. Oder machen nur 3 der 7 Server Probleme? :)

 

vor 26 Minuten schrieb Chiller0tis:

Wie viele Nutzer arbeiten denn bei euch pro Umgebung?

I.d.R. zwischen 5 bis 10 bzw. so, dass wir mit 4 vCPUs auskommen.

[Chiller0tis 0]

Ich wollte mal ein kurzes Update geben:
Ich konnte herausfinden, dass unsere RDP-Server aktuell nicht den Energiesparplan "Höchstleistung" benutzen und bin zur Zeit dabei das anzupassen.

Am 14.4.2021 um 17:31 schrieb testperson:

Da kann es ggfs. helfen, in den verschiedenen Programmen (Office, Browser, Teams, ...) - idealerweise per GPO - die "Grafik Hardwarebeschleunigung" zu deaktivieren. Bei Office ist es mittlerweile auf Terminalservern AFAIK per Default aus. Es kann aber nicht schaden, das trotzdem per GPO zu deaktivieren.

Ist mit auf die Liste der zu Überprüfenden Dinge gekommen

Am 14.4.2021 um 17:31 schrieb testperson:

Wir haben insgesamt 7 von diesen Servern, also insgesamt arbeiten in dieser RDP-Collection um die 180 Mitarbeiter pro Tag.

Insgesamt sind es 7, Das Beispiel war oben auf den Hyper-V Host bezogen, von welchen ich diese Screenshot angefertig habe ;)
 

Am 14.4.2021 um 17:31 schrieb testperson:

I.d.R. zwischen 5 bis 10 bzw. so, dass wir mit 4 vCPUs auskommen.

Nach unserer Saison, welche bis vorraussichtlich bis Juni laufen wird, werden wir die ganze Umgebung erneut auf den Prüfstand stellen. In der zweiten Jahreshälfte sind deutlich weniger Benutzer auf den Systemen unterwegs sodass dann anpassungen durchgeführt werden können.

 

@NilsK
Ich werde nächste Woche eine Auswertung der Auslastung hier posten ;)

[MurdocX 957]

Am 16.4.2021 um 13:06 schrieb Chiller0tis:

Nach unserer Saison, welche bis vorraussichtlich bis Juni laufen wird

Seid ihr eine zufällig Hochschule? Juni klingt so verräterisch nach Semesterferien.  

[daabm 1.366]

Am 16.4.2021 um 13:06 schrieb Chiller0tis:

In der zweiten Jahreshälfte sind deutlich weniger Benutzer auf den Systemen unterwegs

....und die Hoffnung stirbt zuletzt

[zahni 557]

Jedenfalls sollte man keine Konfiguration wählen, welche die Grenzen der NUNA-Architektur überschreiten. Das erfordert immer Speicher- und Cache-Zugriffe auf den jeweils anderen Prozessor, die relativ langsam sind. Es kann gut sein dass MS hier Strategien nutzt, die Zugriffe zu minimieren. Ich würde auch im BIOS prüfen, ob NUNA eventuell abgeschaltet wurde. Das muss eingeschaltet bleiben.

[Nobbyaushb 1.484]

vor 4 Stunden schrieb zahni:

Jedenfalls sollte man keine Konfiguration wählen, welche die Grenzen der NUNA-Architektur....

Moinsen,

konntest du nicht schlafen?

Und heißt das nicht NUMA?

https://de.wikipedia.org/wiki/Non-Uniform_Memory_Access

[Lian 2.449]

Nanu ist die Folge einer verschachtelten Nunana-Architektur

Ich stimme dem Vorschlag zu, das zu prüfen. 

[zahni 557]

Am 18.4.2021 um 07:21 schrieb Nobbyaushb:

Moinsen,

konntest du nicht schlafen?

Und heißt das nicht NUMA?

https://de.wikipedia.org/wiki/Non-Uniform_Memory_Access

Ja, manchmal hier etwas posten und dann besser schlafen, NUNA: War auf dem Ipad mit dicken Fingern und Schlafsand in den Augen 

 

bearbeitet 19. April 2021 von zahni

[Chiller0tis 0]

Am 17.4.2021 um 18:07 schrieb MurdocX:

Seid ihr eine zufällig Hochschule? Juni klingt so verräterisch nach Semesterferien.  

Ne Wir bzw. unsere Mitarbeiter:innen sind in der freien Wirtschaft unterwegs ;)
 

Am 18.4.2021 um 03:03 schrieb zahni:

Jedenfalls sollte man keine Konfiguration wählen, welche die Grenzen der NUNA-Architektur überschreiten. Das erfordert immer Speicher- und Cache-Zugriffe auf den jeweils anderen Prozessor, die relativ langsam sind. Es kann gut sein dass MS hier Strategien nutzt, die Zugriffe zu minimieren. Ich würde auch im BIOS prüfen, ob NUNA eventuell abgeschaltet wurde. Das muss eingeschaltet bleiben.

Über NUMA habe ich vorher wenig gelesen und bin durch meine Recherche auch darauf aufmerksam geworden. Zusammen gefasst gesagt, sollten einer VM nie mehr vCpu´s zugewiesen werden als physische Kerne (ohne HT) auf dem Host liegen?

 

[zahni 557]

vor 32 Minuten schrieb Chiller0tis:

Über NUMA habe ich vorher wenig gelesen und bin durch meine Recherche auch darauf aufmerksam geworden. Zusammen gefasst gesagt, sollten einer VM nie mehr vCpu´s zugewiesen werden als physische Kerne (ohne HT) auf dem Host liegen?

Du solltest zunächst mal die Hardware prüfen: Haben alle CPU'en die gleiche RAM-Bestückung? Die muss wirklich absolut identisch sein.

Dann im BIOS prüfen, ob jemand die NUMA-Funktion deaktiviert hat. Wie sich das bei Deinem Server schimpft, kann ich nicht sagen. Da musst Du die Doku Deines Servers lesen.

Eine VM darf nicht mehr vCPU'en zugewiesen bekommen, als ein (!) Prozessors Cores hat und darf auch nicht mehr RAM bekommen als am NUMA-Node gesteckt ist. Also im Zweifel 50% vom verbauten RAM.

Dann solltest Du alle Stromspar-Funktionen im BIOS abschalten. Im Windows entsprechende Power-Management-Setting auf "max" stellen.

bearbeitet 20. April 2021 von zahni