Java RAM Management

[OnDemand]

Hallo zusammen,

hat jemand eine gute und verständliche Resource, wie Java mit RAM umgeht?

Hab das Problem, dass meine Services laufen immer voller und voller, als ob da keine alten Objekte entfernt werden. Der RAM steigt bis das OS den Prozess killt.
Nun muss ich mich da irgendwie mal einlesen in das Thema.

 

[White_Fox]

Hast du mal den GC gerufen?

Wenn die alten Objekte nicht entfernt werden würde ich mal schauen ob die wirklich herrenlos werden und nicht noch in irgendeiner Collection vor sich hingammeln...so oder so ähnlich klingt das jedenfalls für mich.

PS: Das Thema GC hatten wir hier vor einiger Zeit schon einmal, vielleicht findest du ihn ja. Irgendwer schrieb da dazu, daß der ganze GC-Kram von der jeweiligen JVM-Implementatin abhängt (was eigentlich auch logisch ist).
Sprich: Ob es da so viel zu lesen gibt außer Doku und Quellcode von deiner konkreten Implementation wird wohl fraglich sein.

 

[Barista]

Du solltest auch mal nach 'Java Memory Leak' suchen.

 

[mrBrown]

Grundsätzlich zu GCs: http://www.angelikalanger.com/Articles/EffectiveJava/49.GC.GenerationalGC/49.GC.GenerationalGC.html (gesamte Serie lesen, unten stehen dort die Links)


Wenn der RAM kontinuierlich voller wird, gibt es entweder ein Memory-Leak (also, irgendwo hängen noch Referenzen, und werden nicht aufgeräumt), oder der GC hat einfach nie aufgeräumt – ersteres ist meistens das deutlich wahrscheinlichere.

Wenn bei dir der Prozess gekillt wird, ohne das vorher ein Haufen Exceptions fliegt, könnte es an falsch eingestellten Limits liegen. Aus JVM-
Sicht gibt es noch genug freien Speicher, aus OS-Sicht nicht – der GC läuft also nicht, der Prozess wird aber trotzdem gekillt.

Auf die Spur kommst du dem nur mit Logging und Monitoring. Kannst für den Anfang zB Start-Paratemeter ausgeben lassen (zum Überprüfen der Memory-Limits) und GC-Logging aktivieren, dann siehst du zumindest was der GC macht. Nächstes wäre dann Monitoring mit zB Visual VM, darüber kann man Memory-Leaks finden.

 

[mrBrown]

Hast du mal den GC gerufen?

Der "per Hand" rufen ist fast immer die falsche Wahl – aus Speicher-Verbrauchs-Sicht macht es für die JVM selbst keinen Unterscheid, bevor der Speicher voll ist, würde die sowieso selbst aufräumen, und aus Performance-Sicht ist es meistens eher ein Nachteil, da die damit angestoßene GC üblicherweise länger braucht als eine automatische (weil mehr aufgeräumt wird), beides kann sich aber je nach GC auch unterscheiden. Und wirklich garantiert anstoßen kann man sie eh nicht, die JVM darf das auch einfach ignorieren.

 

[thecain]

Hast du mal den GC gerufen?

Hoffentlich nicht, das ist eigtl nie nötig.

Der Parameter -XX:+HeapDumpOnOutOfMemoryError könnte bei der Fehlersuche evtl. helfen

 

[mrBrown]

Der Parameter -XX:+HeapDumpOnOutOfMemoryError könnte bei der Fehlersuche evtl. helfen

Eigentlich verwunderlich, dass sowas nicht einfach immer aktiviert ist...

 

[LimDul]

Hoffentlich nicht, das ist eigtl nie nötig.

Der Parameter -XX:+HeapDumpOnOutOfMemoryError könnte bei der Fehlersuche evtl. helfen

Ich klink mich mal ein - würde sowas auch bei einem JBoss helfen? Nach X Deployments geht der Regelmässig mit einen OutOfMemoryError - OutOfMetaspace auf die Bretter. Das kann ja eigentlich kein Anwendungscode sein, weil die Anwendung ja jedes mal neu deployed wird.

 

[mrBrown]

Ich klink mich mal ein - würde sowas auch bei einem JBoss helfen? Nach X Deployments geht der Regelmässig mit einen OutOfMemoryError - OutOfMetaspace auf die Bretter. Das kann ja eigentlich kein Anwendungscode sein, weil die Anwendung ja jedes mal neu deployed wird.

Wenn ich mich recht erinnere umfasst der HeapDump dabei wirklich nur den Java-Heap,


