Размер heapdump vs hprof размер

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

Созданный файл hprof превышает 5 ГБ. Когда я загружаю heapdump в visualvm, анализатор матов или вашkit, я вижу только общие байты приблизительно 1gb. Я попытался изменить область достижимости в yourkit, но он не показывает больше, чем 1 gb.

Любая идея, что может означать эта большая разница в размерах файлов и отображаемых размерах heapdump?

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

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

В файловой системе размер HPROF имеет 5.227.659 кб и YourKit он гласит:

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

Самый большой размер сохранил байт [] в 206.810.176

источник

2012-07-26 Michael

Можете ли вы опубликовать скриншот вкладки «Сводка» из VisualVM? –

Я не могу добавить скриншоты, но я добавил информацию из вашего файла – Michael

Данные из YourKit не помогают мне - я не знаю, как они вычисляются. Я знаю, как это делается в VisualVM. Если вы хотите, чтобы я вам помог, укажите данные из раздела «Основная информация» (копия находится в контекстном меню) или вы можете загрузить скомпилированную кучу кучи где-нибудь и отправить мне ссылку. –

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

$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.

источник

2012-07-26 10:22:12

Привет, мы используем следующую команду: jmap -F -dump: format = b, file = $ {filename} $ PID. в соответствии с oracle вариант в реальном времени: «Если указано, только живые объекты в куче сбрасываются». Поэтому, если я укажу это, heapdump скорее всего будет меньше, но может также уменьшить мои шансы найти причину утечки памяти. – Michael

это действительно хороший вопрос - что такое живой объект? Я предполагаю, что живой объект - это то, что недоступно для GC. Поэтому я предполагаю, что live-вариант просто удалит мусорные объекты, и у вас будут только живые объекты - это не значит, что это уменьшает шансы на поиск ... Недавно я обнаружил несколько утечек памяти с живыми опциями на действительно огромном дампе (около 16 ГБ) ... –

Привет, Андрей, спасибо за ваш ответ. «Недавно я обнаружил несколько утечек памяти с живыми настройками на действительно огромном дампе (около 16 ГБ).« Я могу себе представить, что это может помочь, но по-прежнему не имеет смысла, почему существует такая большая разница между размером hprof на диске и размер инструментов анализатора показывает, когда я загружаю hprof (heapdump) в такие инструменты ... – Michael

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

источник

2012-07-27 07:45:19 haridsv

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

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

источник

2013-09-20 22:02:55 sfali16

ответ

Смежные вопросы