JVM-Option: verbose:gc

[VfL_Freak]

Moin,

ich bin derzeit auf der Suche nach Speicherlecks in meiner Anwendung und lese dazu viele Webseiten und habe mir auch das Buch "Java Core Programmierung - Memory model und Garbage Collection" von A. Langer und K. Kreft besorgt.

Nun bin ich auf die o. g. Option "verbose:gc" gestossen, zu der auf der Oracleseite steht:
If you simply use the verbose:gc flag, you'll have GC log output sent to the stdout console

Ich habe nun auch meine Anwendung hiermit gestartet (direkt von Eclipse aus), jedoch bekomme keinerlei Ausgaben. Auch der Versuch, diese Ausgabe per " -Xloggc" in eine Datei umzulenken, brachte kein Ergebnis.

Da ich mir sicher bin, dass das GC ausgeführt wird (sehe ich ja in jConsole resp. VisualVM), frage ich mich : was mache ich hier falsch?

Danke und Gruß
Klaus

 

[Gast2]

Das geht mit dem MemoryAnalyzer super!

Java Performance blog: Memory leaks are easy to find

und

Eclipse Memory Analyzer Open Source Project

Einfach nen Dump erstellen und ganz krasse Sachen schlägt der schon von sich aus vor!

Das Tut ist auch recht gut!

 

[VfL_Freak]

Moin,

ok, Danke - werde mir die Links mal zu Gemüte führen ...

Danke und Gruß
Klaus

 

[FerFemNemBem]

Mahlzeit,

wenn Du eclipse das VM-Argument mitgiebst, bekommst Du auch entsprechende Ausgaben - jedoch natuerlich nur, wenn der gc auch was zu tun hat. Das sieht dann in etwa so aus:

[GC 64960K->17532K(249088K), 0.0264930 secs]
[GC 82492K->25681K(249088K), 0.0162167 secs]

Konfiguriert wird es dort:

Zum finden von MemoryLeaks empfehle ich (wenn Du eclipse benutzt) wie oben schon geschrieben, den Memory Analyzer (MAT) als eclipse Plugin: Eclipse Memory Analyzer Open Source Project

Der gibt Dir schon ordentliche Tips, wenn ihm was suspekt vorkommt.

Gruss, FFNB.

 

[VfL_Freak]

Moin,

ah, jetzt klappt es ... das GC muss klein geschrieben werden ....
Ich hatte ein Beispiel im Web gefunden, wo es groß stand und ich es auch so übernommen hatte

Habe mich jetzt mal mit dem MAT beschäftigt, bin aber noch nicht wirklich glücklich damit ;(
Zum einen zeigt er mir in den Dumps zu 98% nur irgendwelches Gedöns aus den Java-Klassen an, zum anderen schwankt bei mir der Speicherverbrauch - bedingt durch Art der Applikation (es laufen derzeit zyklische Prozesse im Sekundentakt - recht stark. Meistens sind es zwischen 30 und 40 MB, wobei der Gesamtverbrauch langsam ansteigt. Ich kann dies zwar mittlerweile im wesentlich dem Tenured Heap zuschreiben, sehe aber derzeit (noch) keine Chance, dies konkreten Stellen im Quellcode zuordnen zu können ...

Trotzdem erst mal Danke!
Gruß
Klaus

 

[tuxedo]

Kann wärmstens den Yourkit Java Profiler empfehlen. Man bekommt kostenlos einen Test-Key mit dem man 2 Wochen lang testen kann. Wer YJP länger braucht muss sich ihn kaufen (nicht wirklich billig), oder aber ein OpenSource Projekt sein eigenen nennen, denn dann gibt's eine Lizenz für umme.

YJP ist bis dato das beste was ich in den Händen hatte.
Das Zweitbeste ist der in Netbeans enthaltene Profiler.

- Alex

 

[FerFemNemBem]

Halloechen,

oder haenge Dich mit VisualVM an Deine Applikation. Das kann auch Hinweise liefern.

Gruss, FFNB.

 

[VfL_Freak]

Moin,

Halloechen,
oder haenge Dich mit VisualVM an Deine Applikation. Das kann auch Hinweise liefern.

Ja, damit arbeite ich hier auch (und natürlich jConsole). Beide zeigen aber nicht wirklich auf, was da im Speicher hängen bleibt.

Ich hatte jetzt die Applikation mal über Nacht laufen lassen und automatisch im quasi Sekundentakt mit seiner Aufgabe beballern lassen.

Immerhin zeigte mir die o. g. Programme und die GC-Ausgabe an, dass spätestens nach 4 - 5 Stunden der max. Heap-Speicher, den ich dem Programm mitgebe (max-heap-size="512m" in der JNLP) vollständig angefordert wurde und ca. 300 - 350 MB in Benutzung sind.
Der Tenured Speicher ist dann mit ca. 150 - 180 MB belegt und ein Full GC dauert um 30 - 40 sec., wodurch dann irgendwann die Applikation in die Knie geht ...
Im HeapDump sind allenfalls byte[], char[] und int[] auffällig, ohne dass ich dies wirklich im Code zuordnen kann, da diese Strukturen recht häufig verwendet werden

Ich fürchte, dass irgendwo größere Objekte erzeugt werden (u. a. werden permanent Bilder geladen und dargestellt), deren Speicher dann vlt. nicht mehr frei gegeben werden kann ......

Mal schauen, ob, ich doch noch was beim Debuggen finde!

Danke und Gruß
Klaus