Инструмент для анализа больших свалок кучи Java

У меня есть куча кучи JSM HotSpot, который я бы хотел проанализировать. VM работает с -Xmx31g, а файл дампа кучи имеет размер 48 ГБ.

  • Я даже не попробую jhat, так как это требует примерно пяти раз памяти кучи (это будет 240 ГБ в моем случае) и ужасно медленно.
  • Eclipse MAT сработает с ArrayIndexOutOfBoundsException после анализа дампа кучи в течение нескольких часов.

Какие еще инструменты доступны для этой задачи? Лучше всего будет набор инструментов командной строки, состоящий из одной программы, которая преобразует дамп кучи в эффективные структуры данных для анализа в сочетании с несколькими другими инструментами, которые работают с предварительно структурированными данными.

Ответ 1

Обычно я использую ParseHeapDump.sh включенный в Eclipse Memory Analyzer и описанный здесь, и я делаю это на одном из наших более мощных серверов (загрузите и скопируйте в дистрибутив linux.zip, распакуйте его там). Сценарию оболочки требуется меньше ресурсов, чем анализировать кучу из графического интерфейса, плюс вы можете запустить его на своем мощном сервере с большим количеством ресурсов (вы можете выделить больше ресурсов, добавив что-то вроде -vmargs -Xmx40g -XX:-UseGCOverheadLimit до конца последней строки скрипта. Например, последняя строка этого файла может выглядеть так после изменения

./MemoryAnalyzer -consolelog -application org.eclipse.mat.api.parse "[email protected]" -vmargs -Xmx40g -XX:-UseGCOverheadLimit

Запустите его как ./path/to/ParseHeapDump.sh../today_heap_dump/jvm.hprof

После этого он создает ряд "индексных" файлов рядом с файлом .hprof.

После создания индексов я пытаюсь сгенерировать отчеты по ним и просмотреть эти отчеты на своих локальных компьютерах и попытаться выяснить, смогу ли я найти виновного именно по этому (не только отчеты, но не индексы). Здесь учебник по созданию отчетов.

Пример отчета:

./ParseHeapDump.sh ../today_heap_dump/jvm.hprof org.eclipse.mat.api:suspects

Другие параметры отчета:

org.eclipse.mat.api:overview и org.eclipse.mat.api:top_components

Если этих отчетов недостаточно, и если мне нужно больше копаться (например, пусть, скажем, через oql), я копирую индексы, а также файл hprof на свою локальную машину, а затем открываю дамп кучи (с индексами в том же каталоге, что и свалка) с моим Eclipse MAT GUI. Оттуда ему не нужно слишком много памяти для запуска.

РЕДАКТИРОВАТЬ: Мне просто понравилось добавить две заметки:

  • Насколько я знаю, только генерация индексов является частью Eclipse MAT, интенсивно использующей память. После того, как у вас есть индексы, большая часть вашей обработки в Eclipse MAT не потребует столько памяти.
  • Выполнение этого с помощью сценария оболочки означает, что я могу сделать это на безголовом сервере (и обычно я делаю это также на безголовом сервере, потому что обычно они самые мощные). И если у вас есть сервер, который может генерировать дамп кучи такого размера, скорее всего, у вас есть еще один сервер, который может также обрабатывать большую часть кучи дампов.

Ответ 2

Принятый ответ на этот связанный вопрос должен стать хорошим началом для вас (использует гистограммы live jmap вместо кучи кучи):

Способ обнаружения утечки памяти в больших дампах кучи Java

Большинство других анализаторов кучи (я использую IBM http://www.alphaworks.ibm.com/tech/heapanalyzer), требуется, по крайней мере, процент ОЗУ больше, чем куча, если вы ожидая хороший инструмент графического интерфейса.

Кроме того, многие разработчики используют альтернативные подходы, такие как анализ в реальном стеке, чтобы получить представление о том, что происходит.

Хотя я должен задать вопрос, почему ваши кучи настолько велики? Эффект на сбор и сбор мусора должен быть массивным. Я бы поставил большой процент того, что в вашей куче фактически должно храниться в базе данных/постоянном кеше и т.д. И т.д.

Ответ 3

Я предлагаю попробовать YourKit. Обычно требуется немного меньше памяти, чем размер дампа кучи (он индексирует его и использует эту информацию для получения желаемого)

Ответ 4

Еще несколько вариантов:

Этот человек http://blog.ragozin.info/2015/02/programatic-heapdump-analysis.html

написал собственный анализатор кучи NetBeans, который просто предоставляет интерфейс "стиля запроса" через файл дампа кучи, вместо фактической загрузки файла в память.

https://github.com/aragozin/jvm-tools/tree/master/hprof-heap

Хотя я не знаю, лучше ли "его язык запросов", чем OQL Eclipse, упомянутый в принятом здесь ответе.

JProfiler 8,1 (499 $ за лицензию пользователя) также сказал, чтобы иметь возможность пересекать большие кучи, не используя много денег.

Ответ 5

Первый шаг: увеличьте объем оперативной памяти, которую вы выделяете для MAT. По умолчанию это не очень много, и он не может открывать большие файлы.

В случае использования MAT на MAC (OSX) у вас будет файл MemoryAnalyzer.ini в MemoryAnalyzer.app/Contents/MacOS. Мне не помогло внести изменения в этот файл и заставить их "взять". Вместо этого вы можете создать измененную команду запуска/сценарий оболочки на основе содержимого этого файла и запустить его из этого каталога. В моем случае я хотел 20 ГБ кучи:

./MemoryAnalyzer -vmargs -Xmx20g --XX:-UseGCOverheadLimit ... other params desired

Просто запустите эту команду/скрипт из каталога Contents/MacOS через терминал, чтобы запустить графический интерфейс с большей доступной оперативной памятью.

Ответ 6

Не очень известный инструмент - http://dr-brenschede.de/bheapsampler/ хорошо работает для больших куч. Он работает сэмплированием, поэтому ему не нужно читать все, хотя немного пошло.

Ответ 7

Это не решение командной строки, однако мне нравятся инструменты:

Скопируйте дамп кучи на сервер, достаточно большой для его размещения. Вполне возможно, что оригинальный сервер может быть использован.

Войдите на сервер через ssh -X для удаленного запуска графического инструмента и используйте jvisualvm из двоичного каталога Java для загрузки файла .hprof дампа кучи.

Инструмент не загружает полный дамп кучи сразу в память, но загружает детали, когда они необходимы. Конечно, если вы посмотрите в файл достаточно, требуемая память в конечном итоге достигнет размера дампа кучи.

Ответ 8

Попробуйте использовать jprofiler, он хорошо работает при анализе больших .hprof, я пробовал с размером файла около 22 ГБ.

https://www.ej-technologies.com/products/jprofiler/overview.html

Ответ 9

Я хотел бы описать один из наборов инструментов (сервис) для анализа некоторых проблем на разных экземплярах на основе Java.

Следовательно, вы можете использовать HeapHero, онлайн-инструмент, который обеспечит вам простое представление о вашей системе, и вы можете автоматизировать его с помощью общедоступного REST API.

Ответ 10

Я наткнулся на интересный инструмент под названием JXray. Он предоставляет ограниченную пробную лицензию. Было очень полезно найти утечки памяти. Вы можете дать ему шанс.