Eine JVM in einem Container dimensionieren: Heap-Prozentsatz, Non-Heap-Speicher und CPU-Anzahl

Ziel

Eine Container-Speichergrenze, die die JVM nicht überschreitet, und ein Heap, der gross genug ist, dass der Collector nicht ständig läuft – beides aus Messwerten abgeleitet statt aus übernommenen Zahlen.

Voraussetzungen

Ein JDK mit Container-Unterstützung (die Java-Referenz beschreibt sie als nur unter Linux verfügbar und standardmässig aktiviert, abschaltbar mit -XX:-UseContainerSupport), Zugriff auf die cgroup-Speichergrenze und das CPU-Kontingent des Containers sowie eine Möglichkeit, den Dienst unter realistischer Last laufen zu lassen.

Schritte

1. Prüfen, was die JVM sieht: mit -Xlog:os+container=info starten (die Referenz nennt trace für maximale Detailtiefe) und die gemeldete Speichergrenze sowie Prozessorenzahl ablesen. -XX:ActiveProcessorCount=n überschreibt die CPU-Zahl, wenn Kontingente irreführen; die Referenz hält fest, dass dieses Flag auch ohne Container-Unterstützung beachtet wird.
2. Einen Heap-Prozentsatz statt einer festen Grösse wählen: -XX:MaxRAMPercentage (Standard 25 Prozent des dem Prozess verfügbaren Speichers) und -XX:InitialRAMPercentage (Standard 1,5625 Prozent) skalieren mit der Grenze, sodass ein Image in einem 1-GB- und einem 4-GB-Container funktioniert. Ein festes -Xmx überschreitet eine kleinere Grenze stillschweigend.
3. Den Non-Heap-Speicher budgetieren, den der Prozentsatz freihalten muss: Klassenmetadaten (standardmässig unbegrenzt; -XX:MaxMetaspaceSize begrenzt sie), einen Stack pro Thread (-Xss, laut Referenz standardmässig 1024 KB unter Linux/x64), Direct Byte Buffers (-XX:MaxDirectMemorySize), den JIT-Code-Cache, GC-Datenstrukturen und native Bibliotheken. Das eigene Beispiel der Referenz setzt -XX:MaxRAMPercentage=75; welcher Prozentsatz auch gewählt wird, ist eine in Schritt 4 zu prüfende Hypothese, kein bekannt sicherer Wert.
4. Den gesamten Prozess messen: unter Last mit -XX:NativeMemoryTracking=summary und jcmd <pid> VM.native_memory summary laufen lassen, dann den committeten Gesamtwert mit der Container-Grenze und mit dem eigenen Speicherzähler der cgroup vergleichen.
5. Die Container-Grenze auf den gemessenen Spitzenwert plus Puffer setzen, oder den Heap-Prozentsatz senken, bis der Spitzenwert passt. Nie nur für den Heap allein budgetieren.
6. Die Wahl des Collectors erneut prüfen: Das Ergonomie-Kapitel wählt Serial GC unter zwei Prozessoren, sodass ein Container mit einer CPU einen einzelnen Collector-Thread fährt, sofern nicht bewusst -XX:+UseG1GC angegeben wird.
7. Grenze, Prozentsatz, CPU-Anzahl und gemessenen Spitzenwert neben dem Deployment-Manifest festhalten.

Erwartetes Ergebnis

Der Prozess bleibt mit stabiler residenter Grösse unter seiner Grenze, GC-Logs zeigen einen Heap, der bis zu seiner Obergrenze wächst, ohne ständige vollständige Collections, und eine Änderung der Container-Grösse verändert den Heap proportional, ohne ein neues Image.

Grenzen und Prüfbasis

Prozentsätze ergeben in sehr kleinen Containern unerwartet kleine Heaps; die Referenz dokumentiert -XX:MinRAMPercentage (Standard 50 Prozent) für Heaps von rund 125 MB. Verbraucher ausserhalb des Heaps wie Netzwerkpuffer oder Memory-Mapped-Dateien fallen nicht unter die Buchführung der JVM; der cgroup-Zähler ist die letzte Instanz. Hier wird nur das Vorgehen vorgeschlagen; für keine Arbeitslast werden konkrete Grössen behauptet.