magicpeter 9 Geschrieben 4. März Melden Teilen Geschrieben 4. März 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 Zitieren Link zu diesem Kommentar
Beste Lösung testperson 1.534 Geschrieben 4. März Beste Lösung Melden Teilen Geschrieben 4. März 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 1 Zitieren Link zu diesem Kommentar
magicpeter 9 Geschrieben 4. März Autor Melden Teilen Geschrieben 4. März 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? Zitieren Link zu diesem Kommentar
testperson 1.534 Geschrieben 4. März Melden Teilen Geschrieben 4. März 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. 1 Zitieren Link zu diesem Kommentar
Nobbyaushb 1.359 Geschrieben 4. März Melden Teilen Geschrieben 4. März 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 1 Zitieren Link zu diesem Kommentar
daabm 1.185 Geschrieben 4. März Melden Teilen Geschrieben 4. März 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. 1 Zitieren Link zu diesem Kommentar
BOfH_666 568 Geschrieben 4. März Melden Teilen Geschrieben 4. März 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. 🤷🏼♂️ 1 Zitieren Link zu diesem Kommentar
magicpeter 9 Geschrieben 4. März Autor Melden Teilen Geschrieben 4. März Alles klar Männer habe den Autoreboot schon eingestellt. Danke euch.... Zitieren Link zu diesem Kommentar
magicpeter 9 Geschrieben 5. März Autor Melden Teilen Geschrieben 5. März 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? Zitieren Link zu diesem Kommentar
testperson 1.534 Geschrieben 5. März Melden Teilen Geschrieben 5. März Dann schmeiß den Prozessmonitor an und prüfe, wo die Verzögerungen auftreten: Prozessmonitor - Sysinternals | Microsoft Learn 1 Zitieren Link zu diesem Kommentar
magicpeter 9 Geschrieben 5. März Autor Melden Teilen Geschrieben 5. März 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. Zitieren Link zu diesem Kommentar
magicpeter 9 Geschrieben 5. März Autor Melden Teilen Geschrieben 5. März 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. Zitieren Link zu diesem Kommentar
magicpeter 9 Geschrieben 5. März Autor Melden Teilen Geschrieben 5. März 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... ;) Zitieren Link zu diesem Kommentar
Nobbyaushb 1.359 Geschrieben 5. März Melden Teilen Geschrieben 5. März 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… 1 Zitieren Link zu diesem Kommentar
magicpeter 9 Geschrieben 5. März Autor Melden Teilen Geschrieben 5. März 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.... 1 Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.