Kustomisasi perilaku startup runtime Java untuk fungsi Lambda

Halaman ini menjelaskan pengaturan khusus untuk fungsi Java di AWS Lambda. Anda dapat menggunakan pengaturan ini untuk menyesuaikan perilaku startup runtime Java. Ini dapat mengurangi latensi fungsi secara keseluruhan dan meningkatkan kinerja fungsi secara keseluruhan, tanpa harus memodifikasi kode apa pun.

Memahami variabel JAVA_TOOL_OPTIONS lingkungan

Di Java, Lambda mendukung variabel JAVA_TOOL_OPTIONS lingkungan untuk mengatur variabel baris perintah tambahan di Lambda. Anda dapat menggunakan variabel lingkungan ini dengan berbagai cara, seperti untuk menyesuaikan pengaturan kompilasi berjenjang. Contoh berikutnya menunjukkan bagaimana menggunakan variabel JAVA_TOOL_OPTIONS lingkungan untuk kasus penggunaan ini.

Contoh: Menyesuaikan pengaturan kompilasi berjenjang

Kompilasi berjenjang adalah fitur dari mesin virtual Java (JVM). Anda dapat menggunakan pengaturan kompilasi berjenjang tertentu untuk memanfaatkan kompiler JVM just-in-time (JIT) sebaik-baiknya. Biasanya, kompiler C1 dioptimalkan untuk waktu start-up yang cepat. Kompiler C2 dioptimalkan untuk kinerja keseluruhan terbaik, tetapi juga menggunakan lebih banyak memori dan membutuhkan waktu lebih lama untuk mencapainya. Ada 5 tingkat kompilasi berjenjang yang berbeda. Pada Level 0, JVM menafsirkan kode byte Java. Pada Level 4, JVM menggunakan kompiler C2 untuk menganalisis data profil yang dikumpulkan selama startup aplikasi. Seiring waktu, ia memantau penggunaan kode untuk mengidentifikasi pengoptimalan terbaik.

Menyesuaikan tingkat kompilasi berjenjang dapat membantu Anda menyetel kinerja fungsi Java Anda. Untuk fungsi kecil yang dijalankan dengan cepat, menyetel kompilasi berjenjang ke level 1 dapat membantu meningkatkan kinerja start dingin dengan meminta JVM menggunakan kompiler C1. Pengaturan ini dengan cepat menghasilkan kode asli yang dioptimalkan tetapi tidak menghasilkan data profil apa pun dan tidak pernah menggunakan kompiler C2. Untuk fungsi yang lebih besar dan intensif komputasi, pengaturan kompilasi berjenjang ke level 4 memaksimalkan kinerja keseluruhan dengan mengorbankan konsumsi memori tambahan dan pekerjaan pengoptimalan tambahan selama pemanggilan pertama setelah setiap lingkungan eksekusi Lambda disediakan.

Untuk runtime Java 11 dan di bawahnya, Lambda menggunakan pengaturan kompilasi berjenjang JVM default. Untuk Java 17 dan Java 21, Lambda mengonfigurasi JVM untuk menghentikan kompilasi berjenjang di level 1 secara default. Dari Java 25, Lambda masih menghentikan kompilasi berjenjang di level 1 secara default, kecuali saat menggunakan SnapStart atau Konkurensi yang disediakan, dalam hal ini pengaturan JVM default digunakan. Ini meningkatkan kinerja untuk SnapStart dan Konkurensi yang disediakan tanpa menimbulkan penalti start dingin karena kompilasi berjenjang dilakukan di luar jalur pemanggilan dalam kasus ini. Untuk memaksimalkan manfaat ini, Anda dapat menggunakan priming - mengeksekusi jalur kode selama inisialisasi fungsi untuk memicu JIT sebelum mengambil SnapStart snapshot atau ketika lingkungan eksekusi Konkurensi yang Disediakan telah disediakan sebelumnya. Untuk informasi lebih lanjut, lihat posting blog Mengoptimalkan kinerja start dingin AWS Lambda menggunakan strategi priming lanjutan dengan. SnapStart

Untuk menyesuaikan pengaturan kompilasi berjenjang (konsol)

1. Buka halaman Fungsi di konsol Lambda.

