12
Virtualisierter Terminalserver reagiert plötzlich nicht mehr (CPU-Last 100)
Virtualisierter Terminalserver (Win2003 SP2) reagiert plötzlich nicht mehr (1 - 2 mal pro Tag). 100% CPU-Last, Netzwerkverbindung praktisch tot, Terminalsitzungen werden getrennt.
Nach Anhalten (Pause) und Fortsetzen der virtuellen Maschine im Hyper-V Manager läuft er wieder normal!
Hallo,
ich habe hier folgendes Problem, bei dem ich nicht weiterkomme:
Der Terminalserver (Win2003 SP2) wurde mit SCVMM 2008 R2 virtualisiert und läuft jetzt auf einem Hyper-V Host (Win2008 R2), auf dem sonst keine virtuellen Maschinen laufen.
Ansonsten läuft noch ein physischer Server (Win2003 SBS SP2).
Der virtualisierte Terminalserver (TS) läuft eigentlich ganz normal.
Nur fällt er untertags (d.h., wenn Benutzer angemeldet sind) immer wieder mal aus:
Urplötzlich reagiert er nicht mehr. In den Terminalsitzungen der Benutzer wird der Mauszeiger zur Sanduhr und nichts geht mehr. Teilweise werden die Terminalsitzungen auch getrennt (Verbindung unterbrochen).
Der TS ist aber nicht völlig tot oder abgestürzt, sondern „nur“ total dicht.
Konkret folgende Symptome:
Wenn man den virtuellen TS im Hyper-V Manager verbindet, um ihn „lokal“ bedienen zu können, kann man sich manchmal noch (mit viel Geduld) lokal anmelden.
Alles ist total langsam. In seinem Taskmanager sieht man 100% CPU-Last auf allen Cores, aber keine Prozesse, die außergewöhnlich viel CPU-Last haben.
Die Netzwerkverbindung ist so gut wie tot. Manchmal geht ein Ping, manchmal nicht.
Der physische Hyper-V Host ist während dieser Mätzchen gefühlt etwas träger, aber nicht dicht.
In manchen Fällen erholt sich der TS nach einigen Sekunden bis Minuten wieder von selbst. Dann können die Benutzer ihre getrennten Sitzungen wieder anmelden und weiterarbeiten.
In den meisten Fällen erholt sich der TS aber nicht von selbst, und da hat sich herausgestellt, dass man ihn kurioserweise mit folgendem Trick wieder „anschubsen“ kann:
Einfach im Hyper-V Manager die virtuelle Maschine per rechter Maustaste „anhalten“ und wieder „fortsetzen“.
Danach geht sofort im TS die CPU-Last runter, das Netzwerk funktioniert wieder normal, und die Benutzer können ihre getrennten Sitzungen wieder anmelden und weiterarbeiten.
Nix weiß wie!
Nach Anhalten (Pause) und Fortsetzen der virtuellen Maschine im Hyper-V Manager läuft er wieder normal!
Hallo,
ich habe hier folgendes Problem, bei dem ich nicht weiterkomme:
Der Terminalserver (Win2003 SP2) wurde mit SCVMM 2008 R2 virtualisiert und läuft jetzt auf einem Hyper-V Host (Win2008 R2), auf dem sonst keine virtuellen Maschinen laufen.
Ansonsten läuft noch ein physischer Server (Win2003 SBS SP2).
Der virtualisierte Terminalserver (TS) läuft eigentlich ganz normal.
Nur fällt er untertags (d.h., wenn Benutzer angemeldet sind) immer wieder mal aus:
Urplötzlich reagiert er nicht mehr. In den Terminalsitzungen der Benutzer wird der Mauszeiger zur Sanduhr und nichts geht mehr. Teilweise werden die Terminalsitzungen auch getrennt (Verbindung unterbrochen).
Der TS ist aber nicht völlig tot oder abgestürzt, sondern „nur“ total dicht.
Konkret folgende Symptome:
Wenn man den virtuellen TS im Hyper-V Manager verbindet, um ihn „lokal“ bedienen zu können, kann man sich manchmal noch (mit viel Geduld) lokal anmelden.
Alles ist total langsam. In seinem Taskmanager sieht man 100% CPU-Last auf allen Cores, aber keine Prozesse, die außergewöhnlich viel CPU-Last haben.
Die Netzwerkverbindung ist so gut wie tot. Manchmal geht ein Ping, manchmal nicht.
Der physische Hyper-V Host ist während dieser Mätzchen gefühlt etwas träger, aber nicht dicht.
In manchen Fällen erholt sich der TS nach einigen Sekunden bis Minuten wieder von selbst. Dann können die Benutzer ihre getrennten Sitzungen wieder anmelden und weiterarbeiten.
In den meisten Fällen erholt sich der TS aber nicht von selbst, und da hat sich herausgestellt, dass man ihn kurioserweise mit folgendem Trick wieder „anschubsen“ kann:
Einfach im Hyper-V Manager die virtuelle Maschine per rechter Maustaste „anhalten“ und wieder „fortsetzen“.
Danach geht sofort im TS die CPU-Last runter, das Netzwerk funktioniert wieder normal, und die Benutzer können ihre getrennten Sitzungen wieder anmelden und weiterarbeiten.
Nix weiß wie!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 131354
Url: https://administrator.de/contentid/131354
Ausgedruckt am: 25.11.2024 um 19:11 Uhr
12 Kommentare
Neuester Kommentar
Hm...
ich verwend XEN für die Virtualisierung meiner Server, ich hatte mal das Problem dass einzelne Aktionen von Usern (sehr rechenintensive Prozesse zB) hänger von ein paar Sekunden erzeugten.
Dies ist zwar nicht das selbe Problem, jedoch könntest du folgendes Probieren:
Nimm doch mal von Sysinternals den Process Explorer und lass den mitlaufen (minimiert braucht der am wenigsten Last). Dann kannst du nach dem Hänger vielliecht sehen welcher Prozess das Problem ausgelöst hat. Dazu musst du nur am CPU-Graph über die Spikes (die Spitzen) fahren und erfährst damit den zu diesem Zeitpunkt intensivsten Prozess.
Vielleicht hilfts,
LG Florian http://www.lagg.at/
ich verwend XEN für die Virtualisierung meiner Server, ich hatte mal das Problem dass einzelne Aktionen von Usern (sehr rechenintensive Prozesse zB) hänger von ein paar Sekunden erzeugten.
Dies ist zwar nicht das selbe Problem, jedoch könntest du folgendes Probieren:
Nimm doch mal von Sysinternals den Process Explorer und lass den mitlaufen (minimiert braucht der am wenigsten Last). Dann kannst du nach dem Hänger vielliecht sehen welcher Prozess das Problem ausgelöst hat. Dazu musst du nur am CPU-Graph über die Spikes (die Spitzen) fahren und erfährst damit den zu diesem Zeitpunkt intensivsten Prozess.
Vielleicht hilfts,
LG Florian http://www.lagg.at/
Die Idee mit Process Explorer klingt gut!
Ich werde das ausprobieren.
Da der TS heute schon dreimal stehengeblieben ist, wird in der Produktivumgebung jetzt wieder der alte physische TS reaktiviert.
Der Hyper-V Host mit dem virtuellen TS steht dann isoliert zum Testen zur Verfügung.
Ich werde auch noch den anderen alten physischen Server (Win2003 SBS) virtualisieren, damit er als zweite VM auf dem Hyper-V Host zum Testen zur Verfügung steht.
Mit diesen beiden virtuellen Mühlen werde ich dann versuchen, den Fehler zu provozieren. Bisher ist es mir allerdings im Testbetrieb erst einmal "gelungen", dieses Phänomen zu erhalten (weiß nicht mal, wie).
Naja, werden sehen. Der Process Explorer wird jedenfalls mitlaufen.
Danke für den Hinweis!
Ich werde das ausprobieren.
Da der TS heute schon dreimal stehengeblieben ist, wird in der Produktivumgebung jetzt wieder der alte physische TS reaktiviert.
Der Hyper-V Host mit dem virtuellen TS steht dann isoliert zum Testen zur Verfügung.
Ich werde auch noch den anderen alten physischen Server (Win2003 SBS) virtualisieren, damit er als zweite VM auf dem Hyper-V Host zum Testen zur Verfügung steht.
Mit diesen beiden virtuellen Mühlen werde ich dann versuchen, den Fehler zu provozieren. Bisher ist es mir allerdings im Testbetrieb erst einmal "gelungen", dieses Phänomen zu erhalten (weiß nicht mal, wie).
Naja, werden sehen. Der Process Explorer wird jedenfalls mitlaufen.
Danke für den Hinweis!
Hallo LTom72...
Ich habe das selbe Problem, Terminalserver Win2003 R2 SP2 auf einem Wins2008 R2 64 Bit in Hyper-V virtualisiert. Bei mir ist zusätzlich noch Citrix Presentation Server 4.5 im Einsatz. Auch bei mir ergeben sich gelegentliche Vollauslastungen der CPU der virtuellen Maschine, die bisher nicht nachvollziehbar sind und den Server zum fast Stillstand bringen. Ein kurzzeitiges Anhalten und Fortsetzten des virtuellen Servers bringt sofort Abhilfe. Der Process Explorer hat mir hier nur bedingt geholfen, nachvollziehbare Prozesse fand ich hier nicht.
Hast du in der Zwischenzeit evtl. eine Lösung finden können? Ich habe hier mittlerweile schon 2 Firmen da gehabt, die bisher ebenfalls nicht weiter gekommen sind. Das ist eine ziemlich üble Angelegenheit.
Ich habe das selbe Problem, Terminalserver Win2003 R2 SP2 auf einem Wins2008 R2 64 Bit in Hyper-V virtualisiert. Bei mir ist zusätzlich noch Citrix Presentation Server 4.5 im Einsatz. Auch bei mir ergeben sich gelegentliche Vollauslastungen der CPU der virtuellen Maschine, die bisher nicht nachvollziehbar sind und den Server zum fast Stillstand bringen. Ein kurzzeitiges Anhalten und Fortsetzten des virtuellen Servers bringt sofort Abhilfe. Der Process Explorer hat mir hier nur bedingt geholfen, nachvollziehbare Prozesse fand ich hier nicht.
Hast du in der Zwischenzeit evtl. eine Lösung finden können? Ich habe hier mittlerweile schon 2 Firmen da gehabt, die bisher ebenfalls nicht weiter gekommen sind. Das ist eine ziemlich üble Angelegenheit.
Hallo Jogie,
nein. ich habe noch keine Lösung. Allerdings habe ich mich seit meinem letzten Post nicht um die Maschine kümmern können.
Ich kann erst Ende Januar an der Maschine weiterwerkeln.
Falls es was zu berichten gibt, schreib ich es sofort!
Wirklich eine üble Angelgenheit ...
nein. ich habe noch keine Lösung. Allerdings habe ich mich seit meinem letzten Post nicht um die Maschine kümmern können.
Ich kann erst Ende Januar an der Maschine weiterwerkeln.
Falls es was zu berichten gibt, schreib ich es sofort!
Wirklich eine üble Angelgenheit ...
Ich vermute aktuell das Problem in Verbindung mit Internetnutzung. Meiner Meinung nach tritt das Problem vorrangig auf, wenn bestimmte Internetseite aufgerufen werden, kann es aber noch nicht mit Sicherheit sagen. Wir nutzen aktuell den IE7 und stellen Internet via Terminalserver im Netz zur Verfügung. Ein Prozess des IE ist während der Vollauslastung immer oben mit dabei, daher meine Vermutung. Vom IE8 hat man mir bisher abgeraten, da könnte es wohl diverse Probleme in Verbindung mit Citrix 4.5 geben - so zumindest die Aussagen unserer Microsoft und Citrix Spezialisten. Einen anderen Browser können wir aktuell nicht einsetzten.
Grundsätzlich muss es aber irgendeine Applikation sein, die hier Störungen verursacht. Und da das Ganze so sporadisch auftritt (teilweise täglich bis zu 5 Mal, mache Tage nur 1 Mal) ist die Lösungsfindung schwer. Ich quäle mich da nun bereits seit 3 Wochen mit rum und kann aktuell nicht auf physische Hardware zurück.
Grundsätzlich muss es aber irgendeine Applikation sein, die hier Störungen verursacht. Und da das Ganze so sporadisch auftritt (teilweise täglich bis zu 5 Mal, mache Tage nur 1 Mal) ist die Lösungsfindung schwer. Ich quäle mich da nun bereits seit 3 Wochen mit rum und kann aktuell nicht auf physische Hardware zurück.
Gebt mal ein paar Infos ---
Was habt ihr probiert, was dabei rausgefunden, Steht irgendwas in den Event logs, .....
Sonst brauch ich wieder mal meine Glaskugel.
LG Florian.
Was habt ihr probiert, was dabei rausgefunden, Steht irgendwas in den Event logs, .....
Sonst brauch ich wieder mal meine Glaskugel.
LG Florian.
Die Eventlogs geben leider nichts her, da ist nichts auffälliges protokolliert. Die Probleme waren Anfangs noch etwas heftiger, da stand der Server permanent. Erst als ich allen Usern neue Netzwerkprofile verpasst habe, wurde es merklich besser. DNS und DHCP wurden kontrolliert und aufgeräumt, aber auch hier war nichts auffälliges gegeben, was hätte die Probleme verursachen können. Unser Domaincontroller ist ein Win2000 Server.
Seit gestern habe ich den Internetexplorer 7 an den Arbeitsplätzen weg genommen, welchen wir über den Terminalserver zur Verfügung stellen, und durch Firefox getauscht. Seitdem gab es bisher keinen hängenden Server mehr. Das kann natürlich nur Zufall sein, da ich das erst seit gestern Mittag schrittweise an den Clients umgestellt habe. Ich muss da erstmal die nächsten Tage abwarten.
Ansonsten hat unser Server alle notwendigen bzw. vorhanden Win-Updates, auch Citrix ist auf dem aktuellen Stand. Hast du weitere Fragen?
PS: Wenn die Systemauslastung auf 100% hochfährt und der Server somit fast zu Stillstand gekommen ist, ist kein Dienst auffällig CPU-lastig. Alles im Rahmen des normalen. Und das verstehe ich nicht. Virenschutz habe ich testweise deaktiviert, aber auch ohne diesen die selben Vorkommnisse.
Seit gestern habe ich den Internetexplorer 7 an den Arbeitsplätzen weg genommen, welchen wir über den Terminalserver zur Verfügung stellen, und durch Firefox getauscht. Seitdem gab es bisher keinen hängenden Server mehr. Das kann natürlich nur Zufall sein, da ich das erst seit gestern Mittag schrittweise an den Clients umgestellt habe. Ich muss da erstmal die nächsten Tage abwarten.
Ansonsten hat unser Server alle notwendigen bzw. vorhanden Win-Updates, auch Citrix ist auf dem aktuellen Stand. Hast du weitere Fragen?
PS: Wenn die Systemauslastung auf 100% hochfährt und der Server somit fast zu Stillstand gekommen ist, ist kein Dienst auffällig CPU-lastig. Alles im Rahmen des normalen. Und das verstehe ich nicht. Virenschutz habe ich testweise deaktiviert, aber auch ohne diesen die selben Vorkommnisse.
Ansonsten hat unser Server alle notwendigen bzw. vorhanden Win-Updates, auch Citrix ist auf dem aktuellen Stand. Hast du weitere
Fragen?
VMware-Tools sind installiert nehm ich an - somit bin ich immer noch bei der Glaskugel...Fragen?
Zeigt im SysInternals Process Explorer gar nichts was an? weder am Host noch in den Clients? Normalerweise geht zumindest - zB bei einem Hardwareproblem - die Zeile INTERRUPTS hoch.
Wir haben auf Hyper-V virtualisiert. VMware-Tools sind demnach nicht im Einsatz. (Ich hoffe, ich verstehe da nicht was falsch...)
Im SysInternals Process Explorer gehen bei der Vollauslastung des Systems die "Interrupts" voll hoch, pendeln zwischen 84 und 95% bei der CPU-Nutzung, danach folgt gleich "System", welches in der Windows-Prozessanzeige gleichzeitig auf 40% CPU-Nutzung hochfährt, sonst dort aber kaum auftaucht, wenn der Server "normal" läuft.
Wir haben die Tage den RAM der virtuellen Maschine von 4100 MB auf 3584 MB runter gesetzt. Heute hatte ich dann 4 Mal diese Systemvollauslastung, die sich jedoch nach kurzer Zeit (ca. 30 - 60 Sekunden) wieder von selbst erledigt hatte. Bisher musste ich den virtuellen Server wie bereits gesagt immer manuell stoppen und wieder "fortsetzten".
Im SysInternals Process Explorer gehen bei der Vollauslastung des Systems die "Interrupts" voll hoch, pendeln zwischen 84 und 95% bei der CPU-Nutzung, danach folgt gleich "System", welches in der Windows-Prozessanzeige gleichzeitig auf 40% CPU-Nutzung hochfährt, sonst dort aber kaum auftaucht, wenn der Server "normal" läuft.
Wir haben die Tage den RAM der virtuellen Maschine von 4100 MB auf 3584 MB runter gesetzt. Heute hatte ich dann 4 Mal diese Systemvollauslastung, die sich jedoch nach kurzer Zeit (ca. 30 - 60 Sekunden) wieder von selbst erledigt hatte. Bisher musste ich den virtuellen Server wie bereits gesagt immer manuell stoppen und wieder "fortsetzten".
Im SysInternals Process Explorer gehen bei der Vollauslastung des Systems die "Interrupts" voll hoch, pendeln zwischen
84 und 95% bei der CPU-Nutzung, danach folgt gleich "System", welches in der Windows-Prozessanzeige gleichzeitig auf 40%
CPU-Nutzung hochfährt, sonst dort aber kaum auftaucht, wenn der Server "normal" läuft.
Ok, das ist doch mal was.84 und 95% bei der CPU-Nutzung, danach folgt gleich "System", welches in der Windows-Prozessanzeige gleichzeitig auf 40%
CPU-Nutzung hochfährt, sonst dort aber kaum auftaucht, wenn der Server "normal" läuft.
Dann sollte es entweder ein Treiberproblem oder defekte oder fehlerhafte Hardware (auch virtuelle) sein. Dazu hilft dir die Google-Suche dann auch weiter.
Ich hatte damit noch nicht oft zu tun, nach ner kurzen Recherche würde ich es mal mit
http://www.thesycon.de/deu/latency_check.shtml
versuchen - bzw. einfach mal alle Treiber updaten und einzeln die Geräte die nicht unbedingt notwendig sind (virtuelle CD-ROM-Treiber zB) zu deaktivieren.
Viel Glück,
LG Florian
Hallo…
Wir haben den Grund für das Problem endlich gefunden. Nach dem Einspielen von Hotfix http://support.microsoft.com/kb/975530 lief der Terminalserver endlich „rund“.
Da der TS die einzige virtuelle Maschine war, die mehr als einen Prozessor-Core zugewiesen bekam, trat das Problem auch nur dort auf.
Trotzdem danke noch mal für deine Hilfe.
Gruß
Wir haben den Grund für das Problem endlich gefunden. Nach dem Einspielen von Hotfix http://support.microsoft.com/kb/975530 lief der Terminalserver endlich „rund“.
Da der TS die einzige virtuelle Maschine war, die mehr als einen Prozessor-Core zugewiesen bekam, trat das Problem auch nur dort auf.
Trotzdem danke noch mal für deine Hilfe.
Gruß
Hallo Jogie,
freut mich, dass das Problem bei Dir gelöst ist. Oder kam noch mal ein Hänger?
Ich bin jetzt endlich auch wieder an meiner Problemmaschine dran. Sie läuft jetzt isoliert in einer Testumgebung, bis der Fehler gefunden ist.
Ich habe mir das KB975530 aus Deinem letzten Post angeschaut. Ich hatte es auch während der Probleme in der Prosuktivphase installiert, hat aber nichts gebracht.
Was ich übrigens nicht ganz verstehe:
Ich habe im KB975530 keinen Hinweis darauf gefunden, dass das Problem mit der Anzahl der Cores zu tun hat, die man der VM zuweist.
Hattest Du eigentlich während Deiner Versuche eine Möglichkeit gefunden, diese Hänger verlässlich zu reproduzieren?
Danach suche ich gerade, um besser Testen zu können.
Gruß,
Thomas
freut mich, dass das Problem bei Dir gelöst ist. Oder kam noch mal ein Hänger?
Ich bin jetzt endlich auch wieder an meiner Problemmaschine dran. Sie läuft jetzt isoliert in einer Testumgebung, bis der Fehler gefunden ist.
Ich habe mir das KB975530 aus Deinem letzten Post angeschaut. Ich hatte es auch während der Probleme in der Prosuktivphase installiert, hat aber nichts gebracht.
Was ich übrigens nicht ganz verstehe:
Zitat von @-Jogie-:
...
Da der TS die einzige virtuelle Maschine war, die mehr als einen Prozessor-Core zugewiesen bekam, trat das Problem auch nur dort
auf.
...
Da der TS die einzige virtuelle Maschine war, die mehr als einen Prozessor-Core zugewiesen bekam, trat das Problem auch nur dort
auf.
Ich habe im KB975530 keinen Hinweis darauf gefunden, dass das Problem mit der Anzahl der Cores zu tun hat, die man der VM zuweist.
Hattest Du eigentlich während Deiner Versuche eine Möglichkeit gefunden, diese Hänger verlässlich zu reproduzieren?
Danach suche ich gerade, um besser Testen zu können.
Gruß,
Thomas
