Nov 02, 2023

3539

Terminalserver bei Anmeldung auf 100 Prozent CPU-Last

Hallo an Alle,

Ich bin neu hier und versuche so detailliert wie möglich das Problem zu beschreiben.

Wir haben einen Kunden, welcher seit geraumer Zeit Probleme mit seinem Terminalserver hat.

Dieser steht in unserem Rechenzentrum und hat folgende Daten:

32xvCPU (ja nicht Best-Practice, komme ich gleich nochmal zu.)

120GB RAM

Genug Festplatte für lokale Profile etc.

Windows Server 2022 DC. aktueller Updatestand.

Unterbau ist Hyper-V

~22 User

M365 mit AD-Sync auf einem anderen Server, so wie man es macht.

Cloud Telefonanlage, auf dem RDS nur der Client dafür.

Ein paar Sonderprogramme, wo allerdings nur der Client auf dem RDS installiert ist, welcher direkt mit den richtigen Servern spricht.

Jetzt passiert Folgendes:

Die User melden sich an, manche um 7 Uhr und manche um 8 Uhr.

Um 7 Uhr gibt es keine Probleme.

Um 8 Uhr schießt die Prozessorlast auf 100% für EXAKT 30 min, bis alle angemeldet sind. Dann läuft alles sauber.

Das war der Ausgangsstand.

Folgendes haben wir getan:

Eine RDS-Farm mit 2 Terminalservern (Prozessoren und RAM geteilt, weil BP) und einem ConnectionBroker, um die Last zu verteilen.

Profile auf FSLogix umgebaut und zwar komplett neu, weil wir vermutet haben, dass es an den lokalen Profilen liegt.

Daraus wurde aufgrund diverser anderer Probleme mit M365 wieder ein RDS in der Farm, welcher wieder ALLE User aufnimmt, durch Loadbalancing eingerichtet und wieder die volle CPU und RAM. Der andere existiert aber noch.

In der letzten Woche, nachdem wir alles konfiguriert und eingerichtet haben, lief alles sauber.

Auch Montag und Dienstag, wo alle angemeldet waren.

Heute morgen plötzlich das gleiche Phänomen. CPU-Last auf 100% für EXAKT 30 min. Ohne ersichtlichen Grund.

Profile sind ausgeschlossen, da komplett neu. Server ist mMn ausgeschlossen, da komplett neu.

Die Eventlogs haben keine Aussagekraft, da dort nur steht, dass er den Benutzer nicht anmelden kann oder aber ein Timeout bei der Anmledung stattfindet. Beides zurückzuführen auf die Volllast.

Die Standrechner des Kunden, haben wir einzeln angemeldet und überprüft, ob die Probleme machen, nichts.

Ich bin mit meinem technischen Verständnis am Ende.

Hat das jemand schon einmal erlebt?

Was haben wir übersehen?

Wir sitzen seit über 6 Wochen mit 5 hochqualifizierten Technikern mit mehreren Jahren Berufserfahrung an diesem Problem.

Please also mark the comments that contributed to the solution of the article

Content-Key: 7889093113

Url: https://administrator.de/contentid/7889093113

Printed on: April 27, 2024 at 07:04 o'clock

26 Comments

Latest comment

Ach ich habe was vergessen, entschuldigung.

Ich habe alle "Lösungen" für dieses Problem ausprobiert.
Regeinträge, Firewall, AV, reroll auf vorherigen Updatestand, alles.
Keine Verbesserung.

Moin.

Wenn Du dich als Admin vor dem Problem bereits angemeldet hast, kannst Du doch live verfolgen, was passiert. Taskmanager sagt was? Procmon sagt was? Das sind die Standarddiagnosen, die man sofort heranziehen sollte.

Wie ist denn die Auslastung an der AD? Bekommt die überhaupt CPU-Zeit vom Hypervisor (der selbe, wie die RD-SH?)? Du schreibst nicht, warum 32 vCPU und wie viele pCPU überhaupt vorhanden sind. Faustregel erstmal runter auf 8 vCPU, genaueres würde ich mir unter esxtop angucken, keine Ahnung wie genau man da unter Hyper-V vorgeht.

