Java Performance Tools – Teil 1 (Grundlagen)

ten technischen Probleme komplexer Java-Anwendungen
sind dabei:
•Schlechte Performance
•Memory Leaks und OutOfMemoryError
•Garbage Collection Overhead
•Deadlocks und Loops
•Synchronisations- und Thread-Safety-
Probleme.
Die Auswirkungen dieser Probleme sind
vielfältig und reichen von schlechten Antwortzeiten,
einer geringen Anzahl paralleler
Benutzer, bis hin zu einem Ausfall des
gesamten Systems und korrupten Daten.
Dies führt bei geschäftskritischen, produktiven
Systemen unweigerlich zu einer
Eskalation im Management, an deren Ende
leider immer die Entwickler stehen. Die
Aufgabe ist klar und einfach formuliert:
Die Probleme schnell identifizieren und
noch schneller beseitigen. Aber wie?
Tools für die Analyse
Es gibt unterschiedliche Tools, um die
beschriebenen Probleme zu analysieren.
Eine der entscheidenden Fragen ist, wie
viele Informationen man für die Lösungsfindung
benötigt und unter welchen Bedingungen
man eine Analyse durchführen
kann. Eine Faustregel ist: Je mehr Daten
von einem Tool gesammelt werden, desto
höher ist der Einfluss des Tools auf die
Anwendung selbst. Es gibt zum Beispiel
kein Tool, das einen kompletten Memory
Dump inklusive Referenzen erzeugen
kann, ohne das System de facto zum Stillstand
zu bringen. Aus diesem Grund unterscheidet
man drei Arten von Tools:
•Monitoring-Tools eignen sich für den
Einsatz in produktiven Umgebungen.
Diese Tools haben einen akzeptablen
Overhead und liefern Informationen
über Probleme in laufenden Anwendungen
bis auf Komponentenlevel. Mithilfe
von Trendanalysen und längerfristigen
Betrachtungen, können Probleme
proaktiv vermieden werden.
•Diagnose-Tools sind für den Einsatz in
Integrations- und Testumgebungen geeignet.
Diese Tools können auch unter
erzeugter Last detaillierte Analysedaten
bis auf Methodenlevel liefern und ha-
www.javamagazin.de
ben noch einen akzeptablen Overhead.
Gerade für Probleme, die nur unter erhöhter
Belastung auftreten und nicht in
der Entwicklungsumgebung, sind diese
Tools unverzichtbar.
•Profiler und Memory Debugger sind
für den Einsatz in der Entwicklungsumgebung
ausgelegt und können Performance-Informationen
bis auf Zeilenebene
liefern. Mithilfe von Memory
Debuggern können zudem Memory
Leaks analysiert werden. Der Overhead,
gerade bei der Memory-Analyse,
ist sehr hoch und man kann diese Tools
nicht in produktiven Umgebungen einsetzen.
Im Folgenden werden die Technologien
beschrieben, auf denen diese Tools basieren.
Des Weiteren werden die integrierten
Tools in der JVM und dem JDK vorgestellt
und anhand von Problemszenarien
beschrieben.
JVM Tooling Interface
Die Java Virtual Machine verfügt seit der
Version 1.2 über eine Schnittstelle für
Profiling Tools, das Java Virtual Machine
Profiling Interface (JVMPI). Die Schnittstelle
definiert die Funktionen für einen in
C oder C++ geschriebenen Agenten, der
sich für die wichtigsten JVM Events registrieren
kann. Zu den Events, für die sich
ein Agent registrieren kann, zählen:
•JVM Life Cycle Events: Für die Initialisierungsphase
der JVM
•Class Life Cycle Events: Load und Unload
einer Klasse. Der Profiling Agent
hat zusätzlich die Möglichkeit, den Inhalt
der Klasse zu lesen und zu verändern
•Thread Life Cycle Events: Für das Erzeugen
und Zerstören von Threads
•Objekt Life Cycle Events: Bei Allokation,
Löschen und Verschieben von
Objekten auf dem Heap durch den Gar-
bage Collector
•Method Call Events: Entry und Exit jeder
aufgerufenen Methode
•Monitor Event – Anfrage, Enter, Exit
und Wait auf einen Java-Monitor (synchronized
und Object.wait())
•GC Events: Beim Start und Ende der
GC-Phase.
Sonderdruck
Neben diesen Events besteht die Möglichkeit,
über den Agenten einen vollständigen
Heapdump zu erzeugen, das
heißt, alle Objekte auf dem Heap inklusive
der Referenzen in eine Datei zu schreiben.
JVMPI ist allerdings kein Standard
und muss somit nicht zwingend von
allen JVM-Herstellern unterstützt werden
bzw. kann in der Implementierung
abweichen. Mit JSR 163 (Java Platform
Profiling Architecture) wurde ein Standard
entwickelt, der in Java 5 als Java
Virtual Maschine Tool Interface (JVM-
TI) eingegangen ist. JVMTI basiert auf
dem Agenten-Konzept von JVMPI, sodass
auch hier ein C- oder C++-Agent
entwickelt werden muss, der sich dann
für bestimmte Events registrieren und
Funktionen der JVM steuern kann. Eine
weitere, sehr interessante Erweiterung
von JVMTI ist, dass der Inhalt einer Klasse
nicht mehr nur zur Ladezeit verändert
werden kann, sondern auch dynamisch
zu einem späteren Zeitpunkt des Lebenszyklus
einer Klasse.
Die Events von JVMPI und JVMTI
liefern die benötigten Daten, um Performance,
Speicher, Threading- und Gar-
bage-Collection-Probleme im Detail zu
analysieren. Das ist auch der Grund, wa-
rum Java Profiling und Memory Debugger
fast ausschließlich auf Basis dieses
Agentenkonzepts funktionieren. Der hohe
Detailgrad hat aber seinen Preis und resultiert
in einem Performance Overhead,
der zu groß ist, um diese Tools in Produktion
oder Lasttestumgebungen in vollem
Umfang einzusetzen. Monitoring und Diagnose-Tools,
die mit geringem Overhead
arbeiten, nutzen daher in der Regel eine
Form der Bytecode-Instrumentierung für
die Erfassung von Laufzeitdaten.
Bytecode-Instrumentierung
Mit Bytecode-Instrumentierung werden
die Techniken zur nachträglichen Veränderung
des compilierten Bytecodes
einer Java-Anwendung bezeichnet. Performance
Tools nutzen diese Technik,
um den eigentlichen Messcode in den
bestehenden Applikationscode einzufügen.
Mithilfe von Libraries wie der
Apache Byte Code Engineering Library
(BCEL) [1] wird der bestehende Bytecode
analysiert und dann ein neuer Bytecode
Sonderdruck