6
Win2003 Terminalserver sehr langsam
Perfomance-Probleme beim Zugriff auf Terminalserver mittel Terminal-Clients
Hi,
ich betreue z.z. einige Win2003-Terminalserver, wo die User mittels Terminalclients und Citrix Metaframe darauf zugreifen können. Die jeweiligen "Eigene Dateien"-Ordner werden über OpenAFS angesprochen.
In letzter Zeit häuft sich aber das Problem, dass der Server sehr unter Perfomance-Probleme leidet und auf Dauer ist ein Wiederaufspielen des Master-Images keine wirklich vernünftige Lösung.
Die Perfomance-Probleme äußern sich dadurch, dass mittendrin einfach der Desktop am Terminalclient für gewisse Zeit einfriert oder die Verarbeitunggeschwindigkeit derart herabgesetzt ist, dass Arbeiten nur noch mit viel Geduld möglich ist.
Ein Blick in den Task-Manager (oder auch bspw. SysInternals ProcessExplorer) zeigt keine auffälligen Dienste oder andere Prozesse am Laufen. Meine Vermutung, der Server sei irgendwie kontaminiert, wurde größtenteils durch diverse Anti-Viren-, Anti-Rootkit- und Anti-Spyware-Tests widerlegt (sie haben nicht Alarm geschlagen).
Am Netzwerk kanns nicht liegen, da andere (Multimedia-)PCs an das gleiche Netz angeschlossen sind und problemlos Daten austauschen können.
Ich wollt mal daher fragen, ob andere noch weitere Ideen haben, denn mittlerweile bin ich recht ahnungslos, woran der Fehler liegen könnte.
Gruß,
Volcano
Hi,
ich betreue z.z. einige Win2003-Terminalserver, wo die User mittels Terminalclients und Citrix Metaframe darauf zugreifen können. Die jeweiligen "Eigene Dateien"-Ordner werden über OpenAFS angesprochen.
In letzter Zeit häuft sich aber das Problem, dass der Server sehr unter Perfomance-Probleme leidet und auf Dauer ist ein Wiederaufspielen des Master-Images keine wirklich vernünftige Lösung.
Die Perfomance-Probleme äußern sich dadurch, dass mittendrin einfach der Desktop am Terminalclient für gewisse Zeit einfriert oder die Verarbeitunggeschwindigkeit derart herabgesetzt ist, dass Arbeiten nur noch mit viel Geduld möglich ist.
Ein Blick in den Task-Manager (oder auch bspw. SysInternals ProcessExplorer) zeigt keine auffälligen Dienste oder andere Prozesse am Laufen. Meine Vermutung, der Server sei irgendwie kontaminiert, wurde größtenteils durch diverse Anti-Viren-, Anti-Rootkit- und Anti-Spyware-Tests widerlegt (sie haben nicht Alarm geschlagen).
Am Netzwerk kanns nicht liegen, da andere (Multimedia-)PCs an das gleiche Netz angeschlossen sind und problemlos Daten austauschen können.
Ich wollt mal daher fragen, ob andere noch weitere Ideen haben, denn mittlerweile bin ich recht ahnungslos, woran der Fehler liegen könnte.
Gruß,
Volcano
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 32520
Url: https://administrator.de/forum/win2003-terminalserver-sehr-langsam-32520.html
Ausgedruckt am: 19.04.2025 um 13:04 Uhr
6 Kommentare
Neuester Kommentar
Hast du mal auf die Switche geschaut wie hoch der Datendurchsatz zu dieser Zeit ist oder mal ins Netzwerk gelauscht welche anfragen in diesen Zeiten durch das Netz gestellt werden? Die Switche von deinen TS Clients können ja auch überlastet sein.
Sind die Clients im Lan oder WAN ?
Sind die Clients im Lan oder WAN ?
Hallo coxsrcrub.
Der Datendurchsatz ist normal. Habe auch mit TCP View angeschaut, welche Programme auf das Netzwerk/Internet zugreifen wollen. Habe nichts auffälliges finden können.
Die Clients befinden sich in einem abgeschotteten LAN. Die Terminalserver selbst können nur durch einen Proxy-Server mit der "Außenwelt" kommunizieren.
Der Datendurchsatz ist normal. Habe auch mit TCP View angeschaut, welche Programme auf das Netzwerk/Internet zugreifen wollen. Habe nichts auffälliges finden können.
Die Clients befinden sich in einem abgeschotteten LAN. Die Terminalserver selbst können nur durch einen Proxy-Server mit der "Außenwelt" kommunizieren.
Findest du igendwelche Eieignisse in den Protokollen deines Servers?
Werden im Proxy Pakete verworfen?
Schau auch mal nach Paketen die nicht Protokolliert werden.
Ist nicht zufällig ein Bluecoat?
Werden im Proxy Pakete verworfen?
Schau auch mal nach Paketen die nicht Protokolliert werden.
Ist nicht zufällig ein Bluecoat?
laufen bei deinen verteilten Dateisystem vielleicht irgendwelche Synchronisationen inder Zeit im Hintergrund?
Datensicherung Tagsüber wird ja ausscheiden.
Habe übersehen das du die Ereignisse am Server schon überprüft hast.
Mehr Ansätze finde ich so aus dem Stehgreif auch nicht mehr.
Datensicherung Tagsüber wird ja ausscheiden.
Habe übersehen das du die Ereignisse am Server schon überprüft hast.
Mehr Ansätze finde ich so aus dem Stehgreif auch nicht mehr.
Also in der Ereignisanzeige steht auch nichts was mich weiterbringen könnte.
Ob am Proxy Pakete verworfen werden oder nicht, kann ich leider nicht sagen, da ich keinen administrativen Zugriff auf den Proxy habe.
Datensynchronisationen werden immer nachts durchgeführt.
Aber trotzdem danke für deine Mühen, mal sehen ob andere User weitere Ideen haben...
Ob am Proxy Pakete verworfen werden oder nicht, kann ich leider nicht sagen, da ich keinen administrativen Zugriff auf den Proxy habe.
Datensynchronisationen werden immer nachts durchgeführt.
Aber trotzdem danke für deine Mühen, mal sehen ob andere User weitere Ideen haben...
Moin,
einen Ansatz habe ich nun doch noch.
Wenn du einen SQL Server einsetzt auf der mehrere Datenbanken gleichzeitig laufen und du zwei XEON Prozessoren Prozessoren laufen lässt kann es zu einen Phänomen wie deinen kommen. Der Server läßt in diesem Fall einfach die DB Anfragen einiger Clients verhungern, welches sich unterschiedlich äußern kann, z.B. einfrieren der Sitzung oder zähe Arbeitsweise.
Diesen Fehler kannst du aber ausschließen wenn du nach einem einfachen Reboot des Servers genau die gleiche zähe Arbeitsweise siehst.
Sollte dies nicht der Fall sein weise der DB nur die CPU's eins; drei und vier zu. CPU 0 steht dann anderen Anfragen zur Verfügung. Bei Veränderungen ist allerdings ein Reboot nötig.
Ich kenne das Problem nur bei Windows SQL 2000 Servern die auf einem WS 2003 laufen und mit diesen CPU's, vielleicht ist dies aber auch in anderen Konstellationen möglich.
Lass dir im jedem Fall den Tracker deines Proxy zweigen mit allen verworfenen Paketen für die Zeit in der der Fehler Auftritt. Weise darauf hin das du die ungefilterten Protokolle sehen möchtest, da viele Admins Broadcast o.ä. einfach ausfiltern.
einen Ansatz habe ich nun doch noch.
Wenn du einen SQL Server einsetzt auf der mehrere Datenbanken gleichzeitig laufen und du zwei XEON Prozessoren Prozessoren laufen lässt kann es zu einen Phänomen wie deinen kommen. Der Server läßt in diesem Fall einfach die DB Anfragen einiger Clients verhungern, welches sich unterschiedlich äußern kann, z.B. einfrieren der Sitzung oder zähe Arbeitsweise.
Diesen Fehler kannst du aber ausschließen wenn du nach einem einfachen Reboot des Servers genau die gleiche zähe Arbeitsweise siehst.
Sollte dies nicht der Fall sein weise der DB nur die CPU's eins; drei und vier zu. CPU 0 steht dann anderen Anfragen zur Verfügung. Bei Veränderungen ist allerdings ein Reboot nötig.
Ich kenne das Problem nur bei Windows SQL 2000 Servern die auf einem WS 2003 laufen und mit diesen CPU's, vielleicht ist dies aber auch in anderen Konstellationen möglich.
Lass dir im jedem Fall den Tracker deines Proxy zweigen mit allen verworfenen Paketen für die Zeit in der der Fehler Auftritt. Weise darauf hin das du die ungefilterten Protokolle sehen möchtest, da viele Admins Broadcast o.ä. einfach ausfiltern.
