Die Geschwindigkeit beim Öffnen von Dateien (PDF, Excel,..) auf dem RDS Server ist extrem langsam.

[magicpeter 11]

Moin,

wir betreiben einen windows 2019 Hyper-V mit 6 vServern. Darunter ist auch ein RDS-Server.

Seit geraumer Zeit tritt immer wieder das Geschwindigkeitsproblem auf das beim Öffnen von Dateien (PDF, Excel,..) in der RDP Sitzung das extrem lange dauert.

30 Sekunden bis zu einer Minute.

Auf dem RDSServer ist keine Last. Auch auf dem Fileserver ist keine Last. Auch auf dem Hyper-V ist keine Last.

Nachdem der RDSServer neugestartet wurde tritt das Problem nicht mehr auf.

 

Komisch oder.

 

Wer hat das schon mal erlebt oder einen Lösungsansatz dafür.

 

Umgebung:

Supermicroserver

Supermicro Mainboard X11SPi-TF                                                                           
CPU 1 x Intel XEON Silver 4214R (12 Kerne, 2,4 GHz, 24 Logische Prozessoren)
Raid OnBoard Intel® C622 Chipsatz
Performance-Speicher: 8 TB SSD - Raid 1
SAN-Speicher:  8 TB HDD - Raid 1
Hauptspeicher: 256 GB (8x32 GB DDR4-3200, ECC Reg) 
(8x DIMM slots)
Netzwerkkarten: 2 x 1 GB Broadcom 5720 Dual Port, 2 x 10 GB Intel X722, 1 x IPMI Port 
Redundante Stromversorgung: 2 x 400W
Kühlung: Lüfter mit PWM-Drehzahlsteuerungen
Erweiterung: 5 x PCI-E
 

OS:

Windows 2019 auf dem Hyperbolischen-V und allen VM´s

 

VM RDSServer:

vCPU: 4

RAM: 24 GB

 

 

 

 

[testperson 1.677]

Hi,

 

du hast den Lösungsansatz doch schon selber gefunden:

vor 2 Minuten schrieb magicpeter:

Nachdem der RDSServer neugestartet wurde tritt das Problem nicht mehr auf.

 

boote den RDSH "notfalls" jede Nacht durch.

 

Gruß

Jan

[magicpeter 11]

vor einer Stunde schrieb testperson:

Hi,

 

du hast den Lösungsansatz doch schon selber gefunden:

 

boote den RDSH "notfalls" jede Nacht durch.

 

Gruß

Jan

Moin Jan, ja aber das ist natürlich nur ein Workaround.

Ich würde gerne die Ursache kennen und das Problem beheben.

 

Hat jemand eine Idee woran da liegen kann?

[testperson 1.677]

vor 19 Minuten schrieb magicpeter:

ja aber das ist natürlich nur ein Workaround.

Nein. 

 

vor 24 Minuten schrieb magicpeter:

Ich würde gerne die Ursache kennen und das Problem beheben.

Viel Erfolg.

[Nobbyaushb 1.471]

vor 56 Minuten schrieb magicpeter:

Moin Jan, ja aber das ist natürlich nur ein Workaround.

Ich würde gerne die Ursache kennen und das Problem beheben.

Zunächst würde ich bei einer VM erst mal auf den von meinem Spezi empfohlenen RAM Bereich gehen - 8, 16, 32 64... also bei dir 32GB
Was läuft den sonst auf dem Host?
Wie wiele User arbeiten mit dem RDS Host?

Eventuell auf 8 Kerne gehen...

Und bei uns in der Firma haben wir die Suche nach drei Wochen eingestellt und booten die RDS alle 48 Stunden per Script - jeden Tag geht auch

[daabm 1.354]

So ist das hier auch - wir haben Hunderte von Terminal Servern (Citrix, nicht RDS, aber das Grundproblem ist das gleiche). Die werden alle wechselnd jede 2. Nacht gebootet.

[BOfH_666 577]

vor 9 Stunden schrieb magicpeter:

Hat jemand eine Idee woran da liegen kann?

Wenn Client-Software auf Servern ausgeführt wird. Die ist eben nicht auf Dauerbetrieb ausgelegt.  🤷🏼‍♂️

[magicpeter 11]

Alles klar Männer habe den Autoreboot schon eingestellt.

 

Danke euch....

[magicpeter 11]

Leider ist der Reboot nicht die Lösung.

 

Heute morgen auch nach dem Reboot dauert das Öffnen der Dateien wieder 30 bis 60 Sekunden auf den RDSServer.

 

Hat jemand noch einen andere Idee?

[testperson 1.677]

Dann schmeiß den Prozessmonitor an und prüfe, wo die Verzögerungen auftreten: Prozessmonitor - Sysinternals | Microsoft Learn

[magicpeter 11]

vor 13 Minuten schrieb testperson:

Dann schmeiß den Prozessmonitor an und prüfe, wo die Verzögerungen auftreten: Prozessmonitor - Sysinternals | Microsoft Learn

Gute Idee. Werde ich gleich mal ausprobieren und analysieren was da abläuft.

 

[magicpeter 11]

Ich bin aber doch erst einmal etwas grober angefangen.

 

