Personalizzare il comportamento di avvio del runtime Java per le funzioni Lambda

Questa pagina descrive le impostazioni specifiche delle funzioni Java in AWS Lambda. È possibile utilizzare queste impostazioni per personalizzare il comportamento di avvio del runtime Java. Ciò può ridurre la latenza complessiva della funzione e migliorare le prestazioni complessive delle funzioni senza dover modificare il codice.

Informazioni sulla variabile di ambiente JAVA_TOOL_OPTIONS

In Java, Lambda supporta la variabile di ambiente JAVA_TOOL_OPTIONS per impostare variabili della linea di comando aggiuntive in Lambda. È possibile utilizzare questa variabile di ambiente in vari modi, ad esempio per personalizzare le impostazioni di compilazione a più livelli. L'esempio seguente illustra come utilizzare la variabile di ambiente JAVA_TOOL_OPTIONS per questo caso d'uso.

Esempio: personalizzazione delle impostazioni di compilazione a più livelli

La compilazione a livelli è una funzionalità della macchina virtuale Java (JVM). È possibile utilizzare impostazioni di compilazione specifiche a più livelli per utilizzare al meglio i compilatori JVM just-in-time (JIT). In genere, il compilatore C1 è ottimizzato per tempi di avvio rapidi. Il compilatore C2 è ottimizzato per le migliori prestazioni complessive, ma di contro utilizza più memoria e impiega più tempo per raggiungerle. Esistono 5 diversi livelli di compilazione a più livelli. Al livello 0, la JVM interpreta il bytecode Java. Al livello 4, la JVM utilizza il compilatore C2 per analizzare i dati di profilazione raccolti durante l'avvio dell'applicazione. Nel tempo, monitora l'utilizzo del codice per identificare le migliori ottimizzazioni.

La personalizzazione del livello di compilazione a più livelli può aiutarti a ottimizzare le prestazioni delle funzioni Java. Per le piccole funzioni che vengono eseguite rapidamente, l'impostazione della compilazione a più livelli sul livello 1 può contribuire a migliorare le prestazioni di avvio a freddo facendo in modo che JVM utilizzi il compilatore C1. Questa impostazione produce rapidamente codice nativo ottimizzato, ma non genera dati di profilazione e non utilizza mai il compilatore C2. Per le funzioni più grandi e ad alta intensità di calcolo, l'impostazione della compilazione a più livelli al livello 4 massimizza le prestazioni complessive a scapito del consumo di memoria aggiuntivo e del lavoro di ottimizzazione aggiuntivo durante le prime richiami dopo il provisioning di ogni ambiente di esecuzione Lambda.

Per i runtime Java 11 e versioni precedenti, Lambda utilizza le impostazioni di compilazione a più livelli JVM predefinite. Per Java 17 e Java 21, Lambda configura la JVM per interrompere la compilazione su più livelli al livello 1 per impostazione predefinita. A partire da Java 25, Lambda interrompe ancora la compilazione a più livelli al livello 1 per impostazione predefinita, tranne quando si utilizza SnapStart o viene fornita la concorrenza, nel qual caso vengono utilizzate le impostazioni JVM predefinite. Ciò migliora le prestazioni SnapStart e la concorrenza di Provisioned senza incorrere in penalità di avvio a freddo, poiché in questi casi la compilazione a più livelli viene eseguita al di fuori del percorso di invoke. Per massimizzare questo vantaggio, è possibile utilizzare i percorsi di codice di esecuzione priming durante l'inizializzazione della funzione per attivare JIT prima di scattare l'istantanea o quando gli ambienti di esecuzione Provisioned Concurrency sono predisposti. SnapStart Per ulteriori informazioni, consulta il post sul blog Ottimizzazione delle prestazioni di avviamento a freddo di AWS Lambda utilizzando strategie di adescamento avanzate con. SnapStart

Personalizzazione delle impostazioni di compilazione a più livelli (console)

1. Apri la pagina Funzioni della console Lambda.

