Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
ich habe einen Quartzjob welcher von externen Schnittstellen allerhand Daten holt und diese in Maps speichert. Mit den Maps erledigt der Job dann seine Aufgaben. Wenn der Job fertig ist, wird aber der RAM nicht freigegeben, obwohl ich die Maps .clear() nachdem alles fertig ist. Ist jemandem ein Startparameter bekannt, welcher irgendwie ausgibt was im RAM ist?
Gestartet wird das Programm auf debian mit xms7g und xmx7g reicht eine ganze Weile aber irgendwo läuft was über. Werde demnächst mal versuchen das über einen Analyzer herauszufinden, aber da brauch ich ein wenig Lernzeit. Kennt jemand noch irgendwas hilfreiches um herauszufinden an welcher Stelle ein Programm wegen des RAM abschmiert? Im Log sehe ich immer nur "insufficienz Memory" aber nicht die Stelle wo er überlief.
In Java muessen wir sehr wenig ueber Speicher nachdenken, dass liegt daran dass das System mit einer "Garbage Collection" arbeitet. Dies unterscheidet sich von anderen Sprachen in der Art und Weise wie mit Speicher umgegangen wird. In C, C++ und anderen nativen Sprachen zum Beispiel, arbeitet man "direkt" mit dem Speicher welchen man vom System allokiert. Man holt sich diesem von System, verwendet ihn und gibt ihn danach dem System zurueck. In Java ist es aber so dass wir uns keine Gedanken ueber den Speicher selbst machen muessen, insbesondere nicht wenn es um die Interaktion mit dem Betriebssystem geht. Die JVM allokiert und bezieht Speicher vom Betriebssystem, gibt diesen an unsere Objekte aus, und gibt diesen nach Moeglichkeit an das Betriebssystem zurueck.
Wie sieht das konkret aus? Nehmen wir erstmal ein Beispiel in C, wir wollen zehn Arrays mit je ~50MB allokieren, weil wir dieses gleich mit Daten befuellen werden. Hier in Pseudo-Code:
C:
int[][] data = new int[10][];
for (int index = 0; index < 10; index++) {
data[index] = malloc(INT_SIZE * 10 * 1024 * 1024);
}
// Verwendung
for (int index = 0; index < 10; index++) {
free(data[index]);
}
Das ergibt dann eine Speicherverwendung welche in etwa so aussieht:
Das blau ist der allokierte Speicher unserer Applikation, wie wir sehen steigt dieser Sprunghaft an, und sinkt auch wieder Sprunghaft, entsprechend mit unseren Aktionen. Unsere Speicherverwendung innerhlab der Applikation entspricht dem was wir vom Betriebssystem beziehen. Also eine Allokierung von einem neuen Array entspricht hier auch dem beziehen des Speichers vom Betriebssystem.
Soweit, so klar. Wir aendern jetzt noch unser Muster etwas, und zwar allokieren wir immer nur so viel Speicher wie wir gerade brauchen:
Das ergibt uns dann ein Muster in der Speicherverwendung welches so aussieht:
Wir sehen, wir verwenden sehr wenig Speicher, immer nur in Bloecken, und geben diese auch danach wieder frei.
Nun haben wir in Java aber die JVM zwischen uns und dem Betriebssystem, und hinzu kommt noch dass wir Speicher nicht direkt allokieren und freigeben, sondern wir legen Objekt-Instanzen an. Diese Instanzen koennen wir so gar nicht freigegeben, wir koennen lediglich alle Referenzen von diesen Instanzen auf null setzen. Dies entpricht aber nicht einer Freigabe des Speichers, da wir nicht direkt mit dem Speicher des Betriebssystems arbeiten. Die JVM allokiert den Speicher und gibt uns diesen fuer unsere Objekte.
Nehmen wir hierzu zu an dass das Data Objekt in etwa 50MB entspricht, und wir 10 davon wollen:
Java:
Data[] data = new Data[10];
for (int index = 0; index < 10; index++) {
data[index] = new Data[];
}
// Verwendung
for (int index = 0; index < 10; index++) {
data[index] = null;
}
Das ergibt dann einen Speicherverbraucht welcher so aussieht:
Blau ist der Speicher welcher zu unseren Objekten gehoert, Orange ist der Speicher welcher von unserer JVM allokiert wurde vom Betriebssystem. Wir sehen, die JVM haelt sich von Haus aus bereits mehr Speicher als die Applikation benoetigt. Wenn der Speicher knapp wird, wird der naechste grosze Block vom Betriebssystem allokiert. Dies hat den Vorteil dass die JVM weniger Speicherallokierungen vom Betriebssystem machen muss als unser Programm in C, deswegen gibt es auch Faelle in welchen Java einfach schneller ist als die native Implementierung, weil die Kosten fuer diese Allokierungen wegfallen. Wir sehen aber auch dass am Ende der Speicher einfach "bleibt", obwohl wir die Referenzen all auf null gesetzt haben. Das liegt daran dass die Garbage Collection hier in diesem Beispiel noch nie gelaufen ist.
Wenn wir am Ende von diesem Beispiel annehmen dass die Garbage Collection einmal laeuft, wurde es so aussehen:
Java:
for (int counter = 0; counter < 10; counter++) {
Data data = new Data();
}
Wir sehen dass der Speicher unserer Objekte durch die Garbage Collection wieder freigeraeumt wurde, aber die JVM haelt immer noch den Speicher welchen sie vom Betriebssystem allokiert hat. Wurden wir das Programm weiterlaufen lassen, wuerde sie diesen Speicher langsam wieder ans Betriebssystem zurueck geben, dies geschieht aber wirklich "menschlich" langsam. Also erst in Minuten werden die ersten Bloecke wieder freigegeben. Dies passiert unter anderem um die naechste Speicherlastspitze wieder fangen zu koennen ohne erst wieder vom Betriebssystem den Speicher wieder allokieren zu muessen.
Sehen wir uns jetzt unser zweites Verwendungsbeispiel an unter Beruecksichtigung der Garbage Collection:
Wir sehen dass die JVM solange unsere erzeugten Objekte im Speicher behaelt bis zu dem Moment wo sie einen neuen Block allokieren muesste. Davor wird eine Garbage Collection faellig, da wir keine Referenzen auf diese Objekte mehr haben, werde diese eingesammelt und der Speicher ist wieder frei und kann von der JVM wieder vergeben. Wuerden wir Referenzen halten, koennten diese Objekte nicht eingesammelt werden und die JVM muessten mehr Speicher vom Betriebssystem allokieren.
Die Garbage Collection laeuft nur dann wenn es fuer notwendig erachtet wird, was "notwendig" ist, ist ein Implementierungsdetail der jeweiligen Garabage Collection selbst, hier gibt es auch Unterschiede. Pauschal kann man aber sagen dass die Garbage Collection dann arbeitet wenn der Speicher knapp zu werden beginnt. Je knapper der Speicher, desto oefter laeuft die Garbage Collection. Dass sind die klassischgen Situationen in welchen das Programm langsamer und langsamer wird, denn um den Speicher aufraeumen zu koennen muss die Garbage Collection alle Threads anhalten.
Es gibt noch die Funktion System.gc() um die Garbage Collection anzustoszen, dies ist aber nur ein Vorschlag fuer die Garbage Collection, und ob diese dann etwas tut oder nicht, ist ein Implementierungsdetail und darauf sollte man sich nicht verlassen.
Wenn du jetzt das Problem hast dass der Speicher volllaeuft, dann ist das deswegen weil nicht alle Referenzen wieder freigegeben wurden. Wo die OutOfMemory-Exception passiert muss nicht dort sein wo der meiste Speicher verwendet wird, absolut nicht, dass kann in einem komplett anderen Teil der Applikation sein.
Am besten holt man sich so etwas wie VisualVM mit dem man den Speicher betrachten kann, oder man macht sich ein Speicherabbild in dem Moment wo der Prozess stirbt und analysiert dann diesem welche Objekte nicht wieder freigegeben werden und wo der Speicher hin verschwindet.
Wow danke für die ausführliche Antwort! Heisst also, wenn ich meine Maps nur .clear() wird sie geleert, aber nicht genullt. Ok aber immerhin ist sie ja dann leer. Hab direkt 2 Maps gefunden welche ich nicht leere, dann muss ich mich wohl mit VisualVM vertraut machen. Ich vermute, dass ich da auch remote prüfen kann? Denn mein lokaler Mac hat 32GB RAM den bekomm ich so nicht zum Absturz.
Danke Dir!
ok, wie gesagt muss mich echt damit in Ruhe befassen. Vielleicht auch noch etwas am Code ändern und nicht alles an Daten speichern, was das externe System hergibt
Nein, sie wird geleert, damit sind die Referenzen *in dieser Map* weg. Aber ob der Speicher freigegeben wird oder nicht, ist ein Implementierungsdetail der JVM.
Ja, ist aber aufwaendiger, glaube ich, habe ich aber noch nie gemacht. Du kannst dir aber Thread/Memory-Dumps von dem Prozess machen und die dann in VisualVM laden.
Locker, du musst einfach nur den maximalen Speicher auf 2GB drehen, -xmx2g muesste das sein, dann bist du da auch schnell an irgenwelchen Grenzen. Aber es geht ja nicht um den Absturz, du musst ja nur wissen was nicht freigegeben wird, und das kannst du ja auch lokal schauen mit VisualVM wenn du dir einen Test baust der das einfach immer und immer wieder ausfuehrt ohne dass der Java Prozess neugestartet wird.
Nein, sie wird geleert, damit sind die Referenzen *in dieser Map* weg. Aber ob der Speicher freigegeben wird oder nicht, ist ein Implementierungsdetail der JVM.
Also ist die Map die Referenzen in der Map sind weg, existieren aber noch wo anders?
hab in IntelliJ einen Profiler, aber was der mir sagen will muss ich noch studieren. Sieht erstmal schön bunt aus
Ich habe in einer älteren Version die Maps immer
map.clear();
map = null;
gemacht nachdem alles fertig war. Komischerweise war das Problem da noch nicht vorhanden, wird wohl aber Zufall sein
Evtl. gibt es auch nur ein einfaches Verständnisproblem. Was genau stellst Du fest?
Du hast mehrere Ebenen. Zum einen natürlich die Sicht vom Betriebssystem. Du startet eine Applikation, diese bekommt Speicher zugewiesen und diesen Speicher nutzt die Applikation. Das siehst Du z.B. im Taskmanager von Windows oder auf Unix(artigen) Systemen mittels ps oder top.
Dann hast Du die Sicht von Java. Dem Java Prozess steht etwas Speicher zur Verfügung. Der Prozess lädt dann nach und nach mehr in den Speicher (z.B. Klassen und so), und im Ablauf wird dann gewisser Speicher von der Applikation intern benutzt. Wenn der Speicher, den der java Prozess hat, nicht ausreicht und der maximale Speicher noch nicht belegt wurde, wird noch mehr Speicher vom Betriebssystem angefordert.
Wenn jetzt der Garbage Collector Speicher freigibt, dann wirst Du das aus Betriebssystemsicht nicht (direkt) sehen. Es ist prinzipiell denkbar, dass der java Prozess auch Speicher freigibt, aber zumindest als ich vor einigen Jahren das mal geschaut hatte, war das in meinen Tests nicht der Fall. Das ist aber kein Zeichen auf ein Speicherleck oder so!
Daher mit dieser Erklärung einfach einmal die Frage: Ist es evtl. möglich, dass es hier eine Fehlinterpretation gab?
Die VM auf der die App läuft hat 8GB. Ich habe der App 6GB über xms6g xmx6g zugewiesen. Für mein Verständnis heisst das Sie hat mindestens 6 und höchstens 6GB vom "echten" Speicher. Sprich also die JVM arbeitet mit 6GB und beschlagnahmt immer 6GB egal ob sie die braucht oder nicht.
Nun verstehe ich es so, dass die App 6GB von den 8 "echten" für sich vereinnahmt. Innerhalb der 6GB werden Klassen erstellt, Maps usw usf. ist das soweit erstmal richtig oder hier schon ein Denkfehler?
Beim Abarbeiten des Jobs wird eine TXT Datei gelesen welche 290MB groß ist, aus jeder Zeile der Textdatei wird ein Objekt erstellt. Rein von der Logik her, geht man davon aus, 290MB Datei = 290GB RAM plus minus. Aber ich denke hier hab ich nochmal ein wenig Nachholbedarf fürs Verständnis. Das Thema Speichermanagement finde ich kam in den ganzen bisherigen Kursen und Schulungen zu kurz. Vielleicht stell ich mich aber auch nur zu doof an 🙃
Nun verstehe ich es so, dass die App 6GB von den 8 "echten" für sich vereinnahmt. Innerhalb der 6GB werden Klassen erstellt, Maps usw usf. ist das soweit erstmal richtig oder hier schon ein Denkfehler?
Ja genau, also ich lese die Datei ein, diese nimmt 290MB von den 6 JVM GB. Sprich dem OS bleiben trotzdem 2GB
Ich habe irgendwie das gefühl, dass das mit den VM zu tun haben könnte. Denn ein anderer User läuft exakt mit den selben Einstellungen auf dem gleichen Host, hat aber keine Probleme.
Ja, aber...die Frage ist natuerlich wie du die einliest. Wenn du sie als Byte-Array liest und daraus dann einen String baust hast du mal kurz vermutlich eher 900MB beschlagnahmt (290MB Byte Array, 580MB String-Array weil UTF-16). Wenn du da eine XML liest dann, ja...Angst.
Aber vom Prinzip her richtig, alles was du in deinem Prozess machst spielt sich in dem JVM Speicher ab.
Was mir grad noch sauer aufstöst ist, dass ich im Log etliche Einträge sehe die mir nach "Hacking" aussehen. Dazu mach ich gern mal einen weiteren Post. Vielleicht wird die App auch einfach nur "angegriffen" welches Probleme verursacht. Vielleicht hat noch jemand Lust dort ein wenig zu diskutieren: https://www.java-forum.org/thema/spring-boot-seltsame-logeintraege-manipulationsversuche.197698/
Urkomischerweise, läuft die App grad stabil, kein RAM Problem mehr. Ich melde mich gern wieder sobald ich die konkrekte Fehlermeldung habe.
Die VM auf der die App läuft hat 8GB. Ich habe der App 6GB über xms6g xmx6g zugewiesen. Für mein Verständnis heisst das Sie hat mindestens 6 und höchstens 6GB vom "echten" Speicher. Sprich also die JVM arbeitet mit 6GB und beschlagnahmt immer 6GB egal ob sie die braucht oder nicht.
Nun verstehe ich es so, dass die App 6GB von den 8 "echten" für sich vereinnahmt. Innerhalb der 6GB werden Klassen erstellt, Maps usw usf. ist das soweit erstmal richtig oder hier schon ein Denkfehler?
Die 6Gb würden für die Java-Heap genutzt, grob gesagt für deine Objekte. Daneben gibt’s aber noch Non-Heap-Memory, den zB die JVM selbst nutzt für Metaspace, Call Stacks, nativen Code.
Wenn du Spring Boot nutzt: du kannst zB Prometheus zum Monitoring nutzen, damit bekommt man u.a. schon mal einen Langzeit-Überblick über den Speicher-Verbrauch im Live-Betrieb
