Profiling und Memory Analyse in Java
Ich habe in den letzten Wochen sehr viel Zeit damit zugebracht ein paar kleine Speicher-Problemchen zu debuggen. In der Theorie sollte es in Java ja keine Memory-Leaks geben, oder? Gibt es aber doch. Die von mir untersuchten Probleme waren nicht sehr schwerwiegend und traten nur bei sehr lang laufenden Applikationen auf (die betreffenden Webapps werden gewöhnlich für anfallende Änderungen so regelmässig neu gestartet, daß die Probleme über lange Zeiträume gar nicht auffielen). Aber die ganz Sache war ein bisschen Neuland für mich. Ich musste alles über Heap-Dumps und wie man sie erzeugt lernen, mir einen Überblick über verfügbare Profiling Werkzeuge beschaffen und mich dann auch noch besser in JMeter einarbeiten um reproduzierbare Lasten zu produzieren.
Zuerst habe ich mir das Eclipse TPTP angeschaut, bin damit aber nicht zurecht gekommen - zudem funktioniert das unter OSX offensichtlich auch nicht und außerdem war mein Eclipse dananch nicht mehr stabil - seufz.
Dann habe ich den NetBeans Profiler ausprobiert. Das hatte zur Folge das ich ersteinmal meine Testprojekte in NetBeans zum Laufen bekommen musste, was zunächst gar nicht so trivial war. Dann allerdings war das Profilen wirklich simpel. Und als Nebeneffekt konnte ich beim Profiling jederzeit Heap Dumps erzeugen. Das ist nämlich auch gar nicht so einfach sofern man nicht mit Java 6 arbeitet (was unter OSX Tiger nicht möglich ist). Da war ich nun also schon weiter. Allerdings hat mir der Netbeans Profiler nicht sonderlich viel Hilfestellung gegeben bei der Suche nach dem Memory Leak. Also weiter gesucht. JProbe wird oft als geeignetes Tool genannt. Allerdings war es mir weder unter OSX noch unter openSUSE 10.3 vergönnt, die Evaluations Version zum Laufen zu bringen. Ich hasse shell skript basierte Installer, die Ihre Payload binhexed in sich tragen und dann versuchen aus sich herauszuschneiden - zumindest wenn es reproduzierbar nicht funktioniert. Also kein JProbe. Dann bin ich auf SAP's Memory Analyzer gestossen (Vorsicht, der Link lässt sich in Safari nicht korrekt anzeigen), ein Eclipse Plugin, das es in sich hat. Es bietet mit seiner Dominator Tree Ansicht genau was ich brauchte um meine Schuldigen zu finden. Der Dominator Tree zeigt Objekte Bäume samt ihrem aggregierten Speicherverbrauch an und erlaubt es realtiv schnell herauszufinden, wer Speicher verbraucht und warum dieser nicht Garbage collected wird.
P.S.: Es lohnt sich einen Blick auf selbstgeschriebene Klassen die sich in eine Logger Hierachie einordnen und auf ThreadLocal Variablen zu werfen.
Posted at 10:43AM Feb 04, 2008 by joerg in Allgemein |