2. Pilih fungsi Java yang ingin Anda sesuaikan kompilasi berjenjang.

3. Pilih tab Konfigurasi, lalu pilih variabel Lingkungan di menu sebelah kiri.

4. Pilih Edit.

5. Pilih Tambahkan variabel lingkungan.

6. Untuk kuncinya, masukkanJAVA_TOOL_OPTIONS. Untuk nilainya, masukkan-XX:+TieredCompilation -XX:TieredStopAtLevel=1.

   

7. Pilih Simpan.

catatan

Anda juga dapat menggunakan Lambda SnapStart untuk mengurangi masalah start dingin. SnapStartmenggunakan snapshot cache dari lingkungan eksekusi Anda untuk meningkatkan kinerja start-up secara signifikan. Untuk informasi selengkapnya tentang SnapStart fitur, batasan, dan wilayah yang didukung, lihatMeningkatkan kinerja startup dengan Lambda SnapStart.

Contoh: Menyesuaikan perilaku GC menggunakan JAVA_TOOL_OPTIONS

Java 11 runtime menggunakan Serial garbage collector (GC) untuk pengumpulan sampah. Secara default, runtime Java 17 juga menggunakan Serial GC. Namun, dengan Java 17 Anda juga dapat menggunakan variabel JAVA_TOOL_OPTIONS lingkungan untuk mengubah GC default. Anda dapat memilih antara Parallel GC dan Shenandoah GC.

Misalnya, jika beban kerja Anda menggunakan lebih banyak memori dan beberapa CPUs, pertimbangkan untuk menggunakan Parallel GC untuk kinerja yang lebih baik. Anda dapat melakukan ini dengan menambahkan berikut ini ke nilai variabel JAVA_TOOL_OPTIONS lingkungan Anda:

-XX:+UseParallelGC

Jika beban kerja Anda memiliki banyak objek berumur pendek, Anda dapat mengambil manfaat dari konsumsi memori yang lebih rendah dengan mengaktifkan mode generasi pengumpul sampah Shenandoah yang diperkenalkan di Jawa 25. Untuk melakukan ini, tambahkan yang berikut ini ke nilai variabel JAVA_TOOL_OPTIONS lingkungan Anda:

-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational

Patch Log4j untuk Log4Shell

Runtime Lambda untuk Java 8, 11, 17, dan 21 menyertakan tambalan untuk mengurangi kerentanan Log4Shell (CVE-2021-44228) di Log4j, kerangka kerja logging Java yang populer. Patch ini menimbulkan overhead kinerja start dingin. Jika Anda menggunakan versi Log4j yang ditambal (versi 2.17.0 atau yang lebih baru), Anda dapat menonaktifkan tambalan ini untuk meningkatkan kinerja start dingin. Untuk menonaktifkan tambalan, atur variabel AWS_LAMBDA_DISABLE_CVE_2021_44228_PROTECTION lingkungan ketrue.

Mulai dari Java 25, runtime Lambda tidak lagi menyertakan patch Log4Shell. Anda harus memverifikasi bahwa Anda menggunakan Log4j versi 2.17.0 atau yang lebih baru.

Ahead-of-Time (AOT) dan cache CDS

Dimulai dengan Java 25, runtime Lambda menyertakan cache Ahead-of-Time (AOT) untuk klien antarmuka runtime Java (RIC), komponen runtime yang secara aktif melakukan polling untuk peristiwa dari Lambda Runtime API. Ini meningkatkan kinerja start dingin.

Cache AOT khusus untuk build JVM. Saat Lambda memperbarui runtime terkelola, Lambda juga memperbarui cache AOT untuk RIC. Namun, jika Anda menerapkan cache AOT Anda sendiri, cache ini mungkin tidak valid atau mengakibatkan perilaku tak terduga setelah pembaruan runtime. Oleh karena itu, kami sangat menyarankan untuk tidak menggunakan cache AOT saat menggunakan runtime terkelola. Untuk menggunakan cache AOT, Anda harus menerapkan fungsi Anda menggunakan gambar kontainer.

Cache AOT tidak dapat digunakan dengan cache Berbagi Data Kelas (CDS). Jika Anda menerapkan cache CDS di fungsi Lambda Anda, maka Lambda menonaktifkan cache AOT.