Размер heapdump против размера hprof

Недавно я сделал heapdump в формате hprof, когда мой сервер jboss работал с xms 4096m и xmx 4096m и permsize 512m.

Сгенерированный файл hprof имеет размер более 5 ГБ. Когда я загружаю heapdump в VisualVM, Mat Analyzer или yourkit, я вижу всего около 1 ГБ в байтах. Я пытался изменить область досягаемости в yourkit, но она показывает не более 1 ГБ.

Любая идея, к чему может привести эта большая разница в размере файла и отображаемом размере кучи?

пс: я использую jdk1.6.0_23

К сожалению, мне не разрешено присылать сюда скриншоты.

В файловой системе размер hprof составляет 5.227.659 КБ, а в yourkit указано:

Объекты: 9.738.282 / неглубокий размер 740 МБ / сохраненный размер: 740 МБ Доступная строка среди них: 6.652.515 (68%) / поверхностный размер: 381 МБ (51%) / сохраненный размер: 381 МБ (51%)

Наибольший сохраняемый размер — это byte[] 206.810.176.


java visualvm heap-dump yourkit hprof
person Michael    schedule 26.07.2012    source источник
comment
Можете ли вы опубликовать скриншот вкладки «Сводка» из VisualVM?   -  person Tomas Hurka    schedule 26.07.2012
comment
Я не могу добавить скриншоты, но я добавил информацию из вашего набора   -  person Michael    schedule 27.07.2012
comment
Данные из YourKit мне не помогают — я не знаю, как они вычисляются. Я знаю, как это делается в VisualVM. Если вы хотите, чтобы я помог вам, предоставьте данные из раздела «Основная информация» (копия находится в контекстном меню) или вы можете загрузить куда-нибудь сжатый дамп кучи и отправить мне ссылку.   -  person Tomas Hurka    schedule 27.07.2012
comment
Привет, Томас, я не могу предоставить вам heapdump из-за ограничений безопасности, но я могу предоставить вам основную информацию: Дата съемки: пятница, 20 июля, 14:23:43 CEST 2012 Файл: OutOfMemoryProd\20120720-20120723\FOFO1\ java_11607_lnx0399vm_201207201423.hprof\java_11607_201207201423.hprof Размер файла: 5 147,4 МБ Всего байтов: 998 064 824 Всего классов: 24 457 Всего экземпляров: 10 241 901   -  person Michael    schedule 30.07.2012
comment
GC roots: 0 - это очень подозрительно. Похоже, что-то не так с дампом кучи.   -  person Tomas Hurka    schedule 30.07.2012
comment
Странно, вряд ли невозможно создать сломанный дамп или что-то в этом роде.   -  person Michael    schedule 30.07.2012
comment
Как я уже сказал, отсутствие корней GC определенно неправильно. Боюсь, что без дампа кучи я не могу сказать, в чем проблема.   -  person Tomas Hurka    schedule 31.07.2012

Ответы (3)


arrow_upward
2
arrow_downward

какую команду вы использовали для создания дампа кучи?

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

возможно, вам нужно пройти живой вариант, согласно спецификации

 -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
Привет, мы используем следующую команду: jmap -F -dump:format=b,file=${filename} $PID . в соответствии с оракулом опция live: если указано, сбрасываются только живые объекты в куче. Поэтому, если я укажу это, heapdump, скорее всего, будет меньше, но также может снизить мои шансы найти причину утечки памяти. - person Michael; 26.07.2012
comment
это действительно хороший вопрос - что такое живой объект? Я предполагаю, что живой объект недоступен для GC. Так что я думаю, что опция live просто удалит мусорные объекты, и у вас будут только живые объекты - это не означает, что это снижает шансы на обнаружение... Недавно я обнаружил несколько утечек памяти с опциями live в действительно огромном дампе (около 16 ГБ) ... - person Andrey Borisov; 26.07.2012
comment
Привет Андрей, спасибо за ответ. Недавно я обнаружил несколько утечек памяти с параметрами live в действительно огромном дампе (около 16 ГБ). Я могу представить, что это может помочь, но все еще не имеет смысла, почему существует такая большая разница между размером hprof на диске и размером инструменты анализатора показывают, когда я загружаю hprof (heapdump) в такие инструменты... - person Michael; 26.07.2012

arrow_upward
2
arrow_downward

Вы пробовали «Гистограмму недоступных объектов» (вы можете найти ссылку в верхней части страницы «Обзор»)? В одном из моих дампов кучи размером 1509 МБ мат показывает только 454 МБ, но остальное, по сути, мусор, и, конечно же, сумма «мелкой кучи» в гистограмме недоступных объектов составляет 966 МБ.

person haridsv    schedule 27.07.2012
comment
Как получить значение указанного типа int Unreachable Objects Histogram? например, я обнаружил, что java.lang.String занимает 500 МБ, но не могу найти, что это за строка. Я могу только получить тип и общий размер типа, но не могу узнать содержимое в Eclipse Memory Analyzer. - person gfan; 20.03.2019

arrow_upward
1
arrow_downward

Это просто означает, что, скорее всего, ваш дамп кучи состоял из большого количества недостижимых объектов, которые были бы удалены сборщиком мусора, если бы GC работал. Теперь это не означает, что у вас все еще нет утечки, это просто означает, что в вашем 5 ГБ Hprof 4 ГБ объектов были недоступны и, следовательно, не были интересными источниками утечки.

В Java утечка памяти может произойти только в том случае, если сборщик мусора не может очистить объект, потому что что-то содержит ссылку на него (неожиданно). Таким образом, ваша утечка (если она есть) должна быть найдена в 1 ГБ объектов, которые остались в вашем файле hprof.

person sfali16    schedule 20.09.2013