TM mit Java als Speicherfresser

[turbotm]

Hallo an die Techniker in diesem Forum.
TM wird zunehmend speicherhungriger, alleine diese blöde Java-Komponente beansprucht zusehend Resourcen.
Habe meinen RDP-Server gerade erst auf 32GB aufgestockt, was leider das Ende der Fahnenstange ist, und bin schon wieder am Anschlag.
Bei so hoher Speicherauslastung kommt es dann immer wieder zu kurzen Einfrieren der Thin-Clients.
Bei mir arbeitet noch ein HP ProLian mit Xeon CPU E3-1220 v3 @ 3.10GHz.
25 Benutzer, Win Server 2016
Hat jemand einen guten Rat?
Ich wäre dankbar.
Gruß
Maier

[Timebomb]

Moin,
das Problem wird sich nicht ohne neues Blech beheben lassen.

Der 1220V3 ist ein Quadcore ohne HT, also reden wir hier über 4 Threads mit max. 3,5GHz für den Server selbst und 25 Instanzen. Da darf man schon mal nicht das performanteste Ergebnis erwarten. Das ist einfach zu viel. Ideal könnten man hier rechnen 4-6 Sitzungen pro Kern oder 0,5-1GHz pro User (kommt in dem Falle sogar genau hin...) Natürlich braucht der Server selbst auch etwas Futter - hier würde ich sogar einen Kern abziehen. Also 3 * 6 = 18 Sitzungen. Würde bedeuten hier ist ein Flaschenhals.

Dann kommen wir zum Speicher. Ich habe gerade mal gemessen, Turbomed, Ifap und Java kommen auf 461MB (Demodatenbank, Leerlauf). Word braucht gut 100MB. Hinzu kommt die Sitzung selbst. Ich würde pro Benutzer mindetens 2, besser 3GB planen. Hinzu kommt etwas für den Server - auch 2G. Dann kommen wir grob auf 50-75G. Und da ist der zweite Flaschenhals. Ist zu wenig Speicher da wird ausgelagert...

Diese Werte sind keinesfalls brandaktuell und auch nicht als "muss" zu verstehen. Es funktioniert ja ganz offensichtlich auch mit weniger - nur dann halt, wie sie selbst schreiben, zeitweise stockend.

[turbotm]

Super, danke. Damit kann ich arbeiten und werde mich umgucken.
Ich hoffe nur, mein Berater kann mir dann das System auf eine neue Maschine migrieren.....
Beste Grüße

[Timebomb]

Das ist im Grunde kein Hexenwerk. Terminallösungen fordern aber immer etwas mehr Weitsicht als Client-Server-Lösungen. Also keine Punktlandung versuchen und lieber etwas Luft nach oben lassen. Ein aktueller Server kann ja erstmal laufen - der Server 2019 hat sein extended end of life 2029...

[nmndoc]

Ideal könnten man hier rechnen 4-6 Sitzungen pro Kern oder 0,5-1GHz pro User (kommt in dem Falle sogar genau hin...) Natürlich braucht der Server selbst auch etwas Futter - hier würde ich sogar einen Kern abziehen. Also 3 * 6 = 18 Sitzungen. Würde bedeuten hier ist ein Flaschenhals.

Dann kommen wir zum Speicher. Ich habe gerade mal gemessen, Turbomed, Ifap und Java kommen auf 461MB (Demodatenbank, Leerlauf). Word braucht gut 100MB. Hinzu kommt die Sitzung selbst. Ich würde pro Benutzer mindetens 2, besser 3GB planen. Hinzu kommt etwas für den Server - auch 2G. Dann kommen wir grob auf 50-75G. Und da ist der zweite Flaschenhals..

Danke für die Anregungen. Wir haben zwar nicht aktuell das Problem, aber schon mit dem Gedanken auf TS zu wechseln gespielt. Ich ging bisher aber von anderen Daten aus:

1 vCore je aktivem User/Sitzung (bei mehreren Standorten/Sprechzimmern etc sind ja normal nicht immer alle wirklich aktiv)
1GB je User/Sitzung ggf etwas nach oben Puffer.
Für den Sever selbst hätte ich eher 2-4 vCores reserviert. (und falls virtualisiert sollte man dem OS ja noch 5-8 GB reservieren)

Finde ich also eine ganz gute Anregung - ich nehme an die kommt aus der Praxis - während meine eher auf dem Papier und "Abschätzung" entstanden ist.

Da die HW allerdings für ca 80 Clients - davon denke ich mal ~35-60% gleichzeitig aktiv - gepkant ist - wäre diese dann schon so dimensioniert, dass man ggf. noch etwas RAM reinstecken kann