JVM: Speicher wieder für OS freigeben?

[Lyxic]

Hallo,

ich hoffe mal, das ich hier im richtigen Unterforum gelandet bin

Ich beschreibe mal mein Problem:

Wir haben hier eine gewachsene Java Applikation mit der mitlerweile ca. 100 User arbeiten. Ursprünglich war die Applikation für 30 User geplant. Wohl auch aus diesem Grund wurde während der Planung kein Applikation Server für die Software vorgesehen, sondern eine Architektur gewählt, bei der sich die Clients auf einem zentralen Linux Server anmelden und jeweils eine eigene JVM starten in der die Applikation läuft.
Unser konkretes Problem ist jetzt der RAM Verbrauch. Das RAM ist voll ausgelastet und weil auch das nicht reicht, swappt der Server munter darauf los. (4-6GB im Schnitt)
Da die Clients ab und an sehr große Datenmengen aus einer DB abfragen, ist als maximale Heap Größe 512MB gesetzt. Der Server selbst besitzt 8GB Ram(mehr geht auf der Hardware nicht und neue Hardware scheidet vorerst aus).
Das Design der Applikation ist sicherlich nicht optimal, aber daran werde ich nichts ändern können. Mich beschäftigt im Moment vielmehr die Frage, wie ich den RAM Verbrauch minimieren kann. Die JVM scheint den einmal allokierten Speicher nicht wieder für das OS freizugeben. Gibt es Möglichkeiten dies zu ändern?

Ich kann zwar an diversen Parameter des GC drehen, doch wenn der so "intern" (also in der JVM) freie Speicher nicht wieder von der JVM an das OS freigegeben wird, dann würde das ja vermutlich eh nichts bringen ...
Denn dann fehlt dieser Speicher weiterhin für andere Clients...

Gruß Lyxic

 

[maki]

MIr fällt keine Lösung ausser einem redesign ein, aber aus Neugier, wie sehen denn deine XMS und XMX Parameter aus?

 

[tfa]

Mehr Server kaufen.

 

[tuxedo]

sondern eine Architektur gewählt, bei der sich die Clients auf einem zentralen Linux Server anmelden und jeweils eine eigene JVM starten in der die Applikation läuft.

Wie sieht das denn aus? Loggen die sich via VNC/RDP am Linux-Rechner ein?
Wenn ja: Ich will ja nicht stänkern, aber das Design wäre ja schon bei nur 5 Usern "schlecht".

Warum können die User das Programm nicht bei sich lokal starten und über's Netzwerk verbindung zur DB aufnehmen? Oder hängen da noch andere Ressourcen dran?

 

[Lyxic]

Also,

@maki:

xms steht auf 64 und xmx auf 512 MB. Was das redesign angeht - ich bin in der Vergangenheit schon fast gekreuzigt worden als ich das angesprochen habe

Weniger geht leider nicht, da es halt vor kommen kann, dass sich User immense Datenmengen aus der DB saugen und sonst laufen wir halt in eine OutOfMemory...


@tfa:

Steht im Moment nicht zur Diskussion...


@alex0801:

Die Clients loggen sich via SSH auf dem Server ein. (auch aus weit entfernten Aussenstellen mit wenig Bandbreite.) Da die GUI Curses nutzt gibt es da auch keine Probleme - im Gegenteil.

Dass das Design fragwürdig ist, will ich garnicht leugnen. Das ist allerdings nicht auf meinen Mist gewachsen. Ich administriere nur die Server, ich bin kein Entwickler

Das Programm lokal zu starten ist aufgrund der Bandbreite nicht möglich. Viele (die meisten) Benutzer sind nur über schmalbandige Leitungen mit dem Server verbunden. Abfragen die mehrere Millionen Rows in der Datenbank anfassen und dann immer noch einige tausend zurückliefern kann man nicht vernüftig über 128k Leitungen übertragen wenn gleichzeitig mehrer Leute über solch eine Leitung arbeiten sollen.

Gruß Lyxic

 

[tuxedo]

Hmm, afaik hält die JVM den einmal reservierten Speicher fest und gibt ihn (nicht so schnell) wieder her. Ich bin mir recht sicher dass es da keinen vernünftigen Weg gibt den Speicher wieder herzugeben, bzw. damit dynamischer zu verfahren. Da die "Gui" ja recht einfach zu sein schein, wäre es sicher machbar die Anwendung auf "verteilt" umzustricken, so dass nur noch eine VM läuft. Nebenbei sollte man nicht unterschätzen was eine vernünftige komprimierung anstellen kann. Mein jPMdbc Treiber schafft bei der Übertragung rund Faktor 10 bei der Komprimierung (https://jpmdbc.dev.java.net/). Aber 128k sind dennoch etwas wenig wenn mehrere dran hocken.

Zum Thema steinigen: Dich sollte man nicht steinigen. Du kannst ja nix dazu. Aber der, der das verbrochen hat, und auch noch Geld dafür bekommen hat, den sollte man weiß weg, auf eine einsame, verregnete und düstere Insel schicken, wo es kein Internet und keine Rechner gibt. Soweit weg, dass er sowas nicht nochmal verbrechen kann.

Man, wenn ich nur dran denke... 30 mal (soviel war ja geplant) die JVM öffnen... Was das für einen "Overhead" erzeugt...