In der Zeit der Auslastung kann sich kein Benutzer anmelden? Du schreibst nicht so klar, wie sich die Auslastung auswirkt. Was passiert denn im Task Manager? Kann man das an bestimmten Prozessen fest machen?

Hallo, danke für die schnelle Rückmeldung.

Tatsächlich haben wir das getan.
Nur die Anmeldeprozesse gehen hoch und "System".

System ist dann immer zwischen 90 und 100%, bis alle angemeldet sind.

@ukulele-7:

Die Auslastung der AD ist nominal, keine Spitzen oder Ähnliches.
Der Hypervisor verteilt die nach Standard.

32 Kerne haben wir bereits lange vorher eingerichtet, weil die Last immer mehr wurde.
Physisch sind über 200 Kerne vorhanden, da es sich um ein HCI-Cluster handelt.

Die Last passiert bei der Anmeldung, wenn sich alle/viele gleichzeitig anmelden und dann friert das Bild ein, bereits angemeldete User können nur schleppend arbeiten.

Der Taskmanager zeigt nur, dass SYSTEM ausgelastet ist und neben den Diensten für Remotedesktop die höchste Last macht.

Moin @dersysops,

Der Taskmanager zeigt nur, dass SYSTEM ausgelastet ist und neben den Diensten für Remotedesktop die höchste Last macht.

Die Last passiert bei der Anmeldung, wenn sich alle/viele gleichzeitig anmelden und dann friert das Bild ein, bereits angemeldete User können nur schleppend arbeiten.

führe mal auf deinen Hyper-V Nodes, den folgenden Befehl aus. 😉

Power-Shell als Admin

Get-VMSwitch | Set-VMSwitch -EnableSoftwareRsc $false -EnableRscOffload $false

Kannst im laufenden Betrieb machen.

Und die 32 Kerne bringen dir in der VM nicht wirklich einen Vorteil, eher das Gegenteil davon.

Des weiteren.
Habt ihr eine Dritthersteller-AV im Einsatz?
Wenn ja, dann deinstallieren bitte den Windows Defender auf den Servern, wenn nicht schon geschehen.

Power-Shell als Admin

Remove-WindowsFeature -Name "Windows-Defender"

Gruss Alex

Zitat von @MysticFoxDE:

Moin @dersysops,

Der Taskmanager zeigt nur, dass SYSTEM ausgelastet ist und neben den Diensten für Remotedesktop die höchste Last macht.

Die Last passiert bei der Anmeldung, wenn sich alle/viele gleichzeitig anmelden und dann friert das Bild ein, bereits angemeldete User können nur schleppend arbeiten.

führe mal auf deinen Hyper-V Nodes, den folgenden Befehl aus. 😉

Power-Shell als Admin

Get-VMSwitch | Set-VMSwitch -EnableSoftwareRsc $false -EnableRscOffload $false

Remove-WindowsFeature -Name "Windows-Defender"

Gruss Alex

Hallo Mysticfox,

das werde ich nachher mal testen.
Es ist tatsächlich momentan, bitte nicht steinigen, gar kein AV installiert, auch kein Defender. Das war nämlich auch unsere Idee. Wir müssen allerdings jetzt bald wieder einen draufmachen. Habe da auch massive Bauchschmerzen mit.

Die 32 Kerne hatten wir vorher tatsächlich auch schon einmal herabgesetzt. Das hat NOCH mehr Probleme gemacht, als vorher. Da dauerte das Schauspiel ne knappe Stunde.

Ich sollte auch erwähnen, dass wir mehrere Kunden mit einem Ähnlichen Konstrukt haben, auch mit mehr Usern, wo das Problem nie auftritt.

Du hast noch nichts zu Monitoring gesagt (procmon) was tut der Prozess "system" denn, was passiert parallel im Dateisystem?

Moin @dersysops,

Ich sollte auch erwähnen, dass wir mehrere Kunden mit einem Ähnlichen Konstrukt haben, auch mit mehr Usern, wo das Problem nie auftritt.

ich kennen diese Probleme insbesondere bei Hyper-V, aber nicht nur, leider viel zu gut und habe dazu schon etliche Romane selber geschrieben und an vielen anderen, kräftig mitgearbeitet.

Folgend einer der etwas grösseren.

https://community.spiceworks.com/topic/2225989-server-2019-network-perfo ...

