JVM-Heap und Garbage Collection

Status: HotSpot-Teil verifiziert (echte jcmd-Ausgaben gegen den laufenden Liberty-Prozess). IBM-Semeru/OpenJ9-Teil dokumentiert, nicht live verifizierbar (kein Semeru in dieser Umgebung installiert) — siehe Begründung unten, warum das trotzdem der wichtigere Teil für den echten WAS-Alltag ist.

Zwei völlig unterschiedliche JVM-Welten

Der in der Anzeige genannte Punkt "Java Heap, Garbage Collection" klingt nach generischem Java-Wissen — ist es in einer echten WebSphere-Umgebung aber nicht. Siehe docs/00-ueberblick/systemlandschaft.md: kommerzielles WebSphere Liberty läuft in IBM-Shops meist auf IBM Semeru Runtime (OpenJ9), Open Liberty (wie hier verwendet) läuft häufig auf HotSpot (Temurin o. ä.). Beide haben komplett andere GC-Policies, Flags und Diagnose-Tools:

Wer nur HotSpot-Tuning kennt und in ein IBM-Semeru-basiertes WAS-Liberty geht, greift ins Leere — die Flags heißen anders, die Heuristiken sind anders, sogar die Log-Formate sind inkompatibel. Das ist der wichtigste Punkt dieses Kapitels, wichtiger als die einzelnen Kommandos.

HotSpot: hier real gemessen

Server unter Last (normaler Web-Traffic aus den vorherigen Verifikationsschritten) via jcmd untersucht (PID über jps -l ermittelt, siehe 02-heap-und-thread-dumps.md für den vollen Befehlsablauf):

$ jcmd <pid> VM.version
OpenJDK 64-Bit Server VM version 21.0.11+10-LTS

$ jcmd <pid> GC.heap_info
 garbage-first heap   total 69632K, used 50262K [0x0000000602c00000, 0x0000000800000000)
  region size 4096K, 7 young (28672K), 1 survivors (4096K)
 Metaspace       used 45298K, committed 47296K, reserved 1114112K
  class space    used 4739K, committed 5504K, reserved 1048576K

Einordnung:

• G1GC ist HotSpots Default seit Java 9 — Liberty erzwingt hier keine eigene GC-Wahl, es gilt schlicht der JVM-Default. Für einen produktiven Liberty-Server würde man das trotzdem explizit setzen (-XX:+UseG1GC oder bewusst -XX:+UseZGC für sehr große Heaps/niedrige Pausenzeiten), statt sich auf den JDK-Default zu verlassen, der sich zwischen JDK-Versionen ändern kann.
• Metaspace (45 MB) ist bereits größer als der aktuell genutzte Heap (50 MB von 69 MB total) — bei einer Liberty-Instanz mit vielen Features/Bundles ist das normal (OSGi- Klassen-Overhead), aber ein Wert, den man im Blick behalten sollte: unbegrenzte Metaspace (-XX:MaxMetaspaceSize nicht gesetzt) kann bei Class-Loader-Lecks (z. B. wiederholtes Hot-Deployment ohne sauberen Undeploy) unbemerkt wachsen.

Wo -Xms/-Xmx bei Liberty gesetzt werden

Nicht in server.xml, sondern in jvm.options im selben Server-Verzeichnis (usr/servers/<name>/jvm.options, eine Zeile pro Flag):

-Xms512m
-Xmx1024m
-XX:+UseG1GC
-Xlog:gc*:file=logs/gc.log:time,uptime:filecount=5,filesize=10M

Bewusst nicht in diesem Projekt fest eingerichtet (kein jvm.options eingecheckt) — die richtige Größe hängt von echter Lastmessung ab, nicht von einem Lernprojekt-Default; siehe 03-thread-und-connection-pool-tuning.md für dieselbe Überlegung bei Pools.

IBM Semeru/OpenJ9: gencon und die Alternativen (dokumentiert)

Für den Fall, dass die reale Zielumgebung IBM Semeru nutzt (siehe Tabelle oben), die wichtigsten Policies zum Wiedererkennen im Gespräch:

• gencon (Default): generationelles Konzept ähnlich G1, aber mit anderer interner Umsetzung (Nursery/Tenured statt Regionen) — für die meisten Web-Workloads der richtige Startpunkt.
• optthruput: kein Nursery/Generationen-Modell, optimiert auf maximalen Durchsatz, akzeptiert dafür längere/unvorhersehbarere Pausen — für Batch-lastige Hintergrundverarbeitung gedacht, nicht für interaktive Web-Anwendungen.
• optavgpause: Gegenteil von optthruput — minimiert Pausenzeiten auf Kosten von Durchsatz, für latenzkritische interaktive Anwendungen.
• balanced: regionsbasiert (dem HotSpot-G1-Modell konzeptionell am ähnlichsten), gedacht für sehr große Heaps (mehrere hundert GB).
• metronome: Soft-Realtime-GC mit sehr vorhersehbaren, kurzen Pausen — Nischenfall.

Gesetzt über -Xgcpolicy:gencon (o. ä.) in derselben jvm.options-Datei wie oben — die Flag-Position (Datei) ist identisch zwischen HotSpot und Semeru, nur der Inhalt der Flags unterscheidet sich.

Weiter mit 02-heap-und-thread-dumps.md für die konkrete Dump-Analyse und 03-thread-und-connection-pool-tuning.md für Pool-Tuning.