Was tun bei OutOfMemory - Teil 2: Analyse

Nicht sel­ten kommt es vor, dass Speicherprobleme erst im Wirkbetrieb auf­tre­ten. Die Gründe dafür sind oft, dass das System nicht aus­rei­chend oder gar nicht unter rea­len Lastbedingungen getes­tet wurde.
Bei Systemen mit redak­tio­nel­len Inhalten (z. B. Content Management Systeme) ergibt sich aus der stei­gen­den Anzahl der Inhalte in Verbindung mit Abhängigkeiten und Caching  eine wach­sende Belastung. In der Testphase sind diese Inhalte in der Komplexität und Masse meist noch nicht verfügbar.

Wie bei vie­len ande­ren Problemen auch, kann man OutOfMemory in zwei Kategorien einteilen:

• Problem tritt regel­mä­ßig auf:  Das Problem tritt immer nach gewis­ser Zeit oder beim Aufruf gewis­ser Methoden auf. Diese Art von Fehler ist meist gut nach­stell­bar und im Algemeinen auch schnell beho­ben. Die Ursache sind meist Programmierfehler.
• Problem tritt spo­ra­disch auf: Das Problem tritt immer mal wie­der auf. Davor und danach läuft das System  wei­ter­ge­hend sta­bil. Hier ist extrem schwie­rig den Fehler nach­zu­stel­len und die Ursachen dafür ein­zu­gren­zen. Man sucht hier wort­wört­lich die Nadel im Heuhaufen.

Geraden für den Typ 2 ist ein struk­tu­rier­tes Vorgehen von gro­ßer Bedeutung. Es emp­fiehlt sich, ein Vorgehensmodel zu defi­nie­ren und zu doku­men­tie­ren. Bei neuen Erkenntnissen wird das Vorgehensmodel erwei­tert oder ggf. ange­passt. Für jeden Vorgehensschritt gibt es eine kon­krete Aufgabe, die ver­schie­dene Ergebnisse lie­fert. Dieses Vorgehen hat meh­rere Vorteile:

• Es gibt einen roten Faden: Die Komplexität ist meist sehr hoch. Wenn man nicht struk­tu­riert die Probleme angeht, läuft man Gefahr, sich zu verzetteln.
• Das Wissen kann bes­ser auf meh­rere Mitarbeiter ver­teilt wer­den: Sollte ein Mitarbeiter mal aus­fal­len (wegen Krankheit oder Urlaub) kön­nen andere Mitarbeiter diese Aufgabe übernehmen.
• Es gibt Material für das Management: Das Management kann sich oft nicht vor­stel­len, warum es so lange dau­ert, das Problem zu lösen. Über das Vorgehensmodel ist geklärt, wo wir uns befin­den, und was die nächs­ten Schritte sind. Über Entscheidungsvorlagen kön­nen wei­tere Budgets oder Termine abge­stimmt werden.

Hilfreich ist es auch, Probleme und Teilerfolge im Team zu dis­ku­tie­ren. Dazu müs­sen Vorgehen und Ergebnisse auch in ent­spre­chen­der Form auf­be­rei­tet werden.

Betriebskennzahlen ermit­teln

Prozess und Speicher

Im Teil 1 wurde bereits dar­ge­stellt, dass die Größe des maxi­ma­len Speichers für einen Prozess abhän­gig von dem Betriebssystem und der Hardware ist.
Anzeigen kann man den Speicher für einen Prozess unter Linux mit dem Kommando top.

top -p <PID>

Weiterhin kann auch fest­ge­stellt wer­den, wie viel Ressourcen über­haupt noch zur Verfügung ste­hen.
Um her­aus­zu­fin­den, wie viel Speicher ein Prozess maxi­mal ein­neh­men kann, benö­tigt man die genaue Kernel-Version und die Spezifikation des Betriebssystems.

uname -r (Linux)

• In Betriebssystemspezifikation nach­le­sen (z.B. bei RedHat) 

Red Hat Enterprise Linux 4 includes a ker­nel known as the huge­mem ker­nel.
This ker­nel sup­ports a 4GB per-process user space (ver­sus 3GB for the other ker­nels), and a 4GB direct ker­nel space. 

Java-Speicherverlauf über­wa­chen

• GC-Logging akti­vie­ren

JAVA_VM_ARGS="$JAVA_VM_ARGS -verbose:gc -Xloggc:var/logs/gc.log \
   -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC \
   -XX:+PrintTenuringDistribution"

• Auswerten der Datei var/logs/gc.log mit dem Tool HPjtune

• Kurz vor OutOfMemorykann durch GC kaum noch Speicher frei­ge­ge­ben werde
• das Systen ist prak­tisch nur noch mit GC beschäftigt

Tomcat-Monitoring
Über die Tomcat-Manager-Seiten kann der Tomcat über­wacht wer­den. Dafür muss ein Nutzer mit der Rolle manager in der Datei tomcat-users.xml existieren.

<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
...
<role rolename="admin"/>
<role rolename="manager"/>
<user username="admin" password="admin" roles="admin, manager"/>
...
</tomcat-users>

Tomcat Monitoring URL: http://HOST:PORT/manager/status?XML=true

<?xml version="1.0" encoding="utf-8"?>
<status>
<jvm>
<memory free='206.306.536' total='424.214.528' max='492.175.360'/>
</jvm>
...
</status>

Grafisch aus­ge­wer­tet wer­den kön­nen die Werte mit JMeter:

Speicherdumps aus­wer­ten

Oft fin­det man die Ursachen des Speicherproblems aber nur mit der Auswertung des Heapdumps. Zuerst muss man ein Heapdump erstel­len. Es emp­fiehlt sich, den Heap für die Analyse nicht zu groß zu wäh­len. Eine Analyse eines 2 GB Dumps ist schon sehr schwierig.

• Histogramm

   $JAVA_HOME/bin/jmap -histo <PID> > hist.txt

• Binary HeapDump (kom­plett)

  $JAVA_HOME/bin/jmap -heap:format=b <PID>

• Auswerten mit JHat (JDK 1.6)

  java -Xmx2048m -jar hat.jar ../java_pid27280.hprof
  Started HTTP server on port 7000
   Reading from ../java_pid27280.hprof...
   Dump file created Tue Nov 20 14:22:07 CET 2007

  die Auswertung kann dann web­ba­siert per Browser auf Port: 7000 erfolgen

• Auswerten mit dem SAP Memory Analyzer 
  • kos­ten­lo­ses Tool zum Analysieren von gro­ßen Memory Dumps
  • sehr schnelle (durch Indizierung)
  • sehr gute Analysemöglichkeiten
  • Bearbeitung gro­ßer Dumps
  • als Eclipse Plugin oder eigen­stän­dige Applikation (RPC-Framework)
  • Artikel im JavaMagazin (11/2007 S.105)
  • Download: https://wiki.sdn.sap.com/wiki/display/Java/Java+Memory+Analysis

Im gezeig­ten Beispiel war das Problem die Klasse BodyContentImpl des Tomcats (5) aller­dings durch feh­ler­hafte Benutzung in einer eige­nen Tag Library.

Links

• Was tun bei OutOfMemory – Teil 1: Grundlagen