Terminalserver extrem hohe CPU Last, RDP Disconnects

[zahni 521]

Schau Dir mal das hier an:

 

https://www.dell.com/support/kbdoc/de-de/000124011/installation-unter-windows-server-und-unterstützung-für-die-prozessor-produktreihe-amd-rome

 

X2APIC deaktiviert, da Windows 2016? BTW, was ist eigentlich Windows xxxx ENT?

Ist das Board gemäß NUMA-Spezifikation korrekt bestückt?

[illumina7 3]

Hatte mich eingangs verschrieben, ist Server 2016/19 Datacenter, nicht Enterprise.

Ich gehe davon aus, dass das Board korrekt bestückt ist, kam ja so von einem Supermicro Systembuilder (Coreto AG).

Ob X2APIC deaktiviert oder aktiviert ist weiß ich eben nicht, ich schau dann ob ich das über IPMI sehen kann. 

[Wolke2k4 11]

Ich habe aktuell 2 Kunden mit RDS und Performanceproblemen. Sind 2 Schulen...

In beiden Fällen Hyper-V Server als Host, hatten vorher 2008R2 RDS drauf, da gab es keine derartigen Probleme. Nun sind es 2019-er Server...

 

Wir sind derzeit noch bei der Ursachensuche.

 

 

 

[cj_berlin 1.133]

vor 2 Stunden schrieb Wolke2k4:

Ich habe aktuell 2 Kunden mit RDS und Performanceproblemen. Sind 2 Schulen...

In beiden Fällen Hyper-V Server als Host, hatten vorher 2008R2 RDS drauf, da gab es keine derartigen Probleme. Nun sind es 2019-er Server...

 

Wir sind derzeit noch bei der Ursachensuche.

Das Thema mit Zehntausenden von User-basierten Firewall-Regeln schon bereinigt?

[illumina7 3]

vor 25 Minuten schrieb cj_berlin:

Das Thema mit Zehntausenden von User-basierten Firewall-Regeln schon bereinigt?

Das ist in meinem Fall tatsächlich schon erledigt und per reg Eintrag deaktiviert bzw. die Regeln bei Logoff gelöscht. 

bearbeitet 14. Januar 2022 von illumina7

[djmaker 95]

Hallo vielleicht einmal zurück zu den Basics:

 

eure "alten" RDS Server waren vermutlich mit HDD bestückt. Diese sorgen dafür das gelesene Daten gleichmäßig "langsam" gelesen werden. Wenn nun  ein neuer Server mit einem RAID 10 mit NVME-SSDs bestückt wird werden die Daten zu "schnell" geliefert und die CPU wird der Flaschenhals. Das Phänomenen habe ich regelmäßig beim Tausch von altem Storage gegen neue Systeme (die dann oft mehrfach per 16  /32 Gbit FC angebunden sind). 

 

Obwohl ich die Kundschaft regelmäßig vorab warne gibt es anschließend Performanceprobleme in den VMs (RDS / Citrix / Exchange etc. .pp.). Erst nach Aufstocken der virtuellen Ressourcen lösen sich die Probleme.

Erst einmal heißt es immer "sch**ss Storage", zu langsam. Wenn ich dann mit dem Befehl "qos statistics latancy show" auf der  Netapp zeige, das am front end der NetApp eine Latenz über alles von unter 1 ms besteht gibt es "Maulsperren". Da mitten am Tag teilweise keine keine down time möglich ist habe teilweise die NetApp mit Quality of Service  Policies drosseln müssen.

 

Ich hoffe das hilft erst einmal weiter.

[illumina7 3]

Deine Theorie wird ja dadurch gestützt, dass nach verdoppeln der vCPUs die RDSH jetzt richtig rennen. Während die vorher bei der gleichen Sessionanzahl mit 60-80% auslastung gelaufen sind, kommen die jetzt auf 20-30%, im Peak mal 40%. Jetzt hab ich nur ein Problem, zu den 4 bestehenden rdsh kommen noch zwei oder 3 hinzu, dann müsste ich mehr vCPUs als physisch vorhandene zuweisen. Wobei das eigentlich funktionieren sollte, wenn die einzelnen rdsh kaum über 40% auslastung gehen oder?

