Dedizierte Java Installation, Optimierung des Server RAM-Verbrauchs

Frederik Hantke

Moin!

Da wir noch immer das Problem haben, dass die Clients bei intensiver Nutzung nach wenigen Stunden vollaufen, kommt natürlich auch die Frage auf, ob man auch am Server irgendwo Kapazitäten freigeben kann.

Ich bin nun über einen alten Forumsbeitrag (klick) gestolpert, bei dem gesagt wurde, dass gar kein JAVA mehr benötigt wird zur Ausführung der Servertools.

Meine Frage daher: ist das noch aktuell? Gibt es gewisse Zollsoft-Tools (ich sehe auf dem Server z.B. einen "Mirt Connect Administratior Launcher", der eine schon sehr old schoolige JAVA Oberfläche zeigt), die eine dedizierte JAVA Installation benötigen? Die derzeitig stets laufenden JAVA Instanzen fressen zusammen über 11.5 GB virtuellen Speicher und rund 2 GB physikalischen Speicher. Daher ist der M1 Mac Mini Server mit seinen 16 GB RAM bereits bei rund 2 GB Swap, was dann ja in Teilen vermeidbar wäre...

Frederik Hantke

Ich habe mir die JAVA Prozesse mal genauer angeschaut und es werden auf dem Server insgesamt 3 verschiedene java Instanzen geladen:

1. java mit rund 8.75 GB, das v.a. die ganzen JARs aus der Server-App geladen hat

2. java mit rund 2.2 GB, das alleine für die Mirth-Connect Anbindung verwendet wird

3. java mit rund 580 MB, das nochmals alle (?) JARs aus der Tomedo-Server App geladen hat, die bereits im 1. java geladen wurden...

Vielleicht könnte man sich von der Entwicklung ggf. angucken, ob die JARs wirklich alle doppelt in einer weiterern Java Instanz geladen werden müssen. Ich könnte mir da den einen oder anderen Konflikt bei der Prozessverantwortung im System vorstellen ;-)

PS: Bei diesem Test war ausser den Servertools kein weiterer Tomedo-Client am Server gestartet.

Frederik Hantke

Auffallend: bei diversen JARs werden auch die Android, Linux und Windows-Versionen geladen (die vermutlich sehr unterbeschäftigt im RAM rumhängen):

ffmpeg (insgesamt 49.4 MB) zusätzlich mit Linux- und Windows-Versionen:

ffmpeg-4.1-1.4.4-linux-x86_64.jar
ffmpeg-4.1-1.4.4-linux-x86_64.jar
ffmpeg-4.1-1.4.4-windows-x86_64.jar
ffmpeg-4.1-1.4.4.jar

javacpp (insgesamt 2.3 MB) zusätzlich mit Android-, Linux- und Windows-Versionen:

javacpp-1.5.10-android-arm64.jar
javacpp-1.5.10-android-x86_64.jar
javacpp-1.5.10-ios-arm64.jar
javacpp-1.5.10-ios-x86_64.jar
javacpp-1.5.10-linux-arm64.jar
javacpp-1.5.10-linux-ppc64le.jar
javacpp-1.5.10-linux-x86_64.jar
javacpp-1.5.10-macosx-arm64.jar
javacpp-1.5.10-macosx-x86_64.jar
javacpp-1.5.10-windows-x86_64.jar
javacpp-1.5.10.jar

jcip sowohl 1.0, wie auch 1.0.1 parallel:

jcip-annotations-1.0-1.jar
jcip-annotations-1.0.jar

leptonica (insgesamt 31.9 MB) zusätzlich mit Android-, Linux- und Windows-Versionen:

leptonica-1.84.1-1.5.10-android-arm64.jar
leptonica-1.84.1-1.5.10-android-x86_64.jar
leptonica-1.84.1-1.5.10-linux-arm64.jar
leptonica-1.84.1-1.5.10-linux-ppc64le.jar
leptonica-1.84.1-1.5.10-linux-x86_64.jar
leptonica-1.84.1-1.5.10-macosx-arm64.jar
leptonica-1.84.1-1.5.10-macosx-x86_64.jar
leptonica-1.84.1-1.5.10-windows-x86_64.jar
leptonica-1.84.1-1.5.10.jar

Openblas (insgesamt 124 MB) zusätzlich mit Android-, Linux- und Windows-Versionen:

openblas-0.3.26-1.5.10-android-arm64.jar
openblas-0.3.26-1.5.10-android-x86_64.jar
openblas-0.3.26-1.5.10-ios-arm64.jar
openblas-0.3.26-1.5.10-ios-x86_64.jar
openblas-0.3.26-1.5.10-linux-arm64.jar
openblas-0.3.26-1.5.10-linux-ppc64le.jar
openblas-0.3.26-1.5.10-linux-x86_64.jar
openblas-0.3.26-1.5.10-macosx-arm64.jar
openblas-0.3.26-1.5.10-macosx-x86_64.jar
openblas-0.3.26-1.5.10-windows-x86_64.jar
openblas-0.3.26-1.5.10.jar

