Konsumsi Memori JVM


9

Saya mencoba menjalankan kucing jantan pada sistem memori rendah (150-256Mb). Meskipun saya memulai JVM dengan -Xmx64m (yang seharusnya menjadi standarnya), prosesnya langsung memakan waktu 200Mb +.

Saya bertanya-tanya mengapa JVM membutuhkan begitu banyak memori itu sendiri, atau jika ada cara menyetel ini? Apakah JVM lain lebih baik daripada matahari untuk konsumsi memori rendah - dan apakah mereka bekerja dengan kucing jantan?

Jawaban:


5

Selain heap (ditentukan oleh -Xmsdan -Xmx) Anda harus menyertakan area non heap. Ini termasuk

  • Perm Gen, yang 64mb pada sistem 32bit, dan 96mb pada sistem 64bit pada awalnya
  • Kode Cache, yaitu antara 20 dan 40mb tergantung pada JVM
  • Area penyangga NIO (dari mana DirectByteBufferdiambil), ini awalnya 64mb

Ada juga ruang kerja JVM itu sendiri yang akan menjadi beberapa lusin mb.

Anda juga harus mengetahui ukuran otomatis Sun JVM saat menggunakan mesin kelas server . Seiring waktu definisi kelas server (memori 2Gb, lebih dari satu inti) telah mengalami penyusutan dan sekarang sebagian besar mesin mampu memicu -serveroptimisasi. Saran saya adalah selalu menentukan -Xmsdan -Xmxpengaturan dan lulus -serverkecuali Anda tidak bisa memikirkan alasan yang baik juga.


Waspadalah juga terhadap memori Virtual yang hanya dimiliki cadangan JVM, dan belum digunakan.
Steve Schnepp

Benar, sebagian besar segmen ini, seperti PermGen dan Cache Kode dialokasikan pada startup, tetapi kebanyakan kernel akan menghindari mengalokasikan halaman ke segmen tersebut sampai diperlukan.
Dave Cheney

1
Terima kasih atas informasinya - saya pikir ini menjelaskan ke mana memori itu pergi. Apakah ada cara untuk mengubah nilai-nilai ini? Bahkan lebih baik adalah cara untuk melihat seberapa banyak setiap bagian digunakan - saya tidak tahu apakah ada alat debugging / pemantauan Java yang memungkinkan Anda melakukan ini?
Draemon

1
Anda dapat menggunakan pmap, atau jmap untuk mendapatkan ide tentang berbagai segmen yang digunakan. Sebagian besar opsi umum (dan default-nya) tercantum di sini, java.sun.com/javase/technologies/hotspot/vmoptions.jsp . Mereka sering berubah dan tunduk pada perbedaan dalam OS (ukuran tumpukan biasanya) dan lengkungan (OS 64bit umumnya menyiratkan area JVM yang lebih besar)
Dave Cheney

3

Dengan opsi -Xmx Anda membatasi ukuran tumpukan yang cadangan JVM ... Ada sumber daya tambahan yang dibutuhkan JVM ...

"Terima kasih atas memori" * adalah artikel bagus yang menjelaskan bagaimana JVM menggunakan memori ...

Selain itu, Anda dapat mencoba JVM IBM, itu harus bekerja dengan Tomcat, tidak tahu apakah beberapa implementasi JVM gratis berfungsi.

Namun demikian, saya tidak berpikir bahwa mesin dengan memori yang rendah, akan ada gunanya bagimu. Java hanya membutuhkan memori.

* Karena pengguna baru tidak dapat mengirimkan hyperlink, Anda harus mencari sendiri artikel itu ... ini adalah hit pertama di google untuk "terima kasih atas memori ibm".


3
ibm.com/developerworks/java/library/j-nativememory-linux - Tautan ke artikel "Terima kasih atas ingatannya"
StackKrish


0

Salah satu teknik berguna yang saya temukan adalah menggunakan pemantauan JMX untuk melihat dengan tepat berapa banyak memori yang digunakan oleh ruang heap vs permgen.

Siapkan JMX di Tomcat seperti yang dijelaskan di sini http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html

Kemudian gunakan JConsole (dilengkapi dengan JDK 5 atau JDK 6) - tag memori akan melacak konsumsi memori dari waktu ke waktu.

Juga - berhati-hatilah dengan restart lunak webapps. Jika Anda memuat ulang aplikasi web, ruang permgen tidak akan menjadi sampah yang dikumpulkan dan akan menumpuk dari waktu ke waktu. Anda perlu berhenti total / memulai Tomcat untuk mendapatkan kembali ruang permgen.


VisualVM juga dapat digunakan sebagai pengganti JConsole dan memberikan lebih banyak detail saat mencari masalah memori dalam JVM. Saya harus menggunakan ini lebih dari satu kali untuk menemukan masalah.
Jeremy Bouse
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.