Effizientes Verwenden von Arbeitsspeicher für Java-Apps in Azure Container Apps (Vorschau)

Artikel
03/06/2024

Die Java Virtual Machine (JVM) verwendet Speicher konservativ, da sie davon ausgeht, dass der Speicher des Betriebssystems zwischen mehreren Anwendungen aufgeteilt werden muss. Ihre Container-App kann jedoch die Speicherauslastung optimieren und die maximale Menge an Arbeitsspeicher für Ihre Anwendung verfügbar machen. Diese Speicheroptimierung wird als automatische Java-Speicheranpassung bezeichnet. Wenn die Speicheranpassung aktiviert ist, wird die Leistung von Java-Apps in der Regel um 10 bis 20 % verbessert, ohne dass Codeänderungen vorgenommen werden müssen.

Azure Container Apps bietet unter den folgenden Bedingungen eine automatische Speicheranpassung:

Eine einzelne Java-Anwendung wird in einem Container ausgeführt.
Ihre Anwendung wird aus dem Quellcode oder einer JAR-Datei bereitgestellt.

Die automatische Speicheranpassung ist standardmäßig aktiviert, sie können sie jedoch manuell deaktivieren.

Deaktivieren der Speicheranpassung

Die automatische Speicheranpassung ist in den meisten Szenarien hilfreich, möglicherweise aber nicht in allen Situationen ideal. Sie können die Speicheranpassung manuell oder automatisch deaktivieren.

Manuelles Deaktivieren

Um die Speicheranpassung beim Erstellen Ihrer Container-App zu deaktivieren, legen Sie die Umgebungsvariable BP_JVM_FIT auf false fest.

In den folgenden Beispielen wird gezeigt, wie Sie die Befehle create, up und update verwenden, um die Speicheranpassung zu deaktivieren.

az containerapp create \
  --name <CONTAINER_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --image <CONTAINER_IMAGE_LOCATION> \
  --environment <ENVIRONMENT_NAME> \
  --env-vars BP_JVM_FIT="false"

az containerapp up \ 
  --name <CONTAINER_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --image <CONTAINER_IMAGE_LOCATION> \
  --environment <ENVIRONMENT_NAME> \
  --env-vars BP_JVM_FIT="false"

az containerapp update \
  --name <CONTAINER_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --image <CONTAINER_IMAGE_LOCATION>  \
  --set-env-vars BP_JVM_FIT="false"

Hinweis

Die Container-App wird neu gestartet, wenn Sie den Befehl update ausführen.

Um zu überprüfen, ob die Speicheranpassung deaktiviert ist, überprüfen Sie Ihre Protokolle auf die folgende Meldung:

Disabling jvm memory fitting, reason: manually disabled

Automatisches Deaktivieren

Die Speicheranpassung wird automatisch deaktiviert, wenn eine der folgenden Bedingungen erfüllt ist:

Begrenzter Containerspeicher: Der Containerspeicher beträgt weniger als 1 GB.
Festlegen expliziter Speicheroptionen: Wenn eine oder mehrere Speichereinstellungen mithilfe von JAVA_TOOL_OPTIONS in Umgebungsvariablen angegeben werden. Die Einstellungsoptionen für den Speicher umfassen folgende Werte:
- -XX:MaxRAMPercentage
- -XX:MinRAMPercentage
- -XX:InitialRAMPercentage
- -XX:MaxMetaspaceSize
- -XX:MetaspaceSize
- -XX:ReservedCodeCacheSize
- -XX:MaxDirectMemorySize
- -Xmx
- -Xms
- -Xss
Die Speicheranpassung wird beispielsweise automatisch deaktiviert, wenn Sie die maximale Heapgröße in einer Umgebungsvariable angeben, wie im folgenden Beispiel gezeigt wird:
```
az containerapp update \
  --name <CONTAINER_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --image <CONTAINER_IMAGE_LOCATION>  \
  --set-env-vars JAVA_TOOL_OPTIONS="-Xmx512m" 
```
Wenn die Speicheranpassung deaktiviert ist, wird die folgende Meldung im Protokoll ausgegeben:

Disabling jvm memory fitting, reason: use settings specified in JAVA_TOOL_OPTIONS=-Xmx512m instead Picked up JAVA_TOOL_OPTIONS: -Xmx512m
Kleine Nicht-Heapspeichergröße: Seltene Fälle, wenn die berechnete Heap- oder Nicht-Heapgröße zu klein ist (kleiner als 200 MB).

Überprüfen, ob die Speicheranpassung aktiviert ist

Überprüfen Sie den Protokolldatenstrom während des Startvorgangs auf eine Nachricht, die auf eine berechnete JVM-Speicherkonfiguration verweist.

Hier sehen Sie ein Beispiel für die während des Startvorgangs ausgegebene Meldung.

Calculated JVM Memory Configuration: -XX:MaxDirectMemorySize=10M -Xmx1498277K -XX:MaxMetaspaceSize=86874K -XX:ReservedCodeCacheSize=240M -Xss1M (Total Memory: 2G, Thread Count: 250, Loaded Class Count: 12924, Headroom: 0%)

Picked up JAVA_TOOL_OPTIONS: -XX:MaxDirectMemorySize=10M -Xmx1498277K -XX:MaxMetaspaceSize=86874K -XX:ReservedCodeCacheSize=240M -Xss1M

Laufzeitkonfiguration

Sie können Umgebungsvariablen festlegen, um das Verhalten der Speicheranpassung zu beeinflussen.

Variable	Einheit	Beispiel	Beschreibung
`BPL_JVM_HEAD_ROOM`	Percentage	`BPL_JVM_HEAD_ROOM=5`	Reservieren Sie Speicherplatz für das System basierend auf dem angegebenen Prozentsatz.
`BPL_JVM_THREAD_COUNT`	Anzahl	`BPL_JVM_THREAD_COUNT=200`	Die geschätzte maximale Anzahl von Threads.
`BPL_JVM_CLASS_ADJUSTMENT`	Anzahl Percentage	`BPL_JVM_CLASS_ADJUSTMENT=10000` `BPL_JVM_CLASS_ADJUSTMENT="10%"`	Passen Sie die Anzahl der JVM-Klassen nach expliziten oder Prozentwerten an.

Hinweis

Durch das Ändern dieser Variablen wird die automatische Speicheranpassung nicht deaktiviert.

Warnung „Nicht genügend Speicher“

Wenn Sie sich entscheiden, die Speichereinstellungen selbst zu konfigurieren, besteht das Risiko, dass die Warnung „Nicht genügend Speicher“ auftritt.

Hier sind mögliche Gründe dafür, warum Ihr Container nicht genügend Speicher hat:

Der Heapspeicher ist größer als der gesamte verfügbare Speicher.
Der Nicht-Heapspeicher ist größer als der gesamte verfügbare Speicher.
Heap- und Nicht-Heapspeicher zusammen sind größer als der gesamte verfügbare Speicher.

Wenn ihr Container nicht genügend Speicher hat, wird die folgende Warnung angezeigt:

OOM Warning: heap memory 1200M is greater than 1G available for allocation (-Xmx1200M)

Nächste Schritte

Überwachen von Protokollen mit Log Analytics

Freigeben über