Bagian ini hanya memperkenalkan bagian tempur yang sebenarnya. Untuk parameter teoretis tertentu, silakan Baidu.
Alat yang Diperlukan: Linux Server JMeter Test Tool Xshell A Web Application
Parameter JVM Tomcat dapat dikonfigurasi di Catalina.sh, dan jika ada di jendela, Anda dapat mengonfigurasi file .bat.
Konfigurasi 1:
Di sini saya mengkonfigurasi jalur log GC sebagai /home/log/gc.log untuk mencetak log GC, tumpukan awal dan memori tumpukan maksimum diatur ke 50m, dan ketika file pembuangan output dilimpah, menggunakan kolektor sampah serial, dan ukuran generasi permanen adalah 50m.
Masukkan aplikasi web di direktori yang sesuai, konfigurasikan server.xml (konfigurasi tidak diperkenalkan di sini), dan mulai Tomcat.
Pengujian throughput dilakukan dengan menggunakan alat uji tekanan (JMeter). Siswa yang tidak pernah menggunakannya dapat mengunduh dan mempelajarinya di situs web resmi http://jmeter.apache.org/
Buat grup pengguna (10 utas, masing -masing utas meminta 1000 kali), atur informasi dari permintaan HTTP, hasilkan laporan agregat dan log GC
Mari kita lihat log GC terlebih dahulu:
GC lengkap di layar, akhirnya periksa laporan agregat:
Throughput dipertahankan pada 122,7 per detik. Dari kasus ini kita dapat melihat bahwa generasi lama pada dasarnya penuh, dan setelah fullgc, generasi baru akan memiliki sedikit tersisa. Secara umum, waktu jeda GC penuh adalah yang terpanjang dan sering terjadi, jelas konfigurasi seperti itu tidak masuk akal.
Konfigurasi 2:
Konfigurasi ini terutama meningkatkan memori tumpukan maksimum. Untuk secara otomatis memperluas mesin virtual dan mendapatkan ukuran memori tumpukan yang stabil.
Cukup perhatikan memori tumpukan maksimum 82924K adalah sekitar 80m, yang berarti bahwa mesin virtual secara otomatis memperluas memori heap ke 80m dan menstabilkannya. Tes konfigurasi ini hanya untuk menemukan memori tumpukan yang stabil untuk tes berikutnya.
Konfigurasi Tiga:
Atur memori awal tumpukan dengan 128m.
Dari hasil konfigurasi 2, dapat dilihat bahwa memori heap akhirnya stabil di sekitar 80m, sehingga memori tumpukan yang lebih kecil dari 80m cenderung menyebabkan sejumlah besar reaksi GC, jadi di sini saya mengatur memori heap ke 128m, yang dapat mengurangi jumlah GC.
Anda dapat melihat bahwa throughput telah sedikit meningkat, jumlah GC telah menurun secara signifikan, dan interval waktu GC telah menjadi lebih lama.
Konfigurasi 4:
Saat ini menggunakan ParallalGC Recycler, yang merupakan pendaur ulang paralel multithreaded.
Throughput pendaur ulang GC menggunakan paralel multithreaded telah sedikit ditingkatkan. (ParallalGC dan SerialGC memiliki sedikit efek pada throughput tanpa tekanan GC.)
Konfigurasi 5:
Konfigurasi 6:
Menurut kesimpulan konfigurasi 3, GC akan sering terjadi pada memori heap di bawah 80m. Dikombinasikan dengan kesimpulan yang diperoleh dalam konfigurasi 4, ketika ada tekanan GC tertentu, throughput paralelgc dan serialGC akan menunjukkan perbedaan tertentu. Jika memori heap 5 dan 6 dikonfigurasi dengan 64m <80m, sering GC akan terjadi. Saat menggunakan pendaur ulang GC yang berbeda, secara teoritis akan ada perbedaan besar dalam throughput, tetapi mengapa perbedaan dalam percobaan saya tidak terlalu besar, dan mengapa? Hei, keluargaku miskin. Saya menggunakan CPU satu inti. Dalam kasus single-core, perubahan kinerja paralelGC tidak jelas. SerialGC direkomendasikan ketika kemampuan inti tunggal atau paralel lemah. Siswa yang memiliki kondisinya dapat mencobanya dengan server multi-core!
Konfigurasi 7:
Coba gunakan ParnewGC. Generasi baru menggunakan ParnewGC untuk mendaur ulang, sedangkan generasi lama masih menggunakan serialgc untuk mendaur ulang. Lihat bagaimana kinerjanya?
Ini memiliki kinerja yang lebih baik daripada menggunakan semua pendaur ulang serial, tetapi kinerja yang lebih buruk daripada menggunakan semua pendaur ulang paralel.
Selain itu, peningkatan versi JDK juga dapat sedikit meningkatkan kinerja, tetapi peningkatan versi JDK hadir dengan risiko tertentu, dan beberapa bug yang tidak diketahui dapat dimasukkan ke dalam versi baru JDK.
Akhirnya, saya mendaftarkan beberapa parameter konfigurasi JVM yang umum digunakan untuk referensi:
1. Parameter terkait dengan periode pemulihan serial
• -xx:+useerialgc: Gunakan kolektor serial dalam generasi baru dan lama
• -xx: Survivorratio: Tetapkan ukuran area Eden dan rasio area yang selamat
• -xx: PretenuresizeThreshold: Atur ambang batas untuk objek besar untuk secara langsung memasuki usia tua. Saat ukuran objek melebihi nilai ini, itu akan dialokasikan secara langsung di usia tua
• -xx: maxtenuringthreshold: Mengatur nilai usia maksimum dari objek yang memasuki usia tua. Setelah setiap GC minor, usia subjek ditambahkan oleh 1. Objek apa pun yang lebih besar dari usia ini pasti akan memasuki usia tua.
2. Parameter terkait GC paralel
• -xx:+USEPARNEWGC: Gunakan kolektor paralel dalam generasi baru.
• -xx:+useparalleloldgc: Gunakan kolektor paralel di usia tua
• -xx:+paralelgcthreads: Mengatur jumlah utas yang digunakan untuk pengumpulan sampah, yang biasanya dapat diatur sama dengan jumlah CPU. Ketika ada sejumlah besar CPU, juga dimungkinkan untuk menetapkan nilai yang relatif kecil.
• -xx:+maxgcpausemillis: Tetapkan waktu jeda pengumpulan sampah maksimum. Nilainya adalah bilangan bulat yang lebih besar dari 0. Ketika kolektor bekerja, itu akan menyesuaikan ukuran tumpukan java atau parameter lainnya, dan mengontrol waktu jeda ke maxgcpausemillis sebanyak mungkin.
• -xx: +UseAdaptiveSizePolicy: Nyalakan strategi GC adaptif. Dalam mode ini, parameter seperti ukuran generasi baru dan rasio survivio, dan usia objek dalam generasi lama akan secara otomatis disesuaikan untuk mencapai titik keseimbangan antara ukuran tumpukan, throughput dan jeda.
• -xx:+gcTimeratio: atur ukuran throughput. Nilainya adalah sertifikat antara 0 dan 100. Dengan asumsi bahwa nilai GcTimeratio adalah N, sistem akan menghabiskan tidak lebih dari 1/(1+n) waktu untuk pengumpulan sampah.
3. Parameter terkait dengan CMS Collector
• -xx:+useconcmarksweepgc: Generasi baru menggunakan kolektor paralel, sedangkan generasi lama menggunakan kolektor serial CMS+.
• -XX: ParallelCMSThreads: Atur jumlah utas untuk CMS.
• -XX: CMSinITiatingoccancyFraction: Tetapkan berapa banyak kolektor CMS dipicu setelah ruang usia tua digunakan, default 68%
• -xx: usecmscompactatfullcollection: atur apakah CMS perlu defragment sekali setelah menyelesaikan koleksi sampah
• -xx: cmsfullgcbeforecompaction: atur berapa kali koleksi sampah cms dilakukan, dan kompresi memori dilakukan.
• -xx:+cmsclassunloadingenabled: memungkinkan pemulihan metadata kelas
• -XX: CMSInITIingPerMocCupancyFraction: Ketika rasio hunian permanen mencapai persentase ini, mulai pemulihan CMS (asalkan -xx:+cmsclassunloadingEnabled diaktifkan)
• -xx: usecmsinitiatingoccupancyly: berarti pemulihan CMS hanya dilakukan ketika ambang batas tercapai.
• -XX:+CMSINCREMENTALMODE: Gunakan mode tambahan, yang lebih cocok untuk CPU tunggal. Mode tambahan ditandai sebagai dibuang di tengah, dan akan sepenuhnya dihapus di JDK9.
4. Parameter terkait dengan periode pemulihan G1
• -xx:+useg1gc: Gunakan pemulihan G1
• -xx:+maxgcpausemillis: Tetapkan waktu jeda koleksi sampah maksimum
• -XX:+GCPAUSEInterValmillis: Atur interval waktu jeda.
5. Tlab Terkait
• -XX:+USETLAB: Nyalakan alokasi TLAB.
• -xx:+printtlab: cetak informasi alokasi terkait tlab
• -xx: tlabsize: atur ukuran tlab
• -xx:+resizetlab: secara otomatis menyesuaikan ukuran tlab
6. Beberapa parameter lainnya
• -xx:+disablexplicitgc: nonaktifkan GC eksplisit
• -xx:+ExplicitGcinVokesconcurrent: Gunakan konkurensi untuk menangani GC eksplisit
JVM Tomcat Performance Practical (disarankan) di atas adalah semua konten yang saya bagikan dengan Anda. Saya harap Anda dapat memberi Anda referensi dan saya harap Anda dapat mendukung wulin.com lebih lanjut.