Verwenden des Systemdatei-Überprüfungsprogramms (SFC.exe) zur Problembehandlung bei fehlenden oder beschädigten Systemdateien

https://support.microsoft.com/de-de/topic/verwenden-des-systemdatei-überprüfungsprogramms-sfc-exe-zur-problembehandlung-bei-fehlenden-oder-beschädigten-systemdateien-79aa86cb-ca52-166a-92a3-966e85d4094e

 

sfc /scannow

Ergebnis: Der Windows-Ressourcenschutz hat beschädigte Dateien gefunden, die teilweise nicht repariert werden konnten.

Bei Onlinereparaturen finden Sie Details in der CBS-Protokolldatei unter

windir\Logs\CBS\CBS.log. Beispiel C:\Windows\Logs\CBS\CBS.log. Bei Offlinereparaturen

finden Sie Details in der durch das /OFFLOGFILE-Kennzeichen angegebenen Protokolldatei.

 

Log ansehen

C:\Windows\Logs\CBS\CBS.log

 

Server Neustarten

 

Dism /Online /Cleanup-Image /ScanHealth

Ergebnis: Der Komponentenspeicher kann repariert werden

 

Dism /Online /Cleanup-Image /CheckHealth

Ergebnis: Der Komponentenspeicher kann repariert werden

 

Dism /Online /Cleanup-image /Restorehealth

Die Quelldateien wurden nicht gefunden.

Geben Sie mit der Option "Quelle" den Ort der Dateien an, die zum Wiederherstellen des Features erforderlich sind. Weitere Informationen zum Angeben eines Quellorts finden Sie unter "http://go.microsoft.com/fwlink/?LinkId=243077".

 

Die DISM-Protokolldatei befindet sich unter „C:\WINDOWS\Logs\DISM\dism.log".

 

So jetzt schaue ich den Spaß heute Abend noch mal an und versuche mit Quelle den Komponentenspeicher zu reparieren.

 

[magicpeter 11]

So noch mal eine kleine Rückmeldung.

 

Konnte jetzt alle Systemdateien reparieren.

 

Wichtig: Erst DISM und dann SFC!!!

 

Hier meine Vorgehensweise:

 

Systemreparatur, Wiederherstellungskonsole

https://uwe-kernchen.de/phpmyfaq/index.php?action=faq&cat=2&id=27&artlang=de

 

DISM

https://uwe-kernchen.de/phpmyfaq/index.php?solution_id=1334

 

 

Dism /Online /Cleanup-Image /ScanHealth

Ergebnis: Der Komponentenspeicher kann repariert werden

 

Dism /Online /Cleanup-Image /CheckHealth

Ergebnis: Der Komponentenspeicher kann repariert werden

 

Dism /Online /Cleanup-image /Restorehealth

Die Quelldateien wurden nicht gefunden.

Geben Sie mit der Option "Quelle" den Ort der Dateien an, die zum Wiederherstellen des Features erforderlich sind. Weitere Informationen zum Angeben eines Quellorts finden Sie unter "http://go.microsoft.com/fwlink/?LinkId=243077".

 

Die DISM-Protokolldatei befindet sich unter „C:\WINDOWS\Logs\DISM\dism.log".

 

Windows 2019 ISO runterladen und mounten (LW: F:) und Befehl absetzen

dism /online /cleanup-image /restorehealth /source:WIM:F:\sources\install.wim:1 /limitaccess

 

 

Server Neustarten

 

Verwenden des Systemdatei-Überprüfungsprogramms (SFC.exe) zur Problembehandlung bei fehlenden oder beschädigten Systemdateien

https://support.microsoft.com/de-de/topic/verwenden-des-systemdatei-überprüfungsprogramms-sfc-exe-zur-problembehandlung-bei-fehlenden-oder-beschädigten-systemdateien-79aa86cb-ca52-166a-92a3-966e85d4094e

 

sfc /scannow

Ergebnis: Der Windows-Ressourcenschutz hat beschädigte Dateien gefunden und erfolgreich repariert.

Bei Onlinereparaturen finden Sie Details in der CBS-Protokolldatei unter

windir\Logs\CBS\CBS.log. Beispiel C:\Windows\Logs\CBS\CBS.log. Bei Offlinereparaturen

finden Sie Details in der durch das /OFFLOGFILE-Kennzeichen angegebenen Protokolldatei.

Log ansehen

C:\Windows\Logs\CBS\CBS.log

 

So mal schauen ob der Server jetzt anständig läuft... ;) 

[Nobbyaushb 1.471]

Danke für deine ausführliche Rückmeldung 

 

Den automatischen Neustart alle z.B. 48 Stunden würde ich trotzdem in Erwägung ziehen

 

Vielleicht reicht ja auch einmal am Wochenende 

Muss man halt probieren…

[magicpeter 11]

vor 17 Minuten schrieb Nobbyaushb:

Danke für deine ausführliche Rückmeldung 

 

Den automatischen Neustart alle z.B. 48 Stunden würde ich trotzdem in Erwägung ziehen

 

Vielleicht reicht ja auch einmal am Wochenende 

Muss man halt probieren…

Alles klar, gerne.

Den automatischen Neustart habe ich jetzt auf täglich eingestellt und ich denke das schadet nicht....