Opencv (ingesamt 336.5 MB) parallel 4.0.1.-1.4.4 und 4.9.0-1.5.10 zusätzlich mit Android-, Linux- und Windows-Versionen:

opencv-4.0.1-1.4.4-linux-x86_64.jar
opencv-4.0.1-1.4.4-macosx-x86_64.jar
opencv-4.0.1-1.4.4-windows-x86_64.jar
opencv-4.0.1-1.4.4.jar
opencv-4.9.0-1.5.10-android-arm64.jar
opencv-4.9.0-1.5.10-android-x86_64.jar
opencv-4.9.0-1.5.10-ios-arm64.jar
opencv-4.9.0-1.5.10-ios-x86_64.jar
opencv-4.9.0-1.5.10-linux-arm64.jar
opencv-4.9.0-1.5.10-linux-ppc64le.jar
opencv-4.9.0-1.5.10-linux-x86_64.jar
opencv-4.9.0-1.5.10-macosx-arm64.jar
opencv-4.9.0-1.5.10-macosx-x86_64.jar
opencv-4.9.0-1.5.10-windows-x86_64.jar
opencv-4.9.0-1.5.10.jar

Tesseract (insgesamt 14 MB) parallel 4.0.0-1.4.4 und 5.3.4-1.5.10 zusätzlich mit Android-, Linux- und Windows-Versionen:

tesseract-4.0.0-1.4.4.jar
tesseract-5.3.4-1.5.10-android-arm64.jar
tesseract-5.3.4-1.5.10-android-x86_64.jar
tesseract-5.3.4-1.5.10-linux-arm64.jar
tesseract-5.3.4-1.5.10-linux-ppc64le.jar
tesseract-5.3.4-1.5.10-linux-x86_64.jar
tesseract-5.3.4-1.5.10-macosx-arm64.jar
tesseract-5.3.4-1.5.10-macosx-x86_64.jar
tesseract-5.3.4-1.5.10-windows-x86_64.jar
tesseract-5.3.4-1.5.10.jar

Fazit: wenn man die ganzen oben genannten Android, Windows und Linux Versionen weglassen könnte, so hätte man ohne grosse Arbeit rund 720 MB (da ja die o.g. JARs 2x mit je rund 360 MB geladen werden) mehr Platz im RAM zur Verfügung...

Bei den aktuellen RAM-Preisen ist das ja fast schon ein verlängertes Wochenende an der Müritz 😉

Dirk Küpper

Die Frage hat mich neugierig gemacht. Habe daher mal nachgeschaut. Auf meinen Server Installationen für Tomedo konnte ich im Leerlauf auf dem Server selber nur 3 Prozesse entdecken die Java benötigen. Im Verzeichnis /Library/Java/ liegen keine Installationen. Ich schaue mir das bei nächster Möglichkeit noch mal an, wenn auf den Arbeitsplätzen zusätzlich gearbeitet wird.

Ravil Rubashkin

Bin sehr interresiert. Lese mit.

Frederik Hantke

Ja, genau diese 3 Java Instanzen meinte ich.

und wenn man dann z.B. den ersten über das Ausrufezeichen oben genauer analysieren lässt, dann sieht man alle davon geöffneten Dateien und Ports:

Und man sieht dann, dass in der ersten und dritten (die grösste und kleinste) Instanz jeweils die selben Module geladen sind.

Um sich dann die JARs anzeigen zu lassen, die geladen werden, so findet man diese nicht im Library/Java, sondern in der TomedoServer App. Den Inhalt kann man per rechte Maustaste "Paketinhalt öffnen" anzeigen und darin dann auf Contents/tomedo-server/lib navigieren, um die Java Pakete zu sehen.

Dirk Küpper

Auf einem M2Pro mit 32 GB RAM auch im laufenden Betrieb keine Merkwürdigkeiten festzustellen:

Andreas Cepin

Auch auf einem nicht mehr ganz frischen Intel Mac Mini habe ich keine Probleme. Allerdings hatte ich damals satt RAM reingepackt. Vielleicht liegt es doch an der RAM-Ausstattung des Servers.

Dirk Küpper

Bitte keine Seriennummern von Geräten veröffentlichen. Es gibt leider Menschen die mit so was groben Unfug machen. Ansonsten gilt eigentlich wie eh und je. RAM kann man nur mit mehr RAM ersetzen. Bei den M-Prozessoren noch gemeiner, da man das Gerät direkt mit maximalem möglichen RAM kaufen muss, da es nicht mehr nachträglich erweiterbar ist. Auch bei der SSD sollte mindestens 1 TB vohanden sein, da macOS sich alles schnappt was es kriegen kann. Wenn man am RAM und SSD spart, kauft man 2 mal!