Tala JVM untuk Lucee: Memori, GC dan Utas

Tala JVM untuk Lucee: Memori, GC dan Utas

Penulis: Thalhah · Tarikh: 16 Oktober 2026

Menala JVM untuk Lucee bermaksud menetapkan saiz heap dengan -Xms dan -Xmx, memilih pengumpul sampah (garbage collector) yang sesuai dengan beban anda, dan memastikan bilangan pemproses yang dilihat JVM sepadan dengan bekas atau pelayan sebenar. Matlamatnya supaya Lucee tidak kehabisan memori dengan ralat OutOfMemoryError, dan tidak pula membazir memori dengan heap yang terlalu besar pada bekas kecil. Ukur dahulu, kemudian tala: panduan ini menerangkan setiap tetapan, gejalanya, dan cara membacanya.

Hubungan Xms dan Xmx dengan Memori Sebenar

Heap ialah kawasan memori tempat objek Java, termasuk data yang dicache oleh Lucee, hidup. Dua bendera mengawal saiznya: -Xms menetapkan saiz awal heap semasa JVM dimulakan, manakala -Xmx menetapkan saiz maksimum yang boleh dicapai. Nilai lalai imej Docker rasmi Lucee ialah "-Xms64m -Xmx512m", iaitu heap bermula pada 64 MB dan membesar sehingga 512 MB apabila diperlukan.

Heap bukan satu-satunya pengguna memori. JVM turut menggunakan metaspace untuk metadata kelas, tindanan (stack) bagi setiap utas, penimbal terus dan cache kod. Oleh sebab itu, -Xmx mesti sentiasa lebih kecil daripada had memori bekas atau jumlah RAM sebenar: jika -Xmx 1 GB dan had bekas 1 GB, JVM akan melanggar had sebaik sahaja komponen lain mengambil bahagiannya, lalu kernel membunuh proses tersebut. Pautkan nilai ini dengan panduan deploy Docker kerana bekas ialah tempat isu ini paling kerap berlaku.

Kenapa Xmx Terlalu Besar Merugikan Bekas Kecil

Ramai yang beranggapan heap besar sentiasa lebih baik. Sebaliknya, pada bekas kecil, Xmx yang terlalu besar mendatangkan mudarat. Pengumpul sampah menangguhkan kerja selagi ia melihat ruang kosong, jadi heap besar yang jarang penuh akan menimbun objek mati sebelum GC berjalan, menyebabkan jeda "stop-the-world" yang lebih lama apabila GC akhirnya bertindak. Pada masa yang sama, JVM menyandarkan sebahagian heap kepada swap atau terpaksa bersaing dengan proses lain pada hos.

Docker menyediakan had memori keras melalui --memory, yang membenarkan bekas menggunakan paling banyak jumlah tetap memori, dan --memory-swap untuk mengawal swap ke cakera. Secara lalai, jika ralat out-of-memory berlaku, kernel membunuh proses dalam bekas. Had lembut melalui --memory-reservation hanya diaktifkan apabila Docker mengesan kekurangan memori pada hos. Maksud praktikalnya mudah: ukur keperluan sebenar aplikasi anda dahulu, kemudian tetapkan Xmx sedikit di bawah had bekas, bukan sebaliknya.

Memilih Pengumpul Sampah

Pengumpul sampah (GC) mengawal kekerapan dan tempoh jeda. Dokumentasi HotSpot menyenaraikan empat pengumpul utama. Pengumpul Serial menggunakan satu utas dan sesuai untuk satu pemproses atau set data kecil kira-kira 100 MB, dihidupkan dengan -XX:+UseSerialGC. Pengumpul Parallel, atau pengumpul throughput, menggunakan banyak utas dan sesuai untuk set data sederhana hingga besar pada mesin berbilang pemproses, dihidupkan dengan -XX:+UseParallelGC. G1 ialah pengumpul lalai, kebanyakannya serentak, dan boleh memenuhi sasaran masa jeda, dihidupkan dengan -XX:+UseG1GC. ZGC menawarkan jeda di bawah satu milisaat dengan kos throughput, sesuai untuk aplikasi yang memerlukan kependaman rendah, dihidupkan dengan -XX:+UseZGC.

Panduan rasmi menasihatkan supaya bermula dengan G1 lalai, melaraskan saiz heap dahulu, dan hanya menukar pengumpul jika prestasi masih tidak memuaskan. Untuk aplikasi Lucee biasa yang memproses permintaan web, G1 lalai hampir selalu pilihan yang betul; ZGC wajar dipertimbangkan hanya jika anda benar-benar mengejar jeda milisaat.

ActiveProcessorCount dalam Bekas

JVM menggunakan bilangan CPU yang dilihatnya untuk mengira saiz kumpulan utas dalaman, termasuk utas GC dan ForkJoinPool. Dalam bekas, JVM boleh tersilap melihat bilangan CPU hos dan bukannya had CPU bekas. Bendera -XX:ActiveProcessorCount=x menetapkan semula nilai itu secara eksplisit. Dokumentasi Java menyatakan bendera ini menimpa bilangan CPU yang digunakan VM untuk mengira saiz kumpulan utas, dan nilai ini tidak pernah melebihi bilangan pemproses aktif yang tersedia kepada proses.

Sejak JDK menyedari had bekas secara automatik melalui cgroups, JVM moden biasanya mengesan had CPU dan memori sendiri, tetapi menetapkan ActiveProcessorCount memberi anda kawalan yang boleh diramal. Anda boleh melihat maklumat bekas dengan -XX:+PrintContainerInfo, dan menyemak bendera ergonomik yang dipilih JVM dengan -XX:+PrintCommandLineFlags, yang mencetak saiz heap dan pengumpul sampah yang dipilih.

