Freigeben über


Containerisieren Ihrer Java-Anwendungen

Dieser Artikel enthält eine Übersicht über empfohlene Strategien und Einstellungen für die Containerisierung von Java-Anwendungen.

Berücksichtigen Sie bei der Containerisierung einer Java-Anwendung sorgfältig, wie viel CPU-Zeit der Container verfügbar ist. Überlegen Sie dann, wie viel Arbeitsspeicher sowohl im Hinblick auf die Gesamtspeichermenge als auch die Heap-Größe des virtuellen Java-Computers (JVM) verfügbar ist. In containerisierten Umgebungen haben Anwendungen möglicherweise Zugriff auf alle Prozessoren und können daher mehrere Threads parallel ausführen. Es ist jedoch üblich, dass Container über ein CPU-Kontingent verfügen, das den Zugriff auf CPUs möglicherweise drosselt.

Die JVM verfügt über Heuristiken, um die Anzahl der "verfügbaren Prozessoren" basierend auf dem CPU-Kontingent zu bestimmen, was die Leistung von Java-Anwendungen erheblich beeinflussen kann. Der dem Container zugewiesene Speicher und die Größe des Heapbereichs für das JVM sind ebenso wichtig wie die Prozessoren. Diese Faktoren bestimmen das Verhalten des Garbage Collector (GC) und die Gesamtleistung des Systems.

Containerisieren einer neuen Anwendung

Wenn Sie eine Java-Workload für eine neue Anwendung containern, müssen Sie zwei Dinge berücksichtigen, wenn Sie über Arbeitsspeicher nachdenken:

  • Der dem Container zugeordnete Speicher selbst.
  • Die Für den Java-Prozess verfügbare Arbeitsspeichermenge.

Grundlegendes zu JVM-Standard-Ergonomie

Anwendungen benötigen einen Ausgangspunkt und Einstellungen. Das JVM verfügt über Standard-Ergonomie mit vordefinierten Werten, die auf der Anzahl der verfügbaren Prozessoren und der Menge des Arbeitsspeichers im System basieren. Die in den folgenden Tabellen gezeigten Standardwerte werden verwendet, wenn das JVM ohne bestimmte Startflags oder Parameter gestartet wird.

Die folgende Tabelle zeigt die Standard-GC, die für die verfügbaren Ressourcen verwendet wird:

Verfügbare Ressourcen Standard-GC
Beliebig viele Prozessoren
Bis zu 1791 MB Arbeitsspeicher
SerialGC
2+ Prozessoren
1792 MB oder mehr Arbeitsspeicher
G1GC

Die folgende Tabelle zeigt die standardmäßige maximale Heap-Größe, je nachdem, wie viel Arbeitsspeicher in der Umgebung verfügbar ist, in der der JVM ausgeführt wird:

Verfügbarer Arbeitsspeicher Standardmäßige maximale Heapgröße
Bis zu 256 MB 50 % des verfügbaren Arbeitsspeichers
256 MB bis 512 MB ~127 MB
Mehr als 512 MB 25 % des verfügbaren Arbeitsspeichers

Die standardmäßige anfängliche Heapgröße beträgt 1/64 des verfügbaren Arbeitsspeichers.

Diese Werte gelten für OpenJDK 11 und höher und für die meisten Verteilungen, einschließlich Microsoft Build of OpenJDK, Azul Zulu, Eclipse Temurin, Oracle OpenJDK und anderen.

Bestimmen des Containerspeichers

Wählen Sie einen Containerspeicherbetrag aus, der Ihrer Arbeitslast am besten entspricht, abhängig von den Anforderungen Ihrer Anwendung und den charakteristischen Verwendungsmustern. Wenn Ihre Anwendung beispielsweise große Objektdiagramme erstellt, benötigen Sie wahrscheinlich mehr Arbeitsspeicher als für Anwendungen mit vielen kleinen Objektdiagrammen.

Tipp

Wenn Sie nicht wissen, wie viel Arbeitsspeicher zugewiesen werden soll, ist ein guter Ausgangspunkt 4 GB.

Ermitteln des JVM-Heapspeichers

Beachten Sie beim Zuweisen des JVM-Heapspeichers, dass der JVM mehr Speicher benötigt als nur das, was für den JVM-Heap verwendet wird. Wenn Sie den maximalen JVM-Heapspeicher festlegen, sollte er niemals der Menge des Containerspeichers entsprechen, da dies zu Fehlern im Container außerhalb des Arbeitsspeichers (Out of Memory, OOM) und Containerabstürzen führt.

Tipp

Weisen Sie 75 % des Containerspeichers für den JVM-Heap zu.

Auf OpenJDK 11 und höher können Sie die JVM-Heapgröße auf folgende Weise festlegen:

Beschreibung Flag Beispiele
Fester Wert -Xmx -Xmx4g
Dynamischer Wert -XX:MaxRAMPercentage -XX:MaxRAMPercentage=75

