Wir führen mehrere Java-Dienste (Corretto JDK21) auf AWS Elastic Container Service (ECS) Fargate aus. Jeder Dienst hat seinen eigenen Container und wir möchten alle möglichen Ressourcen nutzen, die wir für jeden Prozess bezahlen. Die Schritte können jedoch auf EC2 und andere Clouds angewendet werden.

Dienste führen Batch-Jobs aus und die Latenz spielt keine Rolle. Wir verwenden Parallel GC (-XX: UseParallelGC). Vielleicht wäre G1 sogar mit unseren Aufgaben besser, aber es ist ein Thema für separate Recherche und Veröffentlichung.
Um den gesamten verfügbaren Speicher zu nutzen, ist MaxHeapSize etwas kleiner als die Containerspeichergröße. Aber nach einiger Zeit bemerkten wir zwei Probleme: Manchmal wurden unsere Container getötet, weil sie zu viel Speicher verbrauchen, und manchmal erhielten wir OutOfMemoryError-Ausnahmen. Um das erste Problem zu beheben, vergrößerten wir die Lücke zwischen der Containerspeichergröße und MaxHeapSize und für das zweite Problem erhöhten wir als schnelle Lösung den Speicher der Container und begannen, uns mit Heap-Dumps zu befassen.

Heap-Dumps zeigten interessante Details, die tatsächliche Heap-Größe war kleiner als MaxHeapSize und der Heap der jungen Generation war im Vergleich zur alten Generation winzig.

Die Suche im Internet hat nicht geholfen, eine gute Anleitung zum Optimieren von JVM-Parametern für unseren Fall zu finden. Ich habe nur einige allgemeine Details zu Heaps und Parameterbeschreibungen gefunden. Ich habe beschlossen, diesen Beitrag zu schreiben, um die von mir durchgeführten Schritte zu beschreiben.

Die ersten Schritte waren:

• Informationen zu Parametern und Standardwerten drucken: (-XX: PrintFlagsFinal),
• Setzen Sie InitialHeapSize auf den gleichen Wert wie MaxHeapSize (-XX:InitialRAMPercentage=100 oder setzen Sie einfach -XX:InitialHeapSize auf den gleichen Wert wie MaxHeapSize). Wir zahlen sowieso für den gesamten Containerspeicher, warum also nicht gleich zu Beginn zuweisen?
• Log-GC- und Heap-Informationen (-Xlog:gc*).

Die Standardrate für junge: alte Generationen beträgt 1:2, und nur ein Teil der jungen Generation wird gleichzeitig für die Durchführung von GC verwendet. Und nach dem Start hat die JVM wie erwartet den gesamten Speicher zugewiesen, aber nach einiger Zeit begann sie, die Heap-Größe der jungen Generation fast auf mehrere Megabyte zu verringern. Nach einiger Zeit haben wir also nur noch ⅔ des verfügbaren Speichers verbraucht.
Nach einigem Suchen habe ich einen Parameter zum Deaktivieren der Adaptive Policy (-XX:-UseAdaptiveSizePolicy) gefunden, der geholfen hat: Der Heap-Speicher hat sich nicht mehr verringert und die Intervalle zwischen den Garbage Collections haben sich um eine Größenordnung oder sogar mehr erhöht. Die von GC verbrauchte Zeit nahm ebenfalls zu, aber nicht so stark.

Der nächste Schritt bestand darin, die optimale Lücke zwischen der Speichergröße des Containers zu finden. Selbst wenn InitialRAMPercentage=100 ist, weist das JDK standardmäßig nur Speicher zu und verwendet ihn nicht, sodass er nicht zugeordnet wird. Linux ermöglicht es, mehr virtuellen Speicher zuzuweisen, als physischer Speicher vorhanden ist. Und der Container schlägt später fehl, wenn der Speicher tatsächlich zugeordnet ist (JDK schreibt darauf). -XX: AlwaysPreTouch ändert dieses Verhalten. Leider ist ein Teil des Speichers immer noch nicht zugeordnet, aber die OOM-Beendigung erfolgt viel schneller. Nach mehreren Versuchen endete ich mit der nächsten Formel „Containerspeichergröße“ – 1024 MB für Container mit 8 GB Speicher oder mehr. Für eine Containerspeichergröße von 8192 verwenden wir beispielsweise -XX:MaxHeapSize=7168m.

Für weitere Optimierungen denken wir darüber nach, -XX:NewRatio zu ändern, um die Größe der jungen Generation zu verringern und die GC-Zeit zu verkürzen. Dies hängt jedoch von der Lebensdauer des Objekts in der Anwendung ab.
Wie ich bereits erwähnt habe, habe ich keine gute Anleitung mit ausführlicher Erklärung der Parameter (die beste, die ich gefunden habe, ist vm-options-explorer) und Optimierungsschritte gefunden. Es wäre großartig, wenn Sie Ihr Wissen und Ihre Ergebnisse teilen könnten.