Инструмент для анализа больших свалок кучи 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. Он предоставляет ограниченную пробную лицензию. Было очень полезно найти утечки памяти. Вы можете дать ему шанс.