← Zur Uebersicht
docs/20-monitoring-tuning/02-heap-und-thread-dumps.md

Heap- und Thread-Dumps ziehen und lesen

Status: verifiziert — echter Thread-Dump gegen den laufenden concordiaPortalServer gezogen, sowohl über Liberty-Bordmittel (server javadump) als auch über jcmd (HotSpot).

Zwei Wege, an einen Thread-Dump zu kommen

1. Liberty-Bordmittel (funktioniert unabhängig von der JVM-Wahl)

cd concordia-portal/target/liberty/wlp/bin
./server javadump concordiaPortalServer

Reale Ausgabe:

Speicherauszug für Server concordiaPortalServer wird erstellt.
Der Speicherauszug des Servers concordiaPortalServer in
.../concordiaPortalServer/javadump.20260817.221047.26180.0001.txt ist abgeschlossen.

Das erzeugt eine Textdatei mit vollständigem Thread-Dump (813 Zeilen in unserem Testlauf) — der Weg, der auf jeder Liberty-Installation funktioniert, egal ob darunter HotSpot oder IBM Semeru läuft. Das ist der Grund, warum ein WAS-Admin diesen Befehl statt eines JVM-spezifischen Tools als ersten Reflex kennen sollte.

2. jcmd (HotSpot-spezifisch, hier verwendet)

jps -l                    # PID der Liberty-JVM finden (ws-server.jar)
jcmd <pid> Thread.print   # Thread-Dump direkt in die Konsole
jcmd <pid> GC.heap_info   # Heap-Zusammenfassung, siehe 01-jvm-heap-und-gc.md

Auf IBM Semeru/OpenJ9 wäre das Äquivalent jcmd <pid> Dump.java bzw. das Setzen eines Signal-Handlers für kill -3 — jcmd selbst existiert dort auch, aber nicht alle Subcommands sind identisch, siehe 01-jvm-heap-und-gc.md für die grundsätzliche Werkzeug-Tabelle.

Was im echten Thread-Dump zu sehen war

53 Threads insgesamt, davon 16 im Liberty-Default Executor-Pool aktiv (Namen Default Executor-thread-N). Beispiel-Eintrag:

"Default Executor-thread-5" #57 [9932] daemon prio=5 os_prio=0 cpu=203.12ms elapsed=98.34s
   java.lang.Thread.State: WAITING (on object monitor)

WAITING (on object monitor) bei einem Pool-Thread ist der Normalzustand — der Thread wartet im Pool auf die nächste Aufgabe, das ist kein Problem. Ein Warnsignal wäre stattdessen viele Threads gleichzeitig im Zustand RUNNABLE mit demselben Stacktrace (deutet auf einen Hotspot/Bottleneck hin) oder BLOCKED (deutet auf Lock-Contention/Deadlock-Verdacht hin) — siehe docs/30-troubleshooting-runbooks/ für konkrete Runbooks zu diesen Mustern.

Heap-Dump (Hinweis, nicht in diesem Projekt gezogen)

Ein vollständiger Heap-Dump (jcmd <pid> GC.heap_dump <datei>.hprof bei HotSpot bzw. automatisch bei OutOfMemoryError mit -XX:+HeapDumpOnOutOfMemoryError) wurde hier bewusst nicht gezogen — bei einem gesunden, kaum ausgelasteten Dev-Server liefert er keine aussagekräftigen Daten, und die Datei kann je nach Heap-Größe sehr groß werden. Der Befehl selbst ist aber derselbe Grundgedanke wie bei server javadump: ein Snapshot-Kommando, das man vor einem Neustart/Incident-Response zieht, nicht erst danach.

⌂ Cockpit