Wenn ich raten müsste tritt das auch, wenn die Anwendung oft genug redeployed wird, aber nicht "einfach so" wenn die Anwendung einfach nur lang unter Last läuft?
Das ist am ehesten ein Class-Unloading-Problem tief irgendwo in JBoss selbst, da kann man vermutlich kaum mehr machen, als das zu melden und zu hoffen.
Hilfreich könnte aber u.U. dies: https://stackoverflow.com/a/37933050, ich würde aber erwarten, das es am ehesten das obige bestätigt.

EDIT: vielleicht auch interessant: https://stackoverflow.com/a/38875640

 

[LimDul]

Wenn ich mich recht erinnere umfasst der HeapDump dabei wirklich nur den Java-Heap,


Wenn ich raten müsste tritt das auch, wenn die Anwendung oft genug redeployed wird, aber nicht "einfach so" wenn die Anwendung einfach nur lang unter Last läuft?
Das ist am ehesten ein Class-Unloading-Problem tief irgendwo in JBoss selbst, da kann man vermutlich kaum mehr machen, als das zu melden und zu hoffen.
Hilfreich könnte aber u.U. dies: https://stackoverflow.com/a/37933050, ich würde aber erwarten, das es am ehesten das obige bestätigt.

EDIT: vielleicht auch interessant: https://stackoverflow.com/a/38875640

Jepp, nur durch Redeployed - Laufen tut die Anwendung stabil. Danke für die Links, mal schauen ob ich im Projekt mal genug Luft habe tiefer reinzuschauen was der bei uns tut. Es ist halt nervend aber kein echtes Problem (Lokal startet man den JBoss eh regelmäßig neu und auf den Testsystemen mit Autodeployment über Jenkins muss ich mich halt 1x die Woche einloggen auf dem Server und den JBoss neustarten)

 

[OnDemand]

Danke euch Der Heapdump zeigt an, welche Objekte noch rum liegen oder?

Wann ist der GC der Meinung ein Objekt zu entfernen? Eigentlich wenn es NULL ist oder? Hab viele Hashmaps und Listen, ich vermute die verwirft er nicht, da diese niemals NULL werden, was aber nach dem abarbeiten der List / Map gern passieren kann

 

[LimDul]

Der GC darf nur Objekte verwerfen, die nicht mehr stark referenziert werden. Das hat nix direkt mit null werden zu tun.

Sprich, wenn es in deiner Anwendung noch Referenzen gibt, über die die Listen erreicht werden können, dann bleiben die erhalten.

Beispiele

private void meineMethode() {
List volleListe = ....;
}

Wenn die Methode fertig ist, kann die volleListe abgeräumt werden - es gibt keine Referenz mehr darauf.

Problematisch sind bzgl. Speicherlecks in Java so Dinge wie:
* static Referenzen
* Singletons (die sind ja quasi auch statisch)
* Caches, Lookup-Tabellen etc- alles wo man wiederverwendbar größere Datenmengen sammelt

Wenn du z.B. eine static Field von der Klasse X hast und die Klasse wiederum eine Membervariable der Klasse Y hat und die Klasse Y wiederum irgendwelche Member hat - dann werden die Inhalte da nie abgeräumt, da das statische Feld immer zugreifbar ist, dadurch ist dieses Objekt der Klasse X zugreifbar, dadurch ist das Objekt der Klasse Y was dadurch referenziert wird zugreifbar usw.

 

[mihe7]

Nach X Deployments geht der Regelmässig mit einen OutOfMemoryError - OutOfMetaspace auf die Bretter.

Bah, das war beim Glassfish auch so - dort allerdings wegen PermGen. Das hat sich zwar mit Java 8 geändert, allerdings merkt man nach zig redeploys, wie das Teil immer langsamer wird. In Produktion ist das allerdings kein Problem mehr, da wir nicht mehr redeployen, Docker lässt grüßen

 

[LimDul]

Hier im Projekt sind wir noch nicht produktiv - bei einem anderen Kunden wurde es da einfach so gelöst, das nach einen Deployment der ganze JBoss nochmal komplett durchgestartet wurde (aka "Vorschlaghammer drauf" und Ruhe).

 

[mihe7]

das nach einen Deployment der ganze JBoss nochmal komplett durchgestartet wurde (aka "Vorschlaghammer drauf" und Ruhe).

Kommt mir bekannt vor

 

[OnDemand]

Huhu, hab jetzt gcverbose aktiviert. Dann logged es einiges. Man sieht aber, dass der RAM kontinuierlich steigt, lese ich das richtig raus?