Die grössten Schmerzen solltet ihr durch das deaktivieren von RSC eigentlich beseitigt bekommen.

Gruss Alex

HCI-Cluster ist ja schön und gut, aber wieviele vCores passen in einen physischen NUMA-Node? vCPU und vRAM sollten eigentlich immer kleiner sein als pCore und pRAM eines Hosts. vCore allgemein sollen nicht über 8 pro VM liegen, das ist allerdings in Einzelfällen diskutabel. (Dann aber bitte auch die Wartezeiten im Hypervisor-Scedular einmal anschauen.) Grundsätzlich dürfte ein RD-SH auch mit 10 Power Usern bei 8 Kernen klar kommen.

Das mag jetzt nicht dein Problem selbst lösen, das scheint wirklich Windows related zu sein, aber es kann leicht zu Performance-Problemen führen und auch merkwürdige Nebeneffekte haben. Du tust deiner VM keinen gefallen.

Guten Morgen,

@MysticFoxDE
Das Abschalten von softwareRSC hat leider nicht den gewünschten Erfolg gebracht, hat es eher noch schlimmer gemacht. Der Kunde meldete heute, dass teilweise die Verbindung gar nicht zu Stande kam, vorher dauerte es einfach nur lange.

Vorher brauchten sie 30 Minuten, heute teilweise 1 Stunde und länger.

Moin @dersysops:

Das Abschalten von softwareRSC hat leider nicht den gewünschten Erfolg gebracht, hat es eher noch schlimmer gemacht. Der Kunde meldete heute, dass teilweise die Verbindung gar nicht zu Stande kam, vorher dauerte es einfach nur lange.

Vorher brauchten sie 30 Minuten, heute teilweise 1 Stunde und länger.

ähm, bitte was ... wofür benötigen die den bitte über 30 Minuten?
Sag jetzt aber bitte nicht, nur um die RDP Sitzung zu öffnen.

Dar ich mir das mal per Teamviewer genauer anschauen?

Gruss Alex

Zitat von @MysticFoxDE:

Moin @dersysops:

ähm, bitte was ... wofür benötigen die den bitte über 30 Minuten?
Sag jetzt aber bitte nicht, nur um die RDP Sitzung zu öffnen.

Dar ich mir das mal per Teamviewer genauer anschauen?

Gruss Alex

Doch, genau das.
Gerne.

Allerdings ist das nur morgens. sobald alle einmal angemeldet sind, ist anmelden und auch trennen und wieder verbinden kein Problem mehr.

Das bedeutet, du wirst genauso viel sehen wie wir, denn die Logs sagen nichts aus.

die Logs sagen nichts aus

Hast Du mit Procmon geloggt?

Procmon produziert natürlich unfassbar große Logs und wenn man nicht recht weiß, wonach man sucht, ist das schwierig. Zudem reduziert er duch das Gelogge massiv die Leistung und macht die Vorgänge noch länger.

Dennoch: procmon wird etwas aussagen können. Filtere mal auf den Prozess ntoskrnl.exe (der steht für Kernel und System)

Ich will nicht das Thema wechseln aber nochmal eine Rückfrage von mir: ob bei FSLogix alles passt. Der Ablauf müsste wie folgt sein:

1) Der Benutzer ist abgemeldet - auf dem FSLogix Pfad liegt eine VHDX für den Benutzer mit passenden NTFS-Rechten und KEINE .rw-Datei.
2) Der Benutzer meldet sich an - es wird sofort eine .rw-Datei erstellt die langsam ein bisschen in der Größe wächst aber vermutlich irgendwo bei <500MB bleibt. Die .rw-Datei darf nicht irgendwo unter Windows\Temp angelegt werden.
3) In der Profil-Liste vom Windows des RD-SH steht das Profil des angemeldeten Benutzers als Typ "lokal". Ist das nicht der Fall, kann im Hintergrund immer noch ein Roaming Profile zusätzlich synchronisiert werden.

Wie groß sind die Benutzerprofile? Ist zwischen Profilspeicher und RD-SH eine Subnetztrennung / Firewall oder ähnliches?

Moin @dersysops,

Doch, genau das.

😱 ... das ist ja echt übel, bei solchen Anmeldezeiten hätten mir unsere Kunden schon längst das Fell über die Ohren gezogen.