Minimale/anfängliche Heapgröße

Wenn die Umgebung garantiert einen bestimmten Speicherplatz für eine JVM-Instanz reserviert hat, z. B. in einem Container, sollten Sie die minimale Heap-Größe ( oder die anfängliche Heap-Größe ) auf dieselbe Größe wie die maximale Heapgröße festlegen. Diese Einstellung gibt dem JVM an, dass er nicht die Aufgabe ausführen sollte, Arbeitsspeicher auf das Betriebssystem freizugeben.

Verwenden Sie -Xms zum Festlegen einer mindesten Heap-Größe absolute Beträge oder -XX:InitialRAMPercentage prozentuale Beträge.

Wichtig

Das Kennzeichen -XX:MinRAMPercentagewird trotz des Namens verwendet, um den standardmäßigen maximalen RAM-Prozentsatz für Systeme mit bis zu 256 MB RAM festzulegen, der im System verfügbar ist.

Diagramm mit der Standardhapgröße auf OpenJDK 17.

Bestimmen der zu verwendenden GC

Zuvor haben Sie die Menge des JVM-Heapspeichers festgelegt, mit dem sie beginnen soll. Der nächste Schritt besteht darin, Ihre GC auszuwählen. Die Menge an maximalem JVM-Heap-Speicher, den Sie haben, ist häufig ein Faktor bei der Auswahl Ihrer GC. In der folgenden Tabelle werden die Merkmale der einzelnen GC-Elemente beschrieben.

Faktoren SerialGC ParallelGC G1GC ZGC ShenandoahGC
Anzahl von Kernen 1 2 2 2 2
Multithreading No Ja Ja Ja Ja
Java-Heapgröße <4 GByte <4 GByte >4 GByte >4 GByte >4 GByte
Anhalten Ja Ja Ja Ja (<1 ms) Ja (<10 ms)
Gemeinkosten Mindestens Mindestens Mittel Mittel Mittel
Effekt der Taillatenz High High Hoch Niedrig Moderat
JDK-Version All Alle JDK 8+ JDK 17+ JDK 11+
Am besten geeignet für Einzelner Kern kleiner Heaps Multikernige kleine Heaps oder Batchworkloads mit jeder Heapgröße Reaktionsfähig in mittelgroßen bis großen Heaps (Anforderungsantwort-/DB-Interaktionen) Reaktionsfähig in mittelgroßen bis großen Heaps (Anforderungsantwort-/DB-Interaktionen) Reaktionsfähig in mittelgroßen bis großen Heaps (Anforderungsantwort-/DB-Interaktionen)

Tipp

Für die meisten allgemeinen Microservice-Anwendungen beginnen Sie mit der Parallel GC.

Ermitteln, wie viele CPU-Kerne benötigt werden

Für jede andere GC als SerialGC empfehlen wir zwei oder mehr vCPU-Kerne – oder mindestens 2000m cpu_limit auf Kubernetes. Es wird nicht empfohlen, etwas weniger als 1 vCPU-Kern in containerisierten Umgebungen auszuwählen.

Tipp

Wenn Sie nicht wissen, mit wie vielen Kernen sie beginnen sollen, ist eine gute Wahl 2 vCPU-Kerne.

Auswählen eines Ausgangspunkts

Es wird empfohlen, mit zwei Replikaten oder Instanzen in Container-Orchestrierungsumgebungen wie Kubernetes, OpenShift, Azure Spring Apps, Azure Container Apps und Azure-App Service zu beginnen. In der folgenden Tabelle sind die empfohlenen Ausgangspunkte für die Containerisierung Ihrer neuen Java-Anwendung zusammengefasst.

vCPU-Kerne Containerspeicher JVM-Heapgröße GC Replikate
2 4 GB 75% ParallelGC 2

Die zu verwendenden JVM-Parameter lauten wie folgt: -XX:+UseParallelGC -XX:MaxRAMPercentage=75

Containerisieren einer vorhandenen (lokalen) Anwendung

Wenn Ihre Anwendung bereits lokal oder auf einem virtuellen Computer in der Cloud ausgeführt wird, sollten Sie mit folgendem Verfahren beginnen:

  • Die gleiche Arbeitsspeichermenge, auf die die Anwendung derzeit Zugriff hat.
  • Die gleiche Anzahl von CPUs (vCPU-Kernen), die die Anwendung derzeit zur Verfügung hat.
  • Dieselben JVM-Parameter, die Sie derzeit verwenden.

Wenn die vCPU-Kerne und/oder die Containerspeicherkombination nicht verfügbar ist, wählen Sie den nächstgelegenen Kern aus, um die vCPU-Kerne und den Containerspeicher aufzurunden.

Nächste Schritte

Nachdem Sie nun die allgemeinen Empfehlungen für die Containerisierung von Java-Anwendungen verstanden haben, fahren Sie mit dem folgenden Artikel fort, um einen Containerisierungsbasisplan einzurichten: