Passen Sie das Startverhalten der Java-Laufzeit für Lambda-Funktionen an

Auf dieser Seite werden spezifische Einstellungen für Java-Funktionen in beschrieben AWS Lambda. Sie können diese Einstellungen verwenden, um das Startup-Verhalten der Java-Laufzeit anzupassen. Dies kann die allgemeine Funktionslatenz reduzieren und die Gesamtleistung der Funktionen verbessern, ohne dass Code geändert werden muss.

Die JAVA_TOOL_OPTIONS-Umgebungsvariable verstehen

In Java unterstützt Lambda die Umgebungsvariable JAVA_TOOL_OPTIONS, um zusätzliche Befehlszeilenvariablen in Lambda festzulegen. Sie können diese Umgebungsvariable auf verschiedene Arten verwenden, z. B. um die Einstellungen für die gestufte Kompilierung anzupassen. Im nächsten Beispiel wird gezeigt, wie die Umgebungsvariable JAVA_TOOL_OPTIONS für diesen Anwendungsfall verwendet wird.

Beispiel: Einstellungen für die gestufte Kompilierung anpassen

Die gestufte Kompilierung ist ein Feature der virtuellen Java-Maschine (JVM). Sie können spezielle Einstellungen für die mehrstufige Kompilierung verwenden, um die Compiler der JVM just-in-time (JIT) optimal zu nutzen. In der Regel ist der C1-Compiler für eine schnelle Startzeit optimiert. Der C2-Compiler ist für die beste Gesamtleistung optimiert, benötigt aber auch mehr Speicher und es dauert länger, bis er erreicht ist. Die gestufte Kompilierung umfasst 5 verschiedene Stufen. Auf Stufe 0 interpretiert die JVM Java-Bytecode. Auf Stufe 4 verwendet die JVM den C2-Compiler, um die beim Startup der Anwendung gesammelten Profildaten zu analysieren. Im Laufe der Zeit überwacht sie die Code-Nutzung, um die besten Optimierungen zu identifizieren.

Das Anpassen der mehrstufigen Kompilierungsebene kann Ihnen helfen, die Leistung Ihrer Java-Funktionen zu optimieren. Bei kleinen Funktionen, die schnell ausgeführt werden, kann das Setzen der mehrstufigen Kompilierung auf Stufe 1 dazu beitragen, die Kaltstartleistung zu verbessern, indem die JVM den C1-Compiler verwendet. Diese Einstellung erzeugt schnell optimierten systemeigenen Code, generiert jedoch keine Profilerstellungsdaten und verwendet niemals den C2-Compiler. Bei größeren, rechenintensiven Funktionen maximiert die Einstellung der mehrstufigen Kompilierung auf Stufe 4 die Gesamtleistung auf Kosten von zusätzlichem Speicherverbrauch und zusätzlicher Optimierungsarbeit bei den ersten Aufrufen nach der Bereitstellung jeder Lambda-Ausführungsumgebung.

Für Java 11-Laufzeiten und darunter verwendet Lambda die standardmäßigen JVM-Einstellungen für die mehrstufige Kompilierung. Für Java 17 und Java 21 konfiguriert Lambda die JVM so, dass die mehrstufige Kompilierung standardmäßig auf Stufe 1 beendet wird. Ab Java 25 stoppt Lambda die mehrstufige Kompilierung immer noch standardmäßig auf Stufe 1, außer wenn Parallelität SnapStart oder Provisioned verwendet wird. In diesem Fall werden die standardmäßigen JVM-Einstellungen verwendet. Dadurch wird die Leistung bei Parallelität SnapStart und Bereitstellung verbessert, ohne dass es zu einer Kaltstartstrafe kommt, da die gestaffelte Kompilierung in diesen Fällen außerhalb des Aufrufpfads erfolgt. Um diesen Vorteil zu maximieren, können Sie das Priming — das Ausführen von Codepfaden während der Funktionsinitialisierung — verwenden, um JIT auszulösen, bevor der SnapStart Snapshot erstellt wird, oder wenn die Ausführungsumgebungen von Provisioned Concurrency vorab bereitgestellt werden. Weitere Informationen finden Sie im Blogbeitrag Optimierung der Kaltstartleistung von AWS Lambda mithilfe fortschrittlicher Priming-Strategien mit. SnapStart

Anpassen der Einstellungen für die gestufte Kompilierung (Konsole)

1. Öffnen Sie die Seite Funktionen in der Lambda-Konsole.

2. Wählen Sie eine Java-Funktion, für die Sie die gestufte Kompilierung anpassen möchten.

3. Wählen Sie die Registerkarte Konfiguration und dann im linken Menü die Option Umgebungsvariablen aus.

4. Wählen Sie Bearbeiten aus.

5. Wählen Sie Umgebungsvariablen hinzufügen aus.

6. Geben Sie JAVA_TOOL_OPTIONS als Schlüssel ein. Geben Sie -XX:+TieredCompilation -XX:TieredStopAtLevel=1 als Wert ein.

   

7. Wählen Sie Speichern.

Anmerkung

Sie können Lambda auch verwenden SnapStart , um Kaltstartprobleme zu beheben. SnapStartverwendet zwischengespeicherte Snapshots Ihrer Ausführungsumgebung, um die Startleistung erheblich zu verbessern. Weitere Informationen zu SnapStart Funktionen, Einschränkungen und unterstützten Regionen finden Sie unter. Verbesserung der Startleistung mit Lambda SnapStart

Beispiel: Anpassen des GC-Verhaltens mit JAVA_TOOL_OPTIONS

Java-11-Laufzeiten verwenden den Serial Garbage Collector (GC) für Garbage Collection. Standardmäßig verwenden Java-17-Laufzeiten auch den Serial GC. Mit Java 17 können Sie jedoch auch die Umgebungsvariable JAVA_TOOL_OPTIONS verwenden, um den Standard-GC zu ändern. Sie können zwischen dem Parallel GC und dem Shenandoah GC wählen.

Wenn Ihr Workload beispielsweise mehr und mehrere Speicher beansprucht CPUs, sollten Sie die Verwendung von Parallel GC in Betracht ziehen, um eine bessere Leistung zu erzielen. Hängen Sie dazu Folgendes an den Wert Ihrer Umgebungsvariablen JAVA_TOOL_OPTIONS an:

-XX:+UseParallelGC

Wenn Ihr Workload viele kurzlebige Objekte enthält, können Sie von einem geringeren Speicherverbrauch profitieren, indem Sie den in Java 25 eingeführten Generationsmodus des Shenandoah-Garbage-Collectors aktivieren. Hängen Sie dazu Folgendes an den Wert Ihrer Umgebungsvariablen an: JAVA_TOOL_OPTIONS

-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational

Log4j-Patch für Log4Shell

Die Lambda-Laufzeiten für Java 8, 11, 17 und 21 enthalten einen Patch zur Minderung der Log4Shell-Sicherheitslücke (CVE-2021-44228) in Log4j, einem beliebten Java-Logging-Framework. Dieser Patch verursacht einen Leistungsaufwand beim Kaltstart. Wenn Sie eine gepatchte Version von Log4j (Version 2.17.0 oder höher) verwenden, können Sie diesen Patch deaktivieren, um die Kaltstartleistung zu verbessern. Um den Patch zu deaktivieren, setzen Sie die Umgebungsvariable auf. AWS_LAMBDA_DISABLE_CVE_2021_44228_PROTECTION true

Ab Java 25 enthalten Lambda-Laufzeiten den Log4Shell-Patch nicht mehr. Sie müssen überprüfen, ob Sie Log4j Version 2.17.0 oder höher verwenden.

Ahead-of-Time (AOT) und CDS-Caches

Ab Java 25 umfasst die Lambda-Laufzeit einen Ahead-of-Time (AOT-) Cache für den Java Runtime Interface Client (RIC), eine Laufzeitkomponente, die aktiv nach Ereignissen von der Lambda Runtime API abfragt. Dies verbessert die Kaltstartleistung.

AOT-Caches sind spezifisch für einen JVM-Build. Wenn Lambda die verwaltete Laufzeit aktualisiert, aktualisiert es auch den AOT-Cache für das RIC. Wenn Sie jedoch Ihre eigenen AOT-Caches bereitstellen, können diese ungültig werden oder nach einem Runtime-Update zu unerwartetem Verhalten führen. Wir empfehlen daher dringend, keine AOT-Caches zu verwenden, wenn Sie verwaltete Laufzeiten verwenden. Um AOT-Caches zu verwenden, sollten Sie Ihre Funktionen mithilfe von Container-Images bereitstellen.

AOT-Caches können nicht mit Class Data Sharing (CDS) -Caches verwendet werden. Wenn Sie CDS-Caches in Ihrer Lambda-Funktion bereitstellen, deaktiviert Lambda den AOT-Cache.