ukuran heapdump vs ukuran hprof

Saya baru-baru ini membuat heapdump dalam format hprof ketika server jboss saya berjalan dengan xms 4096m dan xmx 4096m dan permsize 512m.

File hprof yang dihasilkan lebih dari 5GB. Saat saya memuat heapdump di visualvm, mat analizer, atau kit Anda, saya hanya melihat total byte sekitar 1 GB. Saya sudah mencoba mengubah cakupan jangkauan di perangkat Anda tetapi tidak menunjukkan lebih dari 1 gb.

Adakah yang tahu apa yang menyebabkan perbedaan besar dalam ukuran file vs ukuran heapdump yang ditampilkan?

ps: Saya menggunakan jdk1.6.0_23

Sayangnya saya tidak diperbolehkan mengirimkan screenshot di sini.

Pada sistem file, ukuran hprof adalah 5.227.659 kb dan di kit Anda dinyatakan:

Objek: 9.738.282 / ukuran dangkal 740 mb / ukuran dipertahankan: 740 mb String yang dapat dijangkau di antaranya: 6.652.515 (68%) / ukuran dangkal: 381 mb (51%) / ukuran dipertahankan: 381 MB (51%)

Ukuran terbesar yang dipertahankan adalah byte[] dari 206.810.176


java visualvm heap-dump yourkit hprof
person Michael    schedule 26.07.2012    source sumber
comment
Bisakah Anda memposting tangkapan layar tab 'Ringkasan' dari VisualVM?   -  person Tomas Hurka    schedule 26.07.2012
comment
Saya tidak dapat menambahkan tangkapan layar, tetapi saya menambahkan info dari perangkat Anda   -  person Michael    schedule 27.07.2012
comment
Data dari YourKit tidak membantu saya - Saya tidak tahu cara menghitungnya. Saya tahu bagaimana ini dilakukan di VisualVM. Jika Anda ingin saya membantu Anda, berikan data dari bagian 'Info Dasar' (salinannya ada di menu konteks) atau Anda dapat mengunggah heap dump terkompresi di suatu tempat dan kirimkan saya tautannya.   -  person Tomas Hurka    schedule 27.07.2012
comment
Hai Thomas, saya tidak bisa memberi Anda heapdump karena batasan keamanan, tapi saya bisa memberi Anda info dasar: Tanggal diambil: Jum, 20 Juli 14:23:43 CEST 2012 File: OutOfMemoryProd\20120720-20120723\FOFO1\ java_11607_lnx0399vm_201207201423.hprof\java_11607_201207201423.hprof Ukuran file: 5.147,4 MB Total byte: 998.064.824 Total kelas: 24.457 Total instance: 10.241.901 Pemuat kelas: 1.728 Akar GC: 0 Jumlah objek yang menunggu penyelesaian: 0   -  person Michael    schedule 30.07.2012
comment
Akar GC: 0 - ini sangat mencurigakan. Sepertinya ada yang salah dengan heap dump Anda.   -  person Tomas Hurka    schedule 30.07.2012
comment
Aneh, hampir tidak mungkin membuat tempat pembuangan sampah yang rusak atau semacamnya   -  person Michael    schedule 30.07.2012
comment
Seperti yang saya katakan, tidak memiliki root GC jelas salah. Saya khawatir tanpa heap dump saya tidak tahu apa masalahnya.   -  person Tomas Hurka    schedule 31.07.2012

Jawaban (3)


arrow_upward
2
arrow_downward

perintah mana yang Anda gunakan untuk menghasilkan heap dump?

$JAVA_HOME/bin/jmap -dump:live,format=b,file=c:/tmp/heap_dump.bin PID

mungkin Anda perlu melewati opsi langsung, sesuai spek

 -dump:<dump-options> to dump java heap in hprof binary format
                   dump-options:
                     live         dump only live objects; if not specified,
                                  all objects in the heap are dumped.
person Andrey Borisov    schedule 26.07.2012
comment
Hai, kami menggunakan perintah berikut: jmap -F -dump:format=b,file=${filename} $PID . menurut Oracle opsi langsung: Jika ditentukan, hanya objek aktif di heap yang dibuang. Jadi jika saya menentukan ini, heapdump kemungkinan besar akan lebih kecil tetapi mungkin juga mengurangi peluang saya menemukan penyebab kebocoran memori - person Michael; 26.07.2012
comment
ini pertanyaan yang sangat bagus - apa itu benda hidup? saya berasumsi bahwa objek langsung adalah sesuatu yang tidak tersedia untuk GC. Jadi saya kira opsi langsung hanya akan menghapus objek sampah dan Anda hanya akan memiliki objek hidup - ini tidak berarti bahwa ini mengurangi peluang untuk menemukannya... Saya menemukan beberapa kebocoran memori baru-baru ini dengan opsi langsung di dump yang sangat besar (sekitar 16 GB) ... - person Andrey Borisov; 26.07.2012
comment
Hai Andrey, terima kasih atas tanggapan Anda. Saya menemukan beberapa kebocoran memori baru-baru ini dengan opsi langsung di dump yang sangat besar (sekitar 16 GB) Saya dapat membayangkan bahwa ini mungkin membantu tetapi masih tidak masuk akal mengapa ada perbedaan besar antara ukuran hprof pada disk dan ukurannya alat penganalisis muncul ketika saya memuat hprof (heapdump) di alat tersebut... - person Michael; 26.07.2012

arrow_upward
2
arrow_downward

Apakah Anda mencoba "Histogram Objek yang Tidak Dapat Dijangkau" (Anda dapat menemukan tautan dari bagian atas halaman "Ikhtisar")? Di salah satu heapdump saya berukuran 1509MB, mat hanya menampilkan 454MB, tetapi sisanya pada dasarnya adalah sampah, dan tentu saja, jumlah "Timbunan Dangkal" di histogram objek yang tidak dapat dijangkau adalah 966MB.

person haridsv    schedule 27.07.2012
comment
Bagaimana cara mendapatkan nilai tipe tertentu int Unreachable Objects Histogram? misalnya, saya menemukan java.lang.String ditempati 500 juta, tetapi saya tidak dapat menemukan string apa itu. Saya hanya bisa mendapatkan tipenya dan ukuran total tipenya, tetapi tidak bisa mengetahui konten di Eclipse Memory Analyzer. - person gfan; 20.03.2019

arrow_upward
1
arrow_downward

Ini berarti bahwa kemungkinan besar heap-dump Anda terdiri dari sejumlah besar objek yang tidak dapat dijangkau yang akan menjadi sampah yang dikumpulkan, jika GC dijalankan. Hal ini tidak berarti bahwa Anda masih tidak mempunyai kebocoran, itu hanya berarti bahwa dalam Hprof 5 GB Anda, objek sebesar 4 GB tidak dapat dijangkau dan oleh karena itu bukan merupakan sumber kebocoran yang menarik.

Di Java, kebocoran memori hanya dapat terjadi jika Pengumpulan Sampah tidak dapat membersihkan suatu objek karena ada sesuatu yang menyimpan referensi ke objek tersebut (secara tidak terduga). Jadi kebocoran Anda (jika ada) dapat ditemukan pada 1 GB objek yang tersisa di hprof Anda.

person sfali16    schedule 20.09.2013