Terminalserver

[Guybrush Threepwood]

Hi,
ein Kunde verwendet eine Client-Server-Lösung von mir und hat Client und Server auf einem Windows 2003R2 Terminalserver installiert. Auf den Thin-Clients wird das Client-Programm gestartet. Das funktioniert, solange nur ein Client gestartet wird. Bei mehreren gestarteten Clients steigt die CPU-Last auf 99% und die Clients sind sehr träge. Bei "normalen" Netzwerk-Rechnern funktioniert das Programm im Mehrnutzerbetrieb dagegen problemlos.
Ich habe leider überhaupt keine Erfahrung mit Thin-Clients und selbst kein solches System zum Testen zu Verfügung. Hat jemand eine Idee, woran das liegen könnte? Oder kann mir jemand einen Tipp geben, welche Fragen ich dem Kunden stellen muss, um die Ursache des Problems herauszufinden? Zum Kunden besteht leider nur ein E-Mail-Kontakt und ich habe keine Möglichkeit, vor Ort konkret nachzusehen.

Viele Grüße,
Guybrush

 

[Spacerat]

Nadelöhr Netzwerk-Verbindung würd' ich sagen. Die Java-Client-Anwendung wird ja eigentlich auch auf dem Server ausgeführt. Das bedeutet, das die Daten nicht wie bei normalen Rechnern sozusagen von Prozessor zu Prozessor geschickt werden, sondern vom Prozessor des Servers über den Thin-Client zurück zum Prozessor des selben Servers. Prozessor nun aber nicht all zu wörtlich nehmen. Will damit nur sagen, dass alle Clients ein und den selben Prozessor belasten. Wie du das deinen Kunden beibringen kannst weiss ich allerdings nicht. Möglicherweise muss im Server ein Mechanismus implementiert werden, der feststellt, ob die Clienten auf einem Terminal-Server laufen, damit er lokal, statt über Netzwerk darauf zugreift.

 

[Guybrush Threepwood]

Hi,
danke für den Hinweis. Inzwischen hat der Kunde rückgemeldet, dass nach dem Start mehrerer Clients generell die GUI der Clients lahm ist, sodass also nicht nur bei Zugriffen auf das Server-Programm Engpässe vorhanden sind. Kann es sein, dass bei den Thin-Client-Prozessen (kann man das so sagen?) auf dem Server jeweils zu wenig physikalisches RAM zur Verfügung steht und die JVM zum Teil im Cache auf der Platte liegt? Das hatte ich schon mal vor Jahren auf extrem schwach bestückten Desktop-Rechnern. Die GUI wird dann unheimlich träge.

Ciao,
Guybrush

 

[maki]

Hab lange nicht mehr unter einem TerminalServer gearbeitet, war noch der NT 4 TSE.
Der Ram sollte eigentlich "geshared" werden wo möglich, trotzdem sollte man nicht allzuviel beanspruchen, aber das Problem kann auch ein anderes sein, der sog. "Thin Client", auch RDP und TS Client genannt, bekommt seinen "Bildschirm" vom Server, alles geht da durchs Netz, ändert sich häufig etwas an deiner GUI?

Solltest versuchen das Problem nachzustellen wenn du kannst (zB. irgendwo eine alte Lizenz für den TS Server auftreiben und dann virtualisieren) oder mehr Informationen zu bekommen, sonst stocherst du im Dunkeln.

 

[Guybrush Threepwood]

Ist es möglich, dass auf dem Terminalserver die verschiedenen Instanzen der Clients in der gleichen JVM ausgeführt werden und es so zu einem Engpass kommt?

 

[Spacerat]

Das lässt sich doch anhand der Prozesse im Programmanager feststellen. Möglich ist das natürlich.

 

[tuxedo]

Ist es möglich, dass auf dem Terminalserver die verschiedenen Instanzen der Clients in der gleichen JVM ausgeführt werden und es so zu einem Engpass kommt?

Wieso? Viel schlimmer fände ich es wenn jeder Client eine eigene JVM bräuchte und somit der Speicher mehrfach unnötig belastet wird. Denn die Clients werden im großen und ganzen wohl die gleichen Klassen benötigen. Wozu also alles mehrfach im Speicher halten?

 

[Guybrush Threepwood]

Nein, prinzipiell ist das Teilen einer JVM nicht schlimm sondern sogar wünschenswert. Aber: Ein Screenshot des TaskManagers des Kunden zeigt, dass das Client-Programm 31.992 KB reserviert hat. Mir scheint, hier ist irgendwie eine Deckelung bei 32 MB pro Prozess. Einfache Swing-Programme gehen sehr schnell mal über diesen Wert und bei meinem Client-Programm bei meinem Rechner ist man auch recht schnell zwischen 40 und 50 MB. Wenn der Speicher auf dem Terminalserver gedeckelt ist und verschiedene Instanzen sich diesen teilen, dann muss es also zwangsläufig zu einem Engpass kommen. Wenn die JVM zum Teil im Cache liegt, dann wird die Programmbedienung einfach sehr zäh.

 

[tuxedo]

Nein, prinzipiell ist das Teilen einer JVM nicht schlimm sondern sogar wünschenswert. Aber: Ein Screenshot des TaskManagers des Kunden zeigt, dass das Client-Programm 31.992 KB reserviert hat. Mir scheint, hier ist irgendwie eine Deckelung bei 32 MB pro Prozess.

We soll das gehen? Du kannst zwar den Heap etc. begrenzen, aber wenn die Anwendung doch mehr will, dan rauchts...

Einfache Swing-Programme gehen sehr schnell mal über diesen Wert und bei meinem Client-Programm bei meinem Rechner ist man auch recht schnell zwischen 40 und 50 MB.

Das ist auch meine Erfahrung. 40-50MB hat man da locker pro JVM im Speicher ...

Wenn der Speicher auf dem Terminalserver gedeckelt ist und verschiedene Instanzen sich diesen teilen, dann muss es also zwangsläufig zu einem Engpass kommen. Wenn die JVM zum Teil im Cache liegt, dann wird die Programmbedienung einfach sehr zäh.

Du meinst dass der TS den Speicher pro Prozess begrenzt? Wie soll das denn gehen? Wie wird mit Anwendungen verfahren die mehr brauchen? Die 32MB die du da im Taskmanager gesehen hast wird ja nicht der Speicher im RAM sein, sondern der Speicher den der Prozess bracht, unabhängig wieviel davon wirklich im RAM oder Swap (Auslagerungsdatei) liegt.

Aber ja: Wenn der RAM im TS sehr gering ist, dann wird schnell ausgelagert und dann wirds langsam. Sieht man auch daran dass er ständig auf der Platte rumlädt ohne groß CPU zu brauchen. Aber das steht noch im widerspruch zu den max. 32MB RAM ...?!

- Alex

 

[Guybrush Threepwood]

Mein Post war vermutlich Quatisch. Offen gesagt habe ich keine Ahnung von Terminalservern und versuche, es mir irgendwie zusammenzureimen. Außerdem traue ich Microsoft alles zu.

Inzwischen gibt es einen Workaround: Wenn man verschiedene Kopien des Client-Programms ablegt und jede Kopie nur einmal startet, dann läuft es wunderbar. Seltsam ist nur, dass der Client selbst keine Daten ablegt und es folglich auch nicht an der gegenseitigen Blockade irgendwelcher Logging-Datei liegen kann.

 

[tuxedo]

Hmm, ist schon irgendwie mysteriös ...

- Alex

 

[maki]

Wenn ihc mich recht erinnere, dann teilen unter dem TSE die Programme die aus der selben executable gestartet wurden so einiges an ressourcen.