Java - hoher Ramverbraucht auf WTS Server

[java-user44]

Hallo,

Problem: http://cargosoft.dakosy.de/ShaireClient.jnlp wird auf einem WTS 2008 r2 64bit genutzt und ca. 10-20 Mann arbeiten auf dem Server

Im Taskmgr hat die Anwendung je User ca. 1,5 - 2 GB und der ganze RAM ist natürlich weg und der WTS ist langsam

Start/Systemsteuerung/Software sagt: Java 8 Update 131 , 131 (64bit) und 151 (64bit) sind installiert

Wenn ich o.g. Link starte öffnet das JAVA Logo mit (x64)
Ich habe keine Ahnung wie ich explizit 32bit starten, ausser ich deinstalliere 64bit? (oder deaktiviere 64bit in den Java Settings?)

Aktionsplan im Entwurf:

-Java updaten für 32bit und 64bit
Weiter bin ich überfragt, die Dakosy Hotline kannte spontan kein JAVA weg um 32bit explizit zu nutznen. Möglicherweise muss ich die den Link auch mit 32bit Browser öffnen?

Das das Dakosy Tool soviel Speicher frisst war nicht schon immer.
Java Cache löschen war noch nicht dran.



++++

Java Cache löschen
Falls die Anwendung bereits erfolgreich gestartet werden konnte, nun aber nicht mehr startet, dann löschen sie
CargoSoft GE bitte wie folgt:
Gehen Sie zu Start > Einstellungen > Systemsteuerung und klicken sie dort auf Java.
Das Java-Bedienungsfeld wird gestartet.
Klicken Sie auf die Registerkarte Allgemein.
Klicken Sie im Abschnitt "Temporäre Internetdateien" auf die "Ansicht...".
Wählen Sie in der Auswahlbox "Anzeigen" den Punkt "Anwendungen" aus.
Markieren Sie in der Liste die alle Einträge mit dem Namen "DAKOSY GE ...".
Klicken sie auf das Symbol mit dem X (Ausgewählte Elemente entfernen)
Nun können Sie die Anwendung wieder auf der Webseite https://cargosoft.dakosy.de/ bzw. Dakosy Direct starten

 

[mihe7]

Ich würde mal in der JNLP-Datei das Attribut max-heap-size von 2g auf 1g runtersetzen.

 

[kneitzel]

Also ich kenne diese software nicht aber:
Speicherverbrauch: In der JNLP Datei gibt er vor, mit wieviel Speicher die VM Starten soll (256MB) und was er maximal nutzen darf (2GB). Das kannst Du natürlich begrenzen, aber die Frage ist, was das für Auswirkungen hat. Evtl. läuft die Applikation dann nicht mehr.

Wenn es unter 32 Bit besser laufen sollte (wieso das so sein sollte, erschließt sich mir nicht wirklich), dann kannst Du tatsächlich über den 32Bit Browser (Gibt es IMHO in späteren/aktuellen Windows Server Version aber nicht mehr, oder?) gehen. Oder Du nutzt direkt javaws um die Applikation zu starten.

Viele Grüße,

Konrad

 

[mihe7]

Wenn es unter 32 Bit besser laufen sollte (wieso das so sein sollte, erschließt sich mir nicht wirklich)

Mir auch nicht, vielleicht weiß @httpdigest mehr dazu. Ich wäre, ohne nachzusehen, davon ausgegangen, dass es unter 64-Bit-Java nicht zu eklatant höherem Speicherverbrauch ggü. 32-Bit-Java kommt, da Adressen/longs schon immer 64 Bit lang waren.

 

[mrBrown]

Mir auch nicht, vielleicht weiß @httpdigest mehr dazu. Ich wäre, ohne nachzusehen, davon ausgegangen, dass es unter 64-Bit-Java nicht zu eklatant höherem Speicherverbrauch ggü. 32-Bit-Java kommt, da Adressen/longs schon immer 64 Bit lang waren.

Adressen unter 32-bit Java waren doch 32 Bit, und nicht 64 Bit?
Wobei Adressen im Java-Heap unter 64-Bit mit Compressed Oops auch nur 32-bit groß sein können...

 

[mihe7]

Adressen unter 32-bit Java waren doch 32 Bit, und nicht 64 Bit?

Oha, verwechselt mit dem 8-Byte-Header. Asche auf mein Haupt.

 

[httpdigest]

Auszug aus der JNLP:

<resources arch="amd64">
  <java version="1.8*" ... initial-heap-size="256m" max-heap-size="2g" ...

Eine Java Anwendung, der man erlaubt, bis zu 2 Gigabyte zu verwenden, wird irgendwann 2 Gigabyte verwenden, bis der Garbage Collector meint, das vielleicht wieder auf wenige Megabytes zu reduziert. Wahrscheinlich alloziert die Anwendung häufig sehr viele oder sehr große Objekte, die erst später wieder weggeräumt werden, weil Java ja gesagt wurde: "Alles bis 2 Gigabytes ist kein Problem. Gönn' dir die ruhig, bis du glaubst, den Speicher wieder freigeben zu wollen."
Java nimmt hier keine Rücksicht auf eventuell andere laufende Programme im System. Und virtueller, nicht-committeter Arbeitsspeicher kann immer reserviert werden, solange die anderen Anwendungen den nicht tatsächlich beschrieben haben.

Die Lösung ist meiner Meinung nach, die JNLP Datei anzupassen und auszuprobieren, ob ein niedrigeres max-heap-size ausreicht. Ich vermute mal, dass aktuell die Anwendung nicht komplett mit einem OutOfMemoryError wegkracht.

 

[mrBrown]

Oha, verwechselt mit dem 8-Byte-Header.

Wobei der Header unter 64-Bit entweder 12 oder 16 Bit haben können müsste, je nachdem ob Compressed Oops oder nicht (@httpdigest, berichtige das mal bitte )

 

[mihe7]

Ich sollte mir das Zeug mal wieder durchlesen... Auf jeden Fall schon mal Danke für die Korrektur, ich will hier ja keinen Unsinn verbreiten.