Allerdings ist das nur morgens. sobald alle einmal angemeldet sind, ist anmelden und auch trennen und wieder verbinden kein Problem mehr.

Oh je, die Aussage lässt mich nichts gutes vermuten. 😬

Kannst du mal als nächstes morgens auf dem Server wo die Profile liegen, bitte mal den Ressourcenmonitor mit laufen lassen und insbesondere die Antwortzeiten der Datenträgeraktivitäten im Auge behalten.

Ich gehe mal davon aus, das die Server auf SSD's laufen, wenn ja, dann solltest du hier im Optimalfall keine Latenzen im zweistelligen Bereich sehen, denn das wäre ein sehr schlechtes Zeichen, vor allem wenn diese in den dreistelligen oder gar vierstelligen Bereich rutschen.

Gruss Alex

Moin @ukulele-7,

Wie groß sind die Benutzerprofile?

bei manchen User unserer Kunden, sind die VHDX deren Userprofiledisks zum Teil weit über 50G gross und bei diesen usern dauert die Anmeldung in der Regel auch nur wenige Sekunden.

Ist zwischen Profilspeicher und RD-SH eine Subnetztrennung / Firewall oder ähnliches?

👍👍👍, das ist eine sehr gute Frage!
FW's oder SGW's zischen den SH's und dem Fileserver auf dem die Userprofiledisks liegen, haben mir in der Vergangenheit leider auch schon ähnlichen "Spass" beschert.

Gruss Alex

Zitat von @MysticFoxDE:

Moin @ukulele-7,

Wie groß sind die Benutzerprofile?

bei manchen User unserer Kunden, sind die VHDX deren Userprofiledisks zum Teil weit über 50G gross und bei diesen usern dauert die Anmeldung in der Regel auch nur wenige Sekunden.

Das ist richtig, bei mir sind die bis zu 200GB und das ist egal. Es sei denn natürlich das Profil steht in Windows am RD-SH noch auf "Roaming". Dann kann es sein das das alte roaming profile mit der VHDX synchronisiert, also quasi beides statt findet.

Man könnte auch mal einen komplett neuen, noch nie vorher existierenden User anlegen. Wenn das Problem irgendeinen Profilbezug hat, müsste sich die Anmeldezeit deutlich unterscheiden.

Haben wir ausgeschlossen, da wir das Problem kannten.
Es gibt nur noch FS-Logix Profile, keine Roaming-Profiles.

Zitat von @ukulele-7:

Ich will nicht das Thema wechseln aber nochmal eine Rückfrage von mir: ob bei FSLogix alles passt. Der Ablauf müsste wie folgt sein:

1) Der Benutzer ist abgemeldet - auf dem FSLogix Pfad liegt eine VHDX für den Benutzer mit passenden NTFS-Rechten und KEINE .rw-Datei.
2) Der Benutzer meldet sich an - es wird sofort eine .rw-Datei erstellt die langsam ein bisschen in der Größe wächst aber vermutlich irgendwo bei <500MB bleibt. Die .rw-Datei darf nicht irgendwo unter Windows\Temp angelegt werden.
3) In der Profil-Liste vom Windows des RD-SH steht das Profil des angemeldeten Benutzers als Typ "lokal". Ist das nicht der Fall, kann im Hintergrund immer noch ein Roaming Profile zusätzlich synchronisiert werden.

Wie groß sind die Benutzerprofile? Ist zwischen Profilspeicher und RD-SH eine Subnetztrennung / Firewall oder ähnliches?

korrekt.

Genau so läuft es.

Keine Subnetzttrennung, keine Firewall.

Zitat von @MysticFoxDE:

Moin @dersysops,

Doch, genau das.

😱 ... das ist ja echt übel, bei solchen Anmeldezeiten hätten mir unsere Kunden schon längst das Fell über die Ohren gezogen.

Allerdings ist das nur morgens. sobald alle einmal angemeldet sind, ist anmelden und auch trennen und wieder verbinden kein Problem mehr.

Läuft auf nVMEs

Ja der Kunde ist auch alles andere als erfreut. Kann ich nachvollziehen.
Das mit den Latenzen werde ich Montag früh mal prüfen.

