Welche Konfigurationsoptimierungen für die JVM-Garbage-Collection sind für hochperformante Microservices in Kubernetes-Containern unter Berücksichtigung von Cgroup-Limits notwendig?

Die JVM muss in Kubernetes-Umgebungen die Cgroup-Limits präzise erkennen, um Out-of-Memory (OOM) Kills durch den Kernel zu vermeiden. Wir setzen primär auf die Container-Awareness der JVM (ab Java 10+), wobei die Steuerung des Heaps über prozentuale Werte anstelle von fixen Megabyte-Angaben erfolgt. Dies stellt sicher, dass die JVM bei einer Änderung der Kubernetes-Resource-Limits ohne Anpassung der Startparameter korrekt skaliert.

Für hochperformante Microservices konfigurieren wir den G1-Garbage-Collector mit spezifischen Parametern, um die Stop-the-World-Phasen zu minimieren. Ein zentraler Hebel ist -XX:MaxGCPauseMillis, den wir je nach Service-Level-Agreement (SLA) auf 100-200ms setzen. Um die Effizienz zu steigern, optimieren wir den Startzeitpunkt des Concurrent Marking Cycle über -XX:InitiatingHeapOccupancyPercent.

Die Abstimmung dieser Parameter ist Teil unserer IT-Consulting & Digitale Strategie, da die GC-Konfiguration direkt mit den Kubernetes-Resource-Requests und -Limits korrelieren muss. Wenn Requests und Limits identisch gesetzt sind (Guaranteed QoS Class), reduzieren wir die Heap-Varianz, um Jitter zu vermeiden.

Bei der Nutzung von ZGC oder Shenandoah ist zu beachten, dass diese Collector mehr CPU-Ressourcen für das concurrent Marking beanspruchen. Wir erhöhen in diesen Fällen die CPU-Limits, um Performance-Einbußen im Application-Thread zu verhindern. Zudem deaktivieren wir in hochlastkritischen Szenarien die Swap-Nutzung auf Node-Ebene, da dies die GC-Pausenzeiten unvorhersehbar verlängern kann.

Wir empfehlen für moderne Microservices den konsequenten Einsatz von ZGC in Kombination mit identischen CPU- und Memory-Requests/Limits, da nur so die Vorhersehbarkeit der Latenzzeiten in einer dynamischen Container-Umgebung garantiert werden kann.