2. Scegli una funzione Java per la quale desideri personalizzare la compilazione a più livelli.

3. Scegli la scheda Configurazione, quindi scegli Variabili di ambiente nel menu a sinistra.

4. Scegli Modifica.

5. Scegli Add environment variable (Aggiungi variabile d'ambiente).

6. Per la chiave, inserisci JAVA_TOOL_OPTIONS. Per il valore, inserisci -XX:+TieredCompilation -XX:TieredStopAtLevel=1.

   

7. Scegli Save (Salva).

Nota

Puoi anche usare Lambda SnapStart per mitigare i problemi di avvio a freddo. SnapStartutilizza istantanee memorizzate nella cache dell'ambiente di esecuzione per migliorare significativamente le prestazioni di avvio. Per ulteriori informazioni su SnapStart funzionalità, limitazioni e aree supportate, consulta. Migliorare le prestazioni di avvio con Lambda SnapStart

Esempio: personalizzazione del comportamento del GC utilizzando JAVA_TOOL_OPTIONS

I runtime di Java 11 utilizzano Serial Garbage Collector (GC) per la rimozione di oggetti inutili (garbage collection). Per impostazione predefinita, anche i runtime di Java 17 utilizzano Serial GC. Tuttavia, con Java 17 puoi anche utilizzare la variabile di ambiente JAVA_TOOL_OPTIONS per modificare il GC predefinito. Puoi scegliere tra Parallel GC e Shenandoah GC.

Ad esempio, se il tuo carico di lavoro utilizza più memoria e più memoria CPUs, prendi in considerazione l'utilizzo di Parallel GC per prestazioni migliori. Puoi farlo aggiungendo quanto segue al valore della tua variabile di ambiente JAVA_TOOL_OPTIONS:

-XX:+UseParallelGC

Se il tuo carico di lavoro include molti oggetti di breve durata, potresti trarre vantaggio da un minore consumo di memoria abilitando la modalità generazionale dello Shenandoah Garbage Collector introdotto in Java 25. Per fare ciò, aggiungi quanto segue al valore della tua variabile di ambiente: JAVA_TOOL_OPTIONS

-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational

Patch Log4j per Log4Shell

I runtime Lambda per Java 8, 11, 17 e 21 includono una patch per mitigare la vulnerabilità Log4Shell (CVE-2021-44228) in Log4j, un popolare framework di registrazione Java. Questa patch comporta un sovraccarico prestazionale dovuto all'avvio a freddo. Se stai usando una versione patchata di Log4j (versione 2.17.0 o successiva), puoi disabilitare questa patch per migliorare le prestazioni di avvio a freddo. Per disabilitare la patch, imposta la variabile di ambiente su. AWS_LAMBDA_DISABLE_CVE_2021_44228_PROTECTION true

A partire da Java 25, i runtime Lambda non includono più la patch Log4Shell. È necessario verificare di utilizzare Log4j versione 2.17.0 o successiva.

Ahead-of-Time (AOT) e cache CDS

A partire da Java 25, il runtime Lambda include una cache Ahead-of-Time (AOT) per il Java Runtime Interface Client (RIC), un componente di runtime che esegue attivamente il polling degli eventi dall'API Lambda Runtime. Ciò migliora le prestazioni di avvio a freddo.

Le cache AOT sono specifiche per una build JVM. Quando Lambda aggiorna il runtime gestito, aggiorna anche la cache AOT per il RIC. Tuttavia, se distribuisci le tue cache AOT, queste potrebbero essere invalidate o causare un comportamento imprevisto a seguito di un aggiornamento del runtime. Pertanto, consigliamo vivamente di non utilizzare le cache AOT quando si utilizzano runtime gestiti. Per utilizzare le cache AOT, è necessario distribuire le funzioni utilizzando le immagini dei contenitori.

Le cache AOT non possono essere utilizzate con le cache CDS (Class Data Sharing). Se distribuisci cache CDS nella tua funzione Lambda, Lambda disabilita la cache AOT.