[NilsK 2.781]

Moin,

 

In dem Fall wird sehr wahrscheinlich die Überbuchung nach hinten losgehen. Wo keine Ressourcen sind, kann man auch keine zuweisen.

 

Gruß, Nils

[Weingeist 157]

Was man auch gerne vergisst ist die Tatsache, dass Windows mittlerweile verschiedensten Berechnungen an die GPU auslagert. Das hat deutlich zugenommen in den letzten paar Jahren. Ist zwar hilfreich für normale PC's/Notebooks, aber eben nicht mit Virtualisierung. Muss das durch die CPU via virtueller GPU erledigt werden, ist das nicht gerade hilfreich und der Performance abträglich. Sprich im Endeffekt braucht man für das gleiche plötzlich mehr CPU-Zyklen als auch schon. Wird zwar teilweise dadurch aufgefangen, dass diese Berechnungen auf dem zugreifenden Client passiert - Zumindest bei RDP - , aber wohl längst nicht alles. Erhöht man z.Bsp. auch noch die Auflösung an den zugreifenden Clients, wird das ganze nochmals verschärft. Auch sind immer mehr Dienste Userbasiert. Das verschlingt zusätzliche Ressourcen.

 

Der vermehrte Einsatz von Video-Calls, Echtzeit-Audio und Home-Office macht alles noch schlimmer weil das priorisiert werden muss damit man keine unerwünschten Unterbrüche hat. Das pfuscht in die ganzen Verteilungsmechanismen rein. Bei anderen Prozessen spielt das keine Rolle bzw. ist ja erwünscht, sonst würde es nicht funktionieren. Die Priorisierung bremst den Rest aber dann irgendwann zu stark ein weil die notwendigen Zyklen nicht freigegeben werden.

Dann gibts da auch noch ganz banale Dinge: Ist ja eigentlich fast schon etwas bekloppt was alleine ein Starmenüaufruf insgesamt für IOPS/CPU-Zyklen verursacht und wie lange da im Hintergrund Daten analysiert und gespeichert werden. Zu guter letzt ist die Telemetrie enormst ausgebaut worden. Was da im Hintergrund alles berechnet und gespeichert wird ist schon fast mehr als was ein 0815 User selber an IOPS/CPU Zyklen beim Arbeiten verursacht. Zumindest in VDI hilft das daher enorm, wenn man den Rotstift bei dem ganzen Krempel ordentlich ansetzt. Schätze mal, das tut es auch bei RDP. ;)

 

Die Verwendung von SSD's/NVMe's wurde ja bereits genannt. Da wird dann aber mehr die virtuelle Netzwerkkarten zum Problem als die IOPS welches das OS verursacht. Sprich das was an Traffic über das Netz der VMs generiert wird. Wenn ein Client z.Bsp. eine grössere Video-Datei mit 500 MB/s kopiert, dann verursacht das eine enorme CPU-Last. Je nach Storage sowohl auf dem Host als auch innerhalb der VM. Ganz Krass von VM zu VM, sind dann zwei virtuelle Karten und Hostressourcen. Solange das Storage nicht hinterherkommt, 0 Problemo, schaufelt das IOs, dann wirds zum Problem. Sind die CPU's überbucht, wirds zum massiven Problem.

 

Als Fazit würde ich sagen: Überbuchen sollte man möglichst vermeiden/tief behalten sobald man zeitkritische Prozesse wie Video/Audio hat. Da werden eine Menge der ausgefeilten Prozesse ausgehebelt weil die VM eben darauf angewiesen ist, dass sie die Ressourcen ohne Verzögerung bekommt. Sprich die notwendigen CPU-Zyklen möglichst exklusiv im Voraus reserviert werden. Ein Client ohne Video/Audio/unnötige Animationen etc. ist da anspruchsloser.