Если у вас такой же энтузиазм, как и у меня по поводу производительности Java, анализ дампа кучи не должен быть для вас загадкой. Если это так, то хорошей новостью является то, что у вас есть возможность улучшить свои навыки устранения неполадок Java и знания JVM.
В настоящее время JVM эволюционировала до такой степени, что сегодня гораздо проще генерировать и анализировать дамп кучи JVM по сравнению со старым JDK 1.0 — JDK 1.4 дня.
Анализ дампа кучи не следует рассматривать как замену инструментов профилирования и анализа JVM, таких как JProfiler или Plumbr, но дополняющих друг друга. Это особенно полезно при устранении утечек памяти кучи Java и проблем java.lang.OutOfMemoryError.
Этот пост предоставит вам обзор дампа кучи JVM и того, что от него ожидать. Он также предоставит рекомендации о том, как и когда вы должны тратить время на анализ дампа кучи. Будущие статьи будут включать учебники по самому процессу анализа.
Обзор дампа кучи Java
Дамп кучи JVM — это, по сути, «снимок» кучи памяти Java в данный момент времени. Он сильно отличается от дампа потоков JVM, который является снимком потоков.
Такой снимок содержит низкоуровневую информацию о Java-объектах и классах, размещенных в куче Java, таких как:
- Java-объекты, такие как Class, поля, примитивные значения и ссылки
- Данные, относящиеся к загрузчику классов, включая статические поля (важно для проблем с утечкой из загрузчика классов)
- Корни или объекты сборки мусора, доступные вне кучи (системные загрузчики загрузочных классов, такие как rt.jar, JNI или собственные переменные, потоки, локальные Java-объекты и т. Д.)
- Данные и стеки, связанные с потоками (очень полезно для внезапного увеличения кучи Java, особенно в сочетании с анализом дампа потоков)
Обратите внимание, что обычно рекомендуется создавать дамп кучи после полного GC, чтобы исключить ненужный «шум» от объектов, на которые нет ссылок.
Анализ зарезервирован для Элиты?
За последние 10 лет, работая с группами поддержки производства, я заметил одно распространенное заблуждение, что у «элиты» или поставщика продукта зарезервировано такое задание для более глубокого анализа, как профилирование, анализ дампа кучи или потока дампа (Oracle, IBM…) ,
Я не мог не согласиться больше.
Как разработчик Java, вы пишете код, потенциально работающий в среде с высокой степенью параллелизма, управляющей сотнями и сотнями объектов в JVM. Вы должны беспокоиться не только о проблемах параллелизма, но также о сборке мусора и занимаемой памяти вашего приложения. Вы находитесь в лучшем положении, чтобы выполнить этот анализ, так как вы являетесь экспертом приложения.
Ниже приведены типичные вопросы, на которые вы сможете ответить:
- Сколько параллельных потоков необходимо для одновременного запуска моего приложения в соответствии с прогнозом нагрузки? Сколько памяти потребляет каждый активный поток, прежде чем они выполнят свои задачи?
- Какова площадь статической памяти моего приложения? (библиотеки, размер загрузчика классов, структуры данных кэша в памяти и т. д.)
- Какова динамическая память моего приложения под нагрузкой? (следы сессий и т. д.)
- Вы профилировали свое приложение для любой утечки памяти?
Нагрузочное тестирование, профилирование вашего приложения и анализ дампов кучи Java (например, захваченных во время нагрузочного тестирования или производственной проблемы) позволят вам ответить на поставленные выше вопросы. После этого вы сможете достичь следующих целей:
- Снизить риск проблем с производительностью после внедрения производства
- Увеличьте ценность своей работы и своего клиента, предоставив дополнительные указания и факты для команды по производству и управлению производительностью; позволяя им принимать надлежащие меры по улучшению ИТ
- Проанализируйте основную причину утечек памяти или проблем, которые влияют на производственную среду вашего клиента.
- Совершенствуйте свои технические навыки, изучая эти принципы и методы анализа производительности
- Повысьте навыки работы с JVM, улучшив понимание JVM, сборки мусора и жизненных циклов объектов Java
Последнее, чего вы хотите достичь — это умение «плато». Если вы не удовлетворены этим типом анализа, то мои рекомендации приведены ниже:
- Попросите более старшего члена вашей команды выполнить анализ дампа кучи и отследить его работу и подход
- Как только вы почувствуете себя более комфортно, предложите себе выполнить тот же анализ (из другого проблемного случая) и на этот раз попросите более опытного сотрудника отследить вашу аналитическую работу
- В конце концов студент (вы) станет наставником
Когда использовать
Анализ дампов кучи JVM не следует выполнять каждый раз, когда вы сталкиваетесь с проблемой кучи Java, такой как OutOfMemoryError. Поскольку этот процесс анализа может занять много времени, я рекомендую этот анализ для следующих сценариев:
- Необходимость понимания и настройки вашего приложения и / или окружающего API или самого контейнера Java EE.
- Устранение неполадок с утечкой памяти в куче Java
- Утечки памяти загрузчика классов Java
- Внезапные проблемы кучи Java увеличивают проблемы или вызывают события (должны быть объединены с анализом дампа потока в качестве отправной точки)
Теперь найдите ниже некоторые ограничения, связанные с анализом дампа кучи:
- Генерация дампа кучи JVM — это интенсивная вычислительная задача, которая будет зависать на вашей JVM до завершения. Надлежащая должная осмотрительность необходима, чтобы уменьшить влияние на вашу производственную среду
- Анализ дампа кучи не даст вам полного следа памяти процесса Java, например, собственной кучи. Для этого вам нужно будет полагаться на другие инструменты и команды ОС для этой цели
- У вас могут возникнуть проблемы с открытием и анализом дампов кучи, созданных из более старых версий JDK, таких как 1.4 или 1.5.
Методы генерации дампов кучи
Дампы кучи JVM обычно создаются в результате двух действий:
- Автоматически генерируется или срабатывает в результате java.lang.OutOfMemoryError (например, Java Heap, PermGen или истощение собственной кучи)
- Генерируется вручную с использованием таких инструментов, как jmap, VisualVM (через JMX) или команда уровня ОС
# Автоматически запускаемые дампы кучи
Если вы используете HotSpot Java VM 1.5+ или JRockit R28 +, то вам потребуется добавить следующий параметр ниже при запуске JVM:
1
|
-XX:+HeapDumpOnOutOfMemoryError |
Приведенный выше параметр позволит виртуальной машине HotSpot автоматически генерировать дамп кучи после события OOM. Формат дампа кучи для этих типов JVM — HPROF (* .hprof).
Если вы используете IBM JVM 1.4.2+, генерация дампа кучи в результате события OOM включена по умолчанию. Формат дампа кучи для IBM JVM — PHD (* .phd).
# Запущенные вручную дампы кучи
Ручная генерация дампов кучи JVM может быть достигнута как показано ниже:
- Использование jmap для HotSpot 1.5+
- Рекомендуется использовать VisualVM для HotSpot 1.6+ *
** Пожалуйста, сделайте все возможное, чтобы обеспечить должную осмотрительность для вашей производственной среды, поскольку создание дампа кучи JVM — это навязчивый процесс, который повредит ваш процесс JVM до завершения **
Если вы используете IBM JVM 1.4.2, вам потребуется добавить следующие переменные среды при запуске JVM:
1
2
|
export IBM_HEAPDUMP= true export IBM_HEAP_DUMP= true |
Для IBM JVM 1.5+ вам нужно будет добавить следующие аргументы при запуске Java:
1
|
-Xdump:heap |
EX:
01
02
03
04
05
06
07
08
09
10
11
|
java -Xdump:none -Xdump:heap:events=vmstop,opts=PHD+CLASSIC JVMDUMP006I Processing Dump Event 'vmstop' , detail '#00000000' - Please Wait. JVMDUMP007I JVM Requesting Heap Dump using 'C:\sdk\jre\bin\heapdump.20050323.142011.3272.phd' JVMDUMP010I Heap Dump written to C:\sdk\jre\bin\heapdump.20050323.142011.3272.phd JVMDUMP007I JVM Requesting Heap Dump using 'C:\sdk\jre\bin\heapdump.20050323.142011.3272.txt' JVMDUMP010I Heap Dump written to C:\sdk\jre\bin\heapdump.20050323.142011.3272.txt JVMDUMP013I Processed Dump Event 'vmstop' , detail '#00000000' . |
Пожалуйста, просмотрите документацию Xdump для IBM JVM1.5 +.
Для Linux и AIX® сигнал дампа кучи IBM JVM отправляется через kill -QUIT или kill -3. Эта команда ОС запускает генерацию дампа кучи JVM (формат PHD).
Я рекомендую вам просмотреть сводную страницу MAT о том, как получить дамп кучи JVM с помощью различных комбинаций JVM и ОС.
Инструменты анализа дампа кучи
Мой основной рекомендуемый инструмент для открытия и анализа дампа кучи JVM — Eclipse Memory Analyzer (MAT). На сегодняшний день это лучший инструмент для таких участников, как SAP и IBM. Инструмент предоставляет богатый интерфейс и расширенные возможности анализа дампа кучи, включая отчет о подозрении на утечку. MAT также поддерживает форматы дампа кучи HPROF и PHD.
Я рекомендую мой предыдущий пост для краткого руководства по использованию MAT и анализу вашего первого дампа кучи JVM. У меня также есть несколько примеров из практики анализа дампа кучи, полезных для вашего учебного процесса.
Заключительные слова
Я действительно надеюсь, что вам понравится анализ дампа кучи JVM так же, как и мне. В следующих статьях вы узнаете, как анализировать дамп кучи JVM и с чего начать. Пожалуйста, не стесняйтесь оставлять свои комментарии.
Ссылка: Java Heap Dump: Вы готовы к задаче? от нашего партнера JCG Пьера-Хьюга Шарбонно в блоге, посвященном шаблонам поддержки Java EE и руководству по Java .