Setelah mengganti sistem operasi komputer yang berfungsi dengan Win7, myeclipse saya tidak memuaskan dalam startup dan kecepatan berjalan. Terutama ketika memodifikasi dan men -debug beberapa templat halaman secara bersamaan, beralih di antara dua file akan selalu macet selama sekitar sepuluh detik. Mencoba mematikan berbagai plugin dan memverifikasi tidak akan membantu. Jadi setelah secara kasar mempelajari JVM, saya memutuskan untuk mencoba menyelesaikan masalah ini dari perspektif JVM.
Mulai Optimalisasi:
Pertama, mari kita lihat parameter startup default di myeclipse.ini:
-Xmx512m: Atur nilai memori heap maksimum ke 512m
-Xx: maxpermsize = 256m: Tetapkan nilai maksimum generasi persisten ke 256m
-Xx: cadangancodecachesize = 64m: atur ukuran memori yang ditempati oleh kode ke 64m
Tidak ada yang bisa dilihat dari parameter startup, jadi tambahkan parameter yang relevan untuk mencetak perubahan memori:
-Xx:+printgcTimestamps: Cetak waktu waktu setiap GC
-Xx:+printgcdetails: cetak informasi terperinci untuk setiap GC
-Xloggc: myeclipsegc.log: Output GC Records to File
-Verbose: GC: output Situasi yang relevan dari setiap GC
Kemudian mulailah myeclipse dan periksa informasi di myeclipsegc.log:
Startup membutuhkan waktu sekitar 30 detik. Secara selektif mencegat sebagian kecil log. Anda dapat melihat bahwa dalam 10 detik pertama startup Myeclipse, JVM mengeksekusi lebih dari 300 GC dan 9 GC penuh.
Dari frekuensi dan informasi GC, dapat dilihat bahwa laju pemulihan memori sangat tinggi dan ukurannya terus -menerus disesuaikan. Ini harus disebabkan oleh ruang yang tidak mencukupi pada generasi muda, dan nilai awal yang cukup besar diperlukan.
Kemudian fokus pada GC penuh:
Salin kode sebagai berikut: 5.961: [GC penuh 5.961: [Tenured: 34568K-> 34456K (49676K), 0.1397651 dtk] 35336k-> 34456K (53452K), [Perm: 26623k-> 2648K (53452K), [Perm: 26623k-> 2648K (53452K), [266623K-> 2648K (53452K), [Waktu: pengguna = 0,14 sys = 0,00, nyata = 0,14 detik]
9.030: [GC Full 9.030: [Tenured: 53310K-> 52332k (64588k), 0.2034757 Secs] 56020k-> 52332k (69516K), [Timess.1030303030.3.3030.30.303, [43008K), [43008K), [43008K), [43008K), [43008k), [43008K), [43008K), [43008K), [43008K (43008K), [43008K), [43008K (43008K (4300. sys = 0,00, nyata = 0,20 detik]
Dari perbandingan dua log, kita dapat melihat bahwa GC penuh terutama mendaur ulang dua area bertenor dan perm, dan ukuran kedua area ini terus -menerus disesuaikan, jadi kami memutuskan untuk memperbaiki ukurannya terlebih dahulu.
Jadi parameter yang disesuaikan adalah sebagai berikut:
-Xms512m: Atur nilai minimum tumpukan ke 512m
-Xmn192m: Tetapkan ukuran generasi muda ke 192m
-Xx: Permsize = 192m: Tetapkan nilai awal generasi persisten ke 192m
-Xx: maxpermsize = 192m
-Xx: cadangancodecachesize = 64m
-Xx:+printgcTimestamps
-Xx:+printgcdetails
-Xloggc: myeclipsegc.log
-Verbose: GC
Restart myeclipse sekali untuk melihat informasi log:
Startup memakan waktu sekitar 12 detik. Dari log, dapat dilihat bahwa hanya 5 GC yang dilakukan dalam 10 detik pertama, dan tidak ada penyesuaian dengan ukuran masing -masing area yang terlibat. Hasil ini dapat diterima karena tidak perlu sering restart selama bekerja.
Optimalisasi kecepatan respons kerja:
Selanjutnya, saya mempelajari penundaan dan masalah kartu besar yang sering ketika beralih file HTML bolak -balik yang telah mengganggu saya untuk waktu yang lama. Untuk mempelajari perubahan memori JVM secara lebih intuitif, saya memutuskan untuk menggunakan JConsole, alat pembantu yang dilengkapi dengan Java. Pertama -tama kembalikan parameter myeclipse.ini untuk menghindari gangguan dari tahap pertama optimasi.
Mulailah myeclipse, mulailah JConsole dan sambungkan ke JVM di mana myeclipse berada. Diagram memori seluruh tumpukan setelah kandang adalah sebagai berikut:
Selanjutnya coba buka beberapa templat dan kemudian amati perubahan memori.
Pertama -tama, penggunaan keseluruhan memori heap:
Dapat dilihat bahwa setelah membuka beberapa templat, penggunaan memori heap tiba -tiba meningkat dari aslinya di bawah 100m menjadi lebih dari 300m. Penggunaan telah meningkat tiga kali lipat, tetapi masih dalam kisaran 512m yang saya tetapkan. Oleh karena itu, Anda dapat sementara tidak mempertimbangkan untuk terus meningkatkan memori tumpukan, tetapi sebaliknya mempertimbangkan untuk menyesuaikan rasio ukuran memori dari masing -masing zona.
Jadi kami mengamati penggunaan memori dari setiap zona selama periode ini, di antaranya zona Eden adalah sebagai berikut:
Tingkat penggunaan memori dari area Eden meningkat secara signifikan selama periode ini, dan GC terjadi beberapa kali. Melalui informasi pemantauan di bawah ini, kita dapat mengetahui bahwa secara default, area Eden hanya mengalokasikan 31m memori maksimum, yang jelas tidak cukup. Eksekusi titik kecil akan memicu GC di area Eden. Ini harus menjadi salah satu alasan penundaan lag dalam sakelar pembukaan template dan perlu disesuaikan.
Berikutnya adalah area bertenor:
Ruang maksimum yang dialokasikan oleh JVM ke area ini secara default adalah 470m. Ketika perubahan penggunaan memori, ukuran sebenarnya dari area ini terus -menerus disesuaikan. GC penuh akan terjadi setiap kali ukuran area disesuaikan, yang harus menjadi salah satu alasan untuk seringnya blok besar. Pembukaan template baru adalah alasan utama untuk memicu penyesuaian ini. Dari perspektif penggunaan memori di area ini, masih perlu untuk mempertahankan sejumlah redundansi dengan mempertahankan dan memperbaiki ruang memori di area ini sekitar 450m.
Dari sudut pandang ini, masih perlu untuk memperluas memori tumpukan JVM untuk mempertahankan area bertenor yang lebih besar dan area Eden.
Akhirnya, mari kita lihat area perm:
Sebagai bagian dari area metode, perubahan memori di area ini tidak besar dan relatif stabil, jadi tidak perlu meninggalkan terlalu banyak redundansi. Namun, mengingat bahwa volume kode aktual dari proyek yang saat ini dibuka tidak besar, diputuskan untuk sementara mempertahankannya sekitar 128m dan perlahan -lahan menyesuaikannya di masa depan.
Jadi menurut analisis di atas, parameter disesuaikan dengan:
-Xmx768m
-Xms768m
-Xmn256m
-Xx: Permsize = 192m
-Xx: maxpermsize = 192m
-Xx: cadangancodecachesize = 64m
Restart myeclipse, sambungkan ke jconsole, dan buka tiga puluh templat pada saat yang sama untuk melakukan tes. Saat melihat laju penggunaan memori dari setiap zona, saya menemukan masalah. Setelah menyesuaikan generasi muda hingga 256m, karena Eden tidak lagi sering terjadi di GC, jumlah data yang memasuki area bertenor berkurang secara signifikan. Diagram penggunaan memori dari area bertenor adalah sebagai berikut:
Seperti yang ditunjukkan pada gambar di atas, ketika banyak templat dengan sengaja dibuka, ruang 450m+ hanya menggunakan kurang dari 250m, dan laju pemanfaatan ruang terlalu rendah, sehingga penyesuaian perlu dilakukan.
Meringkaskan
Di atas adalah beberapa ide dan proses penyetelan yang sebenarnya bagi saya untuk menyetel myeclipse saya. Dalam penggunaan aktual, saya membuat beberapa penyesuaian dan penyesuaian sesuai dengan preferensi saya. Parameter terakhir myeclipse.ini adalah sebagai berikut:
-VMargs
-Xmx512m
-Xms512m
-Xmn192m
-Xx: Permsize = 128m
-Xx: maxpermsize = 128m
-Xx: cadangancodecachesize = 64m
Di bawah pengaturan parameter ini, kecepatan respons myeclipse relatif dijamin, dan frekuensi berbagai keterlambatan lag sangat berkurang. Kerugiannya adalah bahwa memori sistem yang ditempati oleh penduduk tetap relatif tinggi. Siswa yang suka membuka beberapa myeclipse pada saat yang sama dapat membuat penyesuaian yang tepat sesuai dengan kebutuhan dan kondisi aktual mereka.
Di atas adalah semua tentang artikel ini, saya harap ini akan membantu untuk pembelajaran semua orang.