Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
0800 1 255 255

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 ermitteln

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)

Red Hat Enterprise Linux 4 inclu­des 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

Related Posts

Pin It on Pinterest