Комментарии 11
А вы не рассматривали вариант при таких объёмах сделать полный coredump процесса, а потом анализировать его с помощью Serviceability Agent, где уже есть всё необходимое API для вытаскивания классов, тредов, обхода хипа и т. д.?
Хороший вопрос. Открыть coredump можно только на той же версии OS, используя сторого идентичный билд JVM (для Open JDK ещё требуется установка debug символов). JVM Heap dump не зависит от версии JVM и более компактный.
Иногда я снимаю coredump как промежуточный шаг, чтобы сделать из него heap dump (команда jmap может работать с coredump'ами). Если JVM большая, а памяти на системе впритык, такой путь менее болезненый для системы.
Но в целом, использование Servicability Agent — тема интересная. У меня давно крутится идея анализа памяти не по дампу на диске, а по образу памяти. Servicability Agent, в теории, позволяет это сделать.
Иногда я снимаю coredump как промежуточный шаг, чтобы сделать из него heap dump (команда jmap может работать с coredump'ами). Если JVM большая, а памяти на системе впритык, такой путь менее болезненый для системы.
Но в целом, использование Servicability Agent — тема интересная. У меня давно крутится идея анализа памяти не по дампу на диске, а по образу памяти. Servicability Agent, в теории, позволяет это сделать.
вот это да, безопасный управляемый язык, но всё равно требуется дампить память и копаться в мусоре.
Может всё-таки не в языке дело?
Может всё-таки не в языке дело?
Можно примеры языков, где есть возможность дампить память, но это никогда не требуется?
Возможность отладки и исследования памяти это какой-то там недостаток, о чем 'истекает желчь с ваших уст', а ожидаемая фича и как раз управляемость дает нехилые бонусы по копошению в памяти, в частности получить готовый и красивый дамп объектов.
В случае, если интересует только thread dump, можно воспользоваться вот этим скриптом на Python:
https://github.com/gidouin/hprof-tools
>Но полагаю, что дамп такого размера не по зубам ни JVisualVM, ни Eclipse Memory Analyzer, ни другим профайлерам (хотя пробовать я не стал).
Я пробовал некоторые другие (от IBM например). Условия правда были несколько попроще, дамп всего-навсего 16Гб процесса, но и доступной мне памяти было всего 8Гб на рабочей машине.
Выводы в общем неутешительные — для анализа дампа нужно примерно столько же памяти, сколько было на той машине, где его снимали.
Кстати, aragozin, подскажите пожалуйста, а этот процесс построения индекса — он параллелится?
В смысле, если нам допустим доступны обычные настольные машины, где памяти скажем 8Гб, но рядом есть например кластер из машин, и там допустим Hadoop — можно ли организовать процесс анализа дампа в виде map reduce задачки (название map reduce тут условное, это может быть что-то более подходящее для работы с графами)?
Так чтобы на выходе процесса получилось что-то, что уже можно будет спокойно посмотреть и проанализировать на обычной рядовой настольной машинке?
Я пробовал некоторые другие (от IBM например). Условия правда были несколько попроще, дамп всего-навсего 16Гб процесса, но и доступной мне памяти было всего 8Гб на рабочей машине.
Выводы в общем неутешительные — для анализа дампа нужно примерно столько же памяти, сколько было на той машине, где его снимали.
Кстати, aragozin, подскажите пожалуйста, а этот процесс построения индекса — он параллелится?
В смысле, если нам допустим доступны обычные настольные машины, где памяти скажем 8Гб, но рядом есть например кластер из машин, и там допустим Hadoop — можно ли организовать процесс анализа дампа в виде map reduce задачки (название map reduce тут условное, это может быть что-то более подходящее для работы с графами)?
Так чтобы на выходе процесса получилось что-то, что уже можно будет спокойно посмотреть и проанализировать на обычной рядовой настольной машинке?
Файл дампа представляет из себя непрерывную последовательность записей (в основном Java объекты). Объекты в графе ссылаются друг на друга по оригинальным адресам в памяти. Основная функция индекса — поиск смещения в файле дампа по логического адресу объекта.
Интерактивные анализаторы (Visual VM, Eclipse MAT) так же строят индекс обратных ссылок и некоторые другие вспомогательные индексы. Для пакетной обработки эти индексы не так важны, в своей версии я использую только индекс из адреса объекта в смещение.
Построение индекса требует последовательно чтения файла. Потребление памяти при построении индекса — это не фундаментальная проблема, а скорее особенность реализации конкретного профайлера.
Map Reduce теоретически применим для построения дополнительных индексов, но с ними больших проблем и так нет. Параллельный анализ самого графа в теории возможен, но это не задача такого масштаба. 150GiB не такой большой объём, чтобы получить существенный выигрыш от распределённой обработки
Eclipse MAT, кстати, позволяет построить индекс в пакетном режиме через командную строку. Такой индекс можно построить на сервере и скопировать потом на декстоп.
https://wiki.eclipse.org/MemoryAnalyzer/FAQ#How_to_run_on_64bit_VM_while_the_native_SWT_are_32bit
Интерактивные анализаторы (Visual VM, Eclipse MAT) так же строят индекс обратных ссылок и некоторые другие вспомогательные индексы. Для пакетной обработки эти индексы не так важны, в своей версии я использую только индекс из адреса объекта в смещение.
Построение индекса требует последовательно чтения файла. Потребление памяти при построении индекса — это не фундаментальная проблема, а скорее особенность реализации конкретного профайлера.
Map Reduce теоретически применим для построения дополнительных индексов, но с ними больших проблем и так нет. Параллельный анализ самого графа в теории возможен, но это не задача такого масштаба. 150GiB не такой большой объём, чтобы получить существенный выигрыш от распределённой обработки
Eclipse MAT, кстати, позволяет построить индекс в пакетном режиме через командную строку. Такой индекс можно построить на сервере и скопировать потом на декстоп.
https://wiki.eclipse.org/MemoryAnalyzer/FAQ#How_to_run_on_64bit_VM_while_the_native_SWT_are_32bit
> Даже копирование файла такого объёма с сервера на локальный диск уже представляет проблему.
Он ужимается архиватором в разы.
Он ужимается архиватором в разы.
> Несколько итераций с кодированием на Java и запусками скрипта, анализ результатов — и через пару часов я знаю, что именно сломалось в наших структурах данных.
из всей статьи я так и не понял, как именно вы узнали, что именно сломалось в ваших структурах данных? какие признаки и следы вы искали?
из всей статьи я так и не понял, как именно вы узнали, что именно сломалось в ваших структурах данных? какие признаки и следы вы искали?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Итак, мы сделали дамп JVM на 150 Гб. Что дальше?