Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Sesuaikan 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.
Bagian-bagian
Memahami variabel lingkungan JAVA_TOOL_OPTIONS
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 Java virtual machine (JVM). Anda dapat menggunakan pengaturan kompilasi berjenjang tertentu untuk memanfaatkan kompiler just-in-time (JIT) JVM dengan 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 compiler 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 menyesuaikan kinerja fungsi Java Anda. Untuk fungsi kecil yang dijalankan dengan cepat, mengatur kompilasi berjenjang ke level 1 dapat membantu meningkatkan kinerja cold start 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 compiler 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 panggilan 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 Provisioned Concurrency telah disediakan sebelumnya. Untuk informasi lebih lanjut, lihat posting blog Meng optimalkan kinerja start dingin AWS Lambda menggunakan strategi priming lanjutan dengan. SnapStart
Untuk menyesuaikan pengaturan kompilasi berjenjang (konsol)
-
Buka halaman Functions
di konsol Lambda. -
Pilih fungsi Java yang ingin Anda sesuaikan kompilasi berjenjang.
-
Pilih tab Konfigurasi, lalu pilih Variabel lingkungan di menu kiri.
-
Pilih Edit.
-
Pilih Tambahkan variabel lingkungan.
-
Untuk kunci, masukkan
JAVA_TOOL_OPTIONS. Untuk nilainya, masukkan-XX:+TieredCompilation -XX:TieredStopAtLevel=1.
-
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
Runtime Java 11 menggunakan Serial JAVA_TOOL_OPTIONS lingkungan untuk mengubah GC default. Anda dapat memilih antara GC Paralel dan Shenandoah GC.
Misalnya, jika beban kerja Anda menggunakan lebih banyak memori dan beberapa CPU, pertimbangkan untuk menggunakan GC Paralel untuk kinerja yang lebih baik. Anda dapat melakukan ini dengan menambahkan yang berikut ini ke nilai variabel JAVA_TOOL_OPTIONS lingkungan Anda:
-XX:+UseParallelGC
Jika beban kerja Anda memiliki banyak objek berumur pendek, Anda dapat memperoleh manfaat dari konsumsi memori yang lebih rendah dengan mengaktifkan mode generasi pengumpul sampah Shenandoah yang diperkenalkan di Java 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 patch 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 patch ini untuk meningkatkan kinerja cold start. Untuk menonaktifkan patch, 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. Ketika Lambda memperbarui runtime terkelola, ia juga memperbarui cache AOT untuk RIC. Namun, jika Anda menerapkan cache AOT Anda sendiri, 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 Class Data Sharing (CDS). Jika Anda menerapkan cache CDS di fungsi Lambda Anda, maka Lambda menonaktifkan cache AOT.