Java als Service

[NicoDeluxe]

Moin zusammen, sobald ich auf meinem Server zb Payara Micro starte, kackt der gesamte Server ab und reagiert nicht mehr. Das passiert grundsätzlich, wenn ich auch nur den kleinsten Java Service starten will… folgendes sagt htop. Gestartet wird wie folgt:

java -jar /var/frontend/payara-micro-5.181.jar -Xmx32m -Xss256k --deploy /var/frontend/ROOT.war --logToFile /var/frontend/PayaraMicro.log

Hat jemand ne Idee, was da los ist?

[mrBrown]

Startest du den bewusst 35 mal?

[NicoDeluxe]

nein, nur so wie im Eingangspost beschrieben mit dem Aufruf

[ionutbaiu]

Mach nochmal Htop aber vorher mit F5 das ganze als Tree anzeigen. Sieht man besser ob da nun wie mrBrown meint 35 Instanzen gestartet werden oder ob das nur Threads sind. Nur um sicher zu gehen.

[maki]

@ionutbaiu

Sieht man besser ob da nun wie mrBrown meint 35 Instanzen gestartet werden oder ob das nur Threads sind.

AFAIK (?) haben threads dieselbe PID, kann mich irren.

ps aux hilft da auch, muss nicht htop sein ausser man mag Farben und will nicht mit grep filtern.

[ionutbaiu]

Nope, hab es gerade mal ausprobiert.

Damit es ein Java-Programm ist mal JDownloader gestartet und das ganze mit htop betrachtet.

Da laufen dann 20 Threads/Prozesse, jeder mit eigener PID, lediglich die PPID verweist auf den Parent und ist immer gleich. Die einzigen Unterschiede zeigen sich bei CPU und Rechenzeit jeweils.
Sieht man auch deutlich wenn man sich das als Tree anzeigen lässt, dass dies alles zusammen gehört.

Schätze mal, dass dies bei einem Payara ein ähnliches Bild ergeben wird. Vermutlich also doch nur eine Instanz gestartet.

[mrBrown]

@ionutbaiu

Damit es ein Java-Programm ist mal JDownloader gestartet und das ganze mit htop betrachtet.

Da laufen dann 20 Threads/Prozesse, jeder mit eigener PID, lediglich die PPID verweist auf den Parent und ist immer gleich. Die einzigen Unterschiede zeigen sich bei CPU und Rechenzeit jeweils.
Sieht man auch deutlich wenn man sich das als Tree anzeigen lässt, dass dies alles zusammen gehört.

Zumindest unter macOS taucht JDownloader in htop genau einmal mit nur einer PID auf, auch in der Tree-Ansicht.

@ionutbaiu

Schätze mal, dass dies bei einem Payara ein ähnliches Bild ergeben wird. Vermutlich also doch nur eine Instanz gestartet.

Gleiches gilt bei mir für Payara.

Edit: scheint ein Bug unter macOS zu sein, da zeigt er keine einzelnen Threads mit htop

[ionutbaiu]

Bei htop kann man im Setup unter Display Options den Punkt Hide Userland process threads de-/aktivieren.

Je nach Einstellung hat man dann eben eine Liste von Prozessen oder eben nur sehr wenige, bzw. einen.

Bei mir war die Option deaktiviert. Und bei NicoDeluxe wird es vermute ich mal ebenso sein. Denke auch nicht, dass dies ein macOS Bug ist, sondern nur eine andere Einstellung. Kannste mal ausprobieren.

---

Ich hab irgendwie Zweifel, auch wenn es ein Payara Micro ist, dass dieser mit 32MB Heap auskommt. Wenn da wirklich was drauf deployed wird wird das wohl mehr sein.

Hat dein User, mit dem du startest auch die nötigen Rechte? /var/frontend lesen und schreiben, Ports öffnen usw.

[maki]

@ionutbaiu

Ich hab irgendwie Zweifel, auch wenn es ein Payara Micro ist, dass dieser mit 32MB Heap auskommt. Wenn da wirklich was drauf deployed wird wird das wohl mehr sein.

32MiB sollten den GC ziemlich beschaeftigt halten.

Was steht denn im Log @NicoDeluxe?

[mrBrown]

@ionutbaiu

Bei htop kann man im Setup unter Display Options den Punkt Hide Userland process threads de-/aktivieren.

Je nach Einstellung hat man dann eben eine Liste von Prozessen oder eben nur sehr wenige, bzw. einen.

Bei mir war die Option deaktiviert. Und bei NicoDeluxe wird es vermute ich mal ebenso sein. Denke auch nicht, dass dies ein macOS Bug ist, sondern nur eine andere Einstellung. Kannste mal ausprobieren.

Ne, ist wirklich nicht unterstützt under macOS:no threads shown in OSX · Issue #552 · hishamhm/htop · GitHub

[NicoDeluxe]

Danke für eure Antworten, also ich komm gar nicht so weit, dass ich nochmal htop als tree ansehen könnte, nach dem starten kommt folgender Fehler im Log:
Cannot find javadb client jar file, derby jdbc driver will not be available by default.

und der Server reagiert nicht mehr, startet dann irgendwann von selber neu

[ionutbaiu]

Hab mir mal zum Spaß den payara Micro 5.182 geholt und darauf mal ein einfaches war deployed. Ziemlich minimalistisch.

AdamBien/ping

Da mal diverse Heaps ausprobiert.
32 MB funktioniert schonmal garnicht. Da läuft die CPU auf nahezu 100% und versucht den Speicher zu regeln.
44 MB spuckt Fehlermeldungen ala GC Overhead limit exceeded am laufenden band und liefert auch keine Antworten auf Requests. CPU ist auch gut beschäftigt.
Mit 50 MB funktioniert es halbwegs.
Bei 64 MB funktioniert es gut. CPU ist dann auch wieder am idlen.

Heap vergrössern wäre die erste Maßnahme und dann ein einfaches war darauf deployen um zu sehen ob es da strukturelle Probleme gibt.

[NicoDeluxe]

das problem hab ich auch it einer spring boot application, scheint also irgendwie ein generelles java problem zu sein

[AmunRa]

Hallo Nico

hast du jetzt schon mal ausprobiert (wie oben vorgeschlagen) den -Xmx parameter von 32 Megabyte (das ist tatsächlich extremst wenig. Warum startest du es mit diesem Wert) auf (testweise) mal 126m zu ändern oder sogar noch mehr. Tritt das verhalten dann auch auf?

[NicoDeluxe]

Ja das passiert dann auch. Der reagiert einfach nicht mehr. Welche Mindestanforderungen an den Server sollte man stellen? Wie viel RAM, wie viel Kerne? hat jemand einen groben Richtwert? Kommt auf die Programme an ich weiß, aber “darunter brauchst du nicht anfangen” würde mir genügen

[ionutbaiu]

Hast du jetzt mal versucht ein einfaches (HelloWorldServlet) oder das von mir verlinkte war mit mindestens 64MB Heap zu deployen?

Grundsätzlich sind das Erfahrungswerte und Erfahrungswerte muss man sich erarbeiten.

Starte einfach mal deinen Server mit 512 MB Heap oder 1 - 2 GB. Hauptsache viel, darf ruhig überdimensioniert sein.

Wenn das läuft, dann startest du JVisualVM, gehst dort auf deine Anwendung und schaust dann wie groß der Heap tatsächlich ist und wieviel davon gerade genutzt wird. Dann führst du dort mal manuell eine GarbageCollection durch und beobachtest die Werte weiter. Dort kannst du auch die CPU Usage anschauen und sehen was so benötigt wird.

Für JVisualVM braucht es aber glaube ich Oracle Java. Damit kann man sich dann an das rantasten, an das was man braucht.
Das kann man dann auch laufen lassen während die Anwendung tatsächlich arbeitet und sehen wie sich das unter Last verhält.

Ein einfaches war mit 512 MB Heap, holt sich so 290 MB und verbraucht davon tatsächlich zwischen 40 MB nach GC und 180 MB bevor automatisch einen GC durchführt wird.

Dem Bild entsprechend würde ich das ganze nun mit 128 MB deployen. Da würde dann der GC jede Minute einmal zuschlagen. So kann man das dann etwas justieren um für sich die passenden Werte zu finden.

[maki]

Welche java version nutzt du denn auf dem Server?

Java 9 scheint etwas mehr Konfigurationsaufwand zu sein:

Payara Micro fails to start on Java 9

Ganz ehrlich und nicht boese gemeint, wenn du einfach mal die Infos vorab geben koenntest anstatt dir alles aus der Nase ziehen zu lassen (log files, server spec, etc. pp.), ware es einfacher zu helfen, aber so ist das ganze ziemlich muessig.

Je mehr info du vorab gibst, umso wahrscheinlicher dass man dir helfen kann.

@NicoDeluxe

das problem hab ich auch it einer spring boot application, scheint also irgendwie ein generelles java problem zu sein

Ist kein generelles Java problem, ist (mindestens) ein Konfig problem…

[NicoDeluxe]

Hey, Java 8

ich hab nun einen kleinen popeligen vserver getestet, da läuft es. Es muss also am Cloudserver liegen, hab das mal an deren Techniker gegeben. Scheint also nicht am Programm/Java zu liegen sondern irgendwas am OS