Menetapkan Argumen JVM pada Lucee

Cara menetapkan nilai ini bergantung pada cara Lucee dipasang. Pada pemasangan Tomcat, tambahkan kepada setenv.sh dalam folder bin Tomcat:

export CATALINA_OPTS="$CATALINA_OPTS -Xms512m -Xmx1024m -XX:+UseG1GC"

Pada imej Docker rasmi, gunakan pemboleh ubah LUCEE_JAVA_OPTS yang dibaca oleh setenv.sh imej:

LUCEE_JAVA_OPTS="-Xms512m -Xmx1024m -XX:+UseG1GC"

Pada CommandBox, tetapkan melalui server.json dalam medan jvm. Untuk perincian penuh pemasangan CommandBox, rujuk panduan pengenalan CommandBox.

Membaca Penggunaan Memori Sebenar

Jangan meneka; baca angka sebenar. Dua alat paling berguna ialah bendera permulaan dan heap dump. -XX:+PrintCommandLineFlags mencetak saiz heap dan pengumpul sampah yang dipilih JVM secara ergonomik, supaya anda tahu apa yang sebenarnya berjalan. Untuk melihat objek yang memakan memori, hasilkan heap dump, iaitu gambar semua objek dalam memori JVM pada satu masa. Ia boleh dianalisis dengan Eclipse Memory Analyzer (MAT), VisualVM, atau JProfiler.

Satu dump yang diambil semasa operasi normal berfungsi sebagai garis asas untuk perbandingan, dan membandingkan dua dump yang diambil berbeza masa mendedahkan objek yang terus membesar. Lucee juga mendedahkan tetapan berkaitan memori sebagai pemboleh ubah persekitaran, seperti yang dijelaskan dalam panduan caching dan prestasi.

Gejala Heap Habis

Kenali tanda-tanda sebelum ia menjadi krisis. Ralat java.lang.OutOfMemoryError ialah tanda paling jelas. Masa respons yang perlahan tanpa sebab, atau jeda berkala apabila GC besar berjalan, ialah tanda tekanan memori. Dalam bekas, proses dibunuh tanpa amaran oleh kernel ialah gejala yang paling mengelirukan kerana tiada ralat dalam log aplikasi. Peningkatan penggunaan memori yang berterusan selepas GC pula menunjukkan kebocoran memori, iaitu objek yang sepatutnya dikutip tetapi kekal.

Heap Dump untuk Diagnosis

Sediakan heap dump automatik supaya anda menangkap keadaan memori tepat apabila ralat berlaku:

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/lucee/heapdumps/

Heap dump boleh sebesar saiz heap maksimum anda, jadi pastikan ruang cakera mencukupi, sekurang-kurangnya 1.5 kali nilai Xmx. Mencipta dump menyebabkan jeda "stop-the-world" kerana semua utas aplikasi dihentikan semasa dump ditulis. Ingat bahawa dump mengandungi data sensitif seperti kata laluan dan token sesi; jangan muat naiknya ke forum awam.

Tetapan Lucee Berkaitan Memori

Lucee menyediakan beberapa pemboleh ubah persekitaran untuk mengawal kelakuan berkaitan memori:

Ukur Sebelum Menala

Peraturan paling penting: ukur dahulu, kemudian tala. Mulakan dengan nilai lalai, kumpul data selama beberapa hari di bawah beban pengeluaran sebenar, dan hanya ubah satu pemboleh ubah pada satu masa. Menukar Xmx, pengumpul sampah dan ActiveProcessorCount serentak menjadikan mustahil untuk mengetahui mana satu yang memberi kesan. Pantau memori JVM secara berterusan, seperti yang diterangkan dalam panduan log dan pemantauan.

Soalan Lazim (FAQ)

Apakah maksud Xms dan Xmx dalam JVM Lucee?

Xms ialah saiz awal heap semasa JVM bermula, manakala Xmx ialah saiz maksimum heap. Nilai lalai imej Docker Lucee ialah -Xms64m -Xmx512m.

Adakah Xmx yang besar sentiasa lebih baik?

Tidak. Pada bekas kecil, Xmx terlalu besar menyebabkan jeda GC lebih lama dan pembaziran memori, dan boleh menyebabkan kernel membunuh proses apabila had bekas dilanggar.

Pengumpul sampah mana yang patut saya guna untuk Lucee?

Mulakan dengan G1, pengumpul lalai. Pertimbangkan ZGC hanya jika anda memerlukan jeda di bawah satu milisaat, dan Serial untuk satu CPU atau heap yang sangat kecil.

Apakah ActiveProcessorCount dan kenapa ia penting dalam bekas?

-XX:ActiveProcessorCount=x menimpa bilangan CPU yang digunakan JVM untuk mengira saiz kumpulan utas GC dan ForkJoinPool. Dalam bekas, ia memastikan JVM tidak tersilap melihat bilangan CPU hos.

Bagaimana saya tahu heap Lucee hampir habis?

Tanda termasuk ralat OutOfMemoryError, masa respons yang perlahan, jeda GC berkala, dan proses bekas yang dibunuh kernel tanpa ralat dalam log aplikasi.

Sumber

• Creating Heap Dumps in Lucee, docs.lucee.org
• Docker, docs.lucee.org
• Environment Variables and System Properties, docs.lucee.org
• Available Collectors, Oracle GC Tuning Guide
• Java command options, Oracle
• JEP 8182070: Container Awareness, OpenJDK
• Runtime options with Memory, CPUs, and GPUs, Docker Docs