Guten Morgen an Alle,

Ich habe heute morgen einmal geschaut, wie die Antwortzeiten der Storages sind.

Zuerst einmal danke an @MysticFoxDE für den Hinweis!

Die Antwortzeiten sind bei Anmeldung des Users (hier egal welcher) zwischenzeitig jenseits der 200ms.
Auffällig sind hier die hohen Zahlen bei allem, was mit "AppData" zu tun hat. Hier bewegen wir uns bei Anmeldung im Bereich zwischen 25 und 350 ms.

Auch im "Tagesbetrieb", gibt es dauerhafte Zeiten von 5-35ms für diverse Zugriffe. Summiert, lassen die die CPU ziemlich kämpfen.

Des Weiteren ist auffällig, dass OneDrive hier massiv Antwortzeit generiert, teilweise 593ms. Auch Userunabhängig.

Zur Info, da ich es am Anfang vergessen habe: Wir arbeiten mit einem S2D Cluster mit nVMEs (keine HHDs oder "normale" SSDs verbaut)
Wir nehmen das "AppData" Verzeichnis der User BEWUSST nicht mit, da es ein Drittprogramm gibt, welches damit Probleme hat, wenn die ausgelagert werden.

Ich habe das "FailoverClusterManagement" für diesen Test abgeschaltet und den FS, sowie den RDS auf eine Node geschoben. Das hat tatsächlich ein wenig geholfen. Dennoch bleiben die teilweise hohen Zugriffszeiten.

Laut DELL, sollte ein S2D auf unseren Nodes irgendwo bei 5ms liegen und definitiv nicht weit darüber. Ja das sind geschönte Zahlen, aber jenseits der 10ms ist dann doch sehr auffällig.

Ist denn DELL da jetzt selbst dran?

Moin @dersysops,

Die Antwortzeiten sind bei Anmeldung des Users (hier egal welcher) zwischenzeitig jenseits der 200ms.
Auffällig sind hier die hohen Zahlen bei allem, was mit "AppData" zu tun hat. Hier bewegen wir uns bei Anmeldung im Bereich zwischen 25 und 350 ms.

😱 ... 😭

Laut DELL, sollte ein S2D auf unseren Nodes irgendwo bei 5ms liegen und definitiv nicht weit darüber. Ja das sind geschönte Zahlen, aber jenseits der 10ms ist dann doch sehr auffällig.

Ähm, sagst DELL einen lieben Gruss von mir.
Das folgende sind die Antwortzeiten auf einem RDS eines unserer Kunden auf dem gerade über 20 User angemeldet sind.

Dieser RDS läuft storagetechnisch übrigens auf einem über 6 Jahre altem AllFlash SAN, welches wahrscheinlich noch mit SAS6G SSD's bestückt ist.

Sprich, bei einem Storagesystem wie S2D, wo die Datenträger direkt am Node per PCIE dranhängen, sollte solche Antwortzeiten wie du sie schilderst, eigentlich unmöglich sein. 😔

Gruss Alex

Das mit DELL ist von der offiziellen DELL Seite für S2D.

Bei DELL entsprechenden support ans Telefon zu bekommen ist, gelinde gesagt, schwierig.

Falsch formuliert, entschuldigung.

Also Fazit:
Es liegt offenbar an den Antwortzeiten. Warum genau DIESER Kunde allerdings Probleme macht, bleibt ein Rätsel.
Wir haben, wie gesagt, auch andere Kunden mit ähnlichem Konstrukt, die keinerlei Probleme haben.

Moin @dersysops,

Also Fazit:
Es liegt offenbar an den Antwortzeiten. Warum genau DIESER Kunde allerdings Probleme macht, bleibt ein Rätsel.
Wir haben, wie gesagt, auch andere Kunden mit ähnlichem Konstrukt, die keinerlei Probleme haben.

ich schätze mal, das die Netzwerkverbindung zwischen den Nodes über die das S2D "synchronisiert" wird, einen ordentlichen Schuss hat und daher werden die Storagezugriffe auch verzögert. 😉

Teste mal die Strecke mit iPerf oder am besten mit diskspd um RDMA richtig anzutriggern.

Gruss Alex

German Question Windows Server Hyper-V Microsoft Windows Network