Vielleicht wäre noch eine Info wichtig, mein Programm arbeitet in 50 eigenen Threads dinge ab (jeder Benutzer ein Thread) in der StartDatei habe ich -xmx5gb angegeben, heisst das jeder Prozess bekommt 5gb oder der service? wenn ich das runter nehme, komme ich auf memory allocation errors

 

[mihe7]

Mein Verständnis dazu ist folgendes:

Xms -> Mindestgröße des Heaps
Xms -> Maximalgröße des Heaps

Der Prozess selbst braucht mehr, hier geht es nur um den Heap. Die JVM reserviert beim Start die Mindestgröße und dann nach Bedarf bis zur Maximalgröße für den Heap. Danach ist Schluss, ebenso wenn die Reservierung fehlschlägt. Letzteres kann man verhindern, wenn man Xms mit der gleichen Größe wie Xmx angibt, da dann beim Start gleich die maximale Größe reserviert wird.

 

[mrBrown]

Die Zahl vor dem markierten müsste der „belegte“ Speicher seien, also das, was der GC nicht wegräumt. Das markierte ist nur der vorhandene Platz, der dabei aber zum Großteil leer ist.

 

[LimDul]

Grundsätzlich gibt die JVM afaik einmal reservierten Speicher nicht mehr zurück, sprich dass der gesamte reservierte Speicher nur steigt ist ein normales Verhalten. Problematisch wird es erst, wenn der genutzte Speicher auch nur steigt.

 

[httpdigest]

Grundsätzlich gibt die JVM afaik einmal reservierten Speicher nicht mehr zurück, sprich dass der gesamte reservierte Speicher nur steigt ist ein normales Verhalten.

Does GC release back memory to OS?

When the garbage collector runs and releases memory does this memory go back to the OS or is it being kept as part of the process. I was under the strong impression that the memory is never actually

stackoverflow.com

 

[mrBrown]

Grundsätzlich gibt die JVM afaik einmal reservierten Speicher nicht mehr zurück, sprich dass der gesamte reservierte Speicher nur steigt ist ein normales Verhalten. Problematisch wird es erst, wenn der genutzte Speicher auch nur steigt.

Mindestens die neueren GCs ab G1 machen das. Müsste man auch irgendwie explizit loggen können.

 

[Thallius]

Man sollte übrigens genau deswegen beim Entwickeln und testen den erlaubten Speicher auf ein Minimum setzen um eben solche Fehler direkt zu finden und nicht erst wenn schon 50 Leute damit arbeiten.

BTW: Ich habe es bisher noch nie geschafft eine App zu schreiben die 5GB Speicher braucht und mit meinen Apps arbeiten Mitarbeiter aus ganz EMEA gleichzeitig.

 

[OnDemand]

Ich habe jetzt das xms und xmx auf den selben Wert gesetzt, jetzt läuft es stabil. Auf dem Server laufen gut 4 Anwendungen welche zig gigabyte an Daten abholen und verarbeiten. Passt nun soweit

 

[mrBrown]

Ich habe jetzt das xms und xmx auf den selben Wert gesetzt, jetzt läuft es stabil. Auf dem Server laufen gut 4 Anwendungen welche zig gigabyte an Daten abholen und verarbeiten. Passt nun soweit

Hast du denn vorher mal nach der Ursache gesucht? Nur Symptome zu behandeln ist nicht immer das sinnvollste, kann sein, dass der Fehler jetzt einfach nur drei Tage länger braucht, bis er auftritt

BTW: Ich habe es bisher noch nie geschafft eine App zu schreiben die 5GB Speicher braucht und mit meinen Apps arbeiten Mitarbeiter aus ganz EMEA gleichzeitig.

Dir ist schon bewusst, dass das kein wirkliches Achievement ist?

 

[OnDemand]

Hab zur Zeit leider keine Zeit da mehr zu investierten. Die App wird demnächst abgelöst, von daher nicht so wild sollte sie nochmal abschmieren.

für die neue App hab ich mit Aber fest genommen den Speicher besser zu analysieren. Welches Tool ist dafür am besten geeignet? Jmetric oder wie es hieß? Nutze IntelliJ da gibts bestimmt auch gute Plugin

 

[mihe7]

Nur Symptome zu behandeln ist nicht immer das sinnvollste, kann sein, dass der Fehler jetzt einfach nur drei Tage länger braucht, bis er auftritt

@NicoDeluxe so war das mit Xmx und Xms auch nicht gemeint

 

[temi]

In "Effective Java" von Bloch werden auch ein paar Gründe für Speicherlecks in Java genannt.

https://www.informit.com/articles/article.aspx?p=1216151&seqNum=6

Ist ja vielleicht interessant für dich. Ich halte im Übrigen das gesamte Buch für lesenswert.