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

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

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

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

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

./MemoryAnalyzer -consolelog -application org.eclipse.mat.api.parse "$@" -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. Оттуда для работы не требуется слишком много памяти.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Последняя сборка моментальных снимков Eclipse Memory Analyzer имеет возможность случайным образом отбрасывать определенный процент объектов, чтобы уменьшить потребление памяти и позволить анализировать оставшиеся объекты. См. Ошибку 563960 и сборку ночных снимков, чтобы протестировать эту возможность, прежде чем она будет включена в следующий выпуск MAT.

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

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

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

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

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

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

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