Feintuning der Speicherbelegung von Java-Programmen mit visualgc
Seite 3: Beispielanwendung
Eigene Versuche
Im Folgenden geht es um das Optimieren einer Applikation, in deren Code man nicht eingreifen kann, durch eine visualgc-Analyse. Gezeigt sei das aus Gründen der Einfachheit und der allgemeinen Verfügbarkeit der Testapplikation an der in Java geschriebenen Telnet-Anwendung Kava, die einen ASCII-Art-Stream abspielen soll, um etwas Last zu erzeugen. Die damit gesammelte Erfahrung lässt sich eins zu eins auf beliebige Java-Programme übertragen.
Man startet die Applikation und visualgc mit folgenden Befehlen:
java -verbose:gc -jar jta-1.1.jar towel.blinkenlights.nl
/opt/jvmstat/bin/visualgc $!
Ein Blick über visualgc und das geschwätzig ("verbose") eingestellte GC-Logging zeigt, dass der Default-Wert von 64 MByte Speicher für einen flüssigen Ablauf viel zu wenig ist. Während der Spielzeit des Streams sind 320 GCs fällig, der Prozess stoppt für insgesamt 700 ms. Eine Erhöhung des Heap bringt mehr Ruhe in den Programmablauf. Da die Anwendung offensichtlich den Survivor-Bereich nicht nutzt, kann man die Aufteilung des Young-Generation-Bereichs zugunsten des Eden Space verändern (beispielsweise -XX:SurvivorRatio=36. Alternativ lässt sich mit dem Schalter -client) der Speicherbereich des Perm-Speichers begrenzen. Durch weitere Analysen und Variationen anderer Parameter (Verwendung der parallelen Garbage Collection sowie 128 MByte Speicher für Xms und Xmx) kommt man letztlich zu 80 ms Stoppzeit bei nur 16 GCs.
Remote-Kontrolle
Wer mit visualgc das Verhalten eines Applikationsservers wie Tomcat oder GlassFish untersuchen will, findet dort nur selten ein X-Terminal angeschlossen. Einen X-Server benötigt man, wenn visualgc unter Unix gestartet wird. Unter Umständen kann man visualgc "remote" via ssh auf dem Server starten und die X-Ausgabe auf den lokalen Rechner umlenken. Es waren jedoch Speicherfehler im lokalen X-Server zu beobachten; nach spätestens 24 Stunden belegte er sowohl unter Solaris als auch unter Linux nahezu den gesamten Hauptspeicher, sodass ein Neustart notwendig war.
Der Cygwin-X-Server unter Windows lief wesentlich robuster und hielt fast eine Woche durch, bevor Speicherprobleme auftraten. Mit dem Programm jstatd, Bestandteil der Java Standard Edition (Java SE), liefert Sun ein Tool aus, das "Remote Method Invocation"-Informationen (RMI) lokaler Java-Anwendungen via TCP-Port 1098 und 1099 im Netz zur Verfügung stellt. Damit kann man unter anderem visualgc auf einem lokalen Rechner starten und die Daten einer "remote" laufenden VM anzeigen. Voraussetzung hierfür ist, dass eine eventuell vorhandene Firewall die von jstatd genutzte RMI-Kommunikation erlaubt.
Laufen visualgc und die zu beobachtende Applikation auf demselben Rechner wird visualgc beim Start die Prozess-ID (PID) angegeben. Bei der Verwendung von jstatd ist als Parameter für visualgc "PID@Applikationsserver" anzugeben. Einen kritischen Punkt stellen die Zugriffsrechte auf eine per RMI erreichbare VM dar. Um Missbrauch zu verhindern, sollte eine Konfigurationsdatei den RMI-Zugriff einschränken. Wie man beispielhaft den Remote-Rechner "lyra" konfiguriert und visualgc lokal auf "cassiopeia" startet, zeigt die folgende Codepassage:
nobody@lyra: cat /opt/jvmstat/etc/jstatd.all.policy
grant codebase "file:${java.home}/../lib/tools.jar" {
permission java.security.AllPermission;
};
nobody@lyra: jstatd -J-Djava.security.policy=
/opt/jvmstat/etc/jstatd.all.policy
renner@cassiopeia: jps -l lyra.example.net
3002 /opt/j2sdk1.5.0/demo/jfc/Java2D/Java2Demo.JAR
2857 sun.tools.jstatd.jstatd
renner@cassiopeia: /opt/jvmstat/bin/visualgc 3002@lyra.example.net
Fazit
Obwohl Java von Version zu Version ein besseres Laufzeitverhalten bietet, lässt sich mit händischem Tuning der Aufrufparameter die Performance um bis zu zehn Prozent steigern. Mit visualgc lassen sich die dafür nötigen Laufzeitparameter ohne Eingriffe in den Code ermitteln.
Nach einem Update auf eine andere Java-Version ist es ratsam zu prüfen, ob sich das Tempo durch neue Optionen erhöhen lässt. Weitere Tools aus dem Hause Sun (etwa JConsole und der NetBeans Profiler) bieten zusätzliche, jedoch schwieriger zu verstehende Einblicke in die Tiefen der JVM. Weiterführende Informationen zur Optimierung der GC finden sich im Artikel "Tuning Garbage Collection with the 5.0 Java Virtual Machine".
Christian Pemsl und Michael Renner
administrieren unterschiedliche Applikationsserver (ATG Dynamo, Sun, Tomcat, WebSphere, WebLogic) in einer großen Direktbank. Performance und Verfügbarkeit stehen dabei im Vordergund.
