Bagaimana saya bisa memonitor memori JVM dengan benar?


9

Saya sedang memikirkan bagaimana kita melakukan monitor memori JVM dengan cara overhead rendah di lingkungan produksi bahkan di bawah jam sibuk.

Misalkan saya memiliki dua server aplikasi kucing jantan dalam produksi, keseimbangan beban diatur di belakang mereka. Jika saya dapat melihat statistik memori jvm saya dapat memberitahu load balance untuk berhenti mengirim permintaan ke server yang akan mengalami masalah OOM. Apakah ini masuk akal? Jconsole atau VisualVM memakan lebih banyak sumber daya kinerja bukan pilihan saya.


Kerangka Java Simon mungkin terlihat layak.
khmarbaise

Jawaban:



1

Orang lain telah memberikan saran tentang cara memantau penggunaan memori ...

Misalkan saya memiliki dua server aplikasi kucing jantan dalam produksi, keseimbangan beban diatur di belakang mereka. Jika saya dapat melihat statistik memori jvm saya dapat memberitahu load balance untuk berhenti mengirim permintaan ke server yang akan mengalami masalah OOM. Apakah ini masuk akal?

Semacam. Tapi itu belum tentu cara terbaik untuk menyelesaikan masalah Anda.

Mari kita mundur ke akar masalah ... OOME. Dalam konteks Tomcat, OOME kemungkinan disebabkan oleh salah satu dari yang berikut:

  • kebocoran memori di aplikasi Anda, (atau mungkin Tomcat sendiri),
  • mencoba memproses terlalu banyak permintaan secara paralel pada setiap Tomcat, atau
  • permintaan individu yang membutuhkan terlalu banyak memori selama pemrosesan.

Untuk menyelesaikan masalah Anda, pertama-tama Anda perlu mencari tahu mana yang terjadi ... karena solusinya berbeda untuk masing-masing.

1) Untuk melihat apakah ini kebocoran memori, Anda perlu menggunakan alat analisis memori untuk memeriksa pola penggunaan memori jangka panjang. Ini mungkin akan menunjukkan pola gigi gergaji ... yang normal. Yang perlu Anda perhatikan adalah tingkat pantat "gigi" yang cenderung naik seiring waktu. Itu menunjukkan bahwa ada sesuatu yang menciptakan sampah yang tidak dapat dikumpulkan; yaitu kebocoran memori.

Jika Anda memiliki kebocoran memori, maka solusi terbaik adalah mencari tahu bagian mana dari kode Anda yang bertanggung jawab, dan memperbaikinya. Ada hal lain ... termasuk load balancing ... adalah solusi bandaid dan dapat menyebabkan masalah lebih buruk di trek.

2) Setelah menghilangkan kebocoran memori, Anda perlu mencari tahu apakah masalahnya Anda memproses terlalu banyak permintaan sekaligus. Saya tidak yakin cara terbaik untuk melakukan itu, tetapi jika ini masalahnya (atau Anda curiga) maka ada beberapa solusi yang mungkin:

  • Sesuaikan konfigurasi server Tomcat untuk mengurangi jumlah utas pekerja.

  • Jika permintaan Anda terikat I / O, maka kemungkinan lain adalah dengan melihat dukungan penanganan permintaan tidak sinkron yang tersedia dalam versi terbaru dari spesifikasi Servlet - lihat http://docs.oracle.com/javaee/7/tutorial/doc/ servlets012.htm . Tapi itu akan lebih banyak pekerjaan.

3) Jika masalahnya ternyata bahwa permintaan tertentu menggunakan terlalu banyak memori, maka Anda perlu mencari cara untuk mendeteksi permintaan tersebut sebelumnya dan "mengatasinya". Mendeteksi dan menangani permintaan ini bisa sulit ... dan sulit untuk memberi saran tanpa rincian aplikasi Anda. Tetapi beberapa solusi pragmatis adalah:

  • Meneruskan permintaan anomali ke server lain dengan tumpukan besar ... di mana OOME tidak akan mengganggu permintaan "normal".

  • Tambah ukuran tumpukan. Jika Anda memiliki memori fisik yang cukup, menjalankan dengan tumpukan yang lebih besar sebenarnya bisa membuat server Tomcat Anda lebih efisien ... serta menghindari OOME.


Singkatnya, alih-alih mencoba memuat keseimbangan untuk menghindari OOME, saya sarankan Anda mencari tahu mengapa Anda mendapatkan OOME ... dan mencoba menangani penyebab OOME secara langsung.


0

Mungkin jvmtop layak untuk Anda.

Ini menunjukkan Anda dengan cara "seperti-atas" berdasarkan metrik pemantauan per-jvm seperti konsumsi memori, pemanfaatan cpu, jumlah utas dll.

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.