Для этого будет использован реальный пример из практики: утечка памяти в Weblogic 9.2, влияющая на сервер администратора Weblogic.
Спецификации окружающей среды
- Сервер Java EE: Oracle Weblogic Server 9.2 MP1
- Промежуточное программное обеспечение ОС: Solaris 10
- Java VM: Sun HotSpot 1.5.0_22
- Тип платформы: Средний уровень
Инструменты мониторинга и устранения неполадок
- Quest Foglight (JVM и мониторинг сборки мусора)
- jmap (hprof / инструмент создания дампа кучи)
- Memory Analyzer 1.1 через помощника поддержки IBM (анализ дампа кучи hprof)
- Тип платформы: Средний уровень
Шаг № 1 — WLS 9.2 Контроль JVM сервера администрирования и подтверждение утечки
Инструмент мониторинга Quest Foglight Java EE был весьма полезен для выявления утечки кучи Java с нашего сервера Weblogic Admin. Как вы можете видеть ниже, память кучи Java со временем растет.
Если вы не используете какой-либо инструмент мониторинга для своей среды Weblogic, я рекомендую вам, по крайней мере, включить verbose: gc вашей виртуальной машины HotSpot. Пожалуйста, посетите мой учебник Java 7 verbose: gc по этому вопросу для получения более подробных инструкций.
Шаг № 2 — Создайте дамп кучи из вашей утечки JVM
После обнаружения утечки памяти JVM цель состоит в том, чтобы создать файл дампа кучи (двоичный формат) с помощью утилиты Sun JDK jmap.
** обратите внимание, что генерация дампа кучи jmap приведет к тому, что ваша JVM перестанет отвечать на запросы, поэтому перед запуском утилиты jmap убедитесь, что на вашу уязвимую / текущую JVM больше не отправляется трафик **
|
1
|
<JDK HOME>/bin/jmap -heap:format=b <Java VM PID> |
Эта команда сгенерирует двоичный файл дампа кучи (heap.bin) вашей утечки JVM. Размер файла и истекшее время процесса генерации будут зависеть от размера вашей JVM и технических характеристик / скорости машины.
В нашем случае мы создали двоичный файл дампа кучи размером ~ 2 ГБ за 1 час.
Файл Sun HotSpot 1.5 / 1.6 / 1.7 также генерируется автоматически в результате OutOfMemoryError и путем добавления -XX: + HeapDumpOnOutOfMemoryError в аргументы запуска JVM.
Шаг № 3 — Загрузите файл дампа кучи в инструмент анализа памяти
Теперь пришло время загрузить файл дампа кучи в инструмент анализатора памяти. Процесс загрузки займет несколько минут в зависимости от размера вашего дампа кучи и скорости вашей машины.
Шаг № 4 — Проанализируйте свой дамп кучи
Анализатор памяти предоставляет вам множество функций, в том числе отчет о предполагаемой утечке. В этом примере гистограмма кучи Java использовалась в качестве отправной точки для анализа протекающих объектов и источника.
Для нашего примера использования java.lang.String и char [] были найдены как утечка объектов. Теперь вопрос в том, что является источником утечки, например, ссылки на те утечки Объектов. Просто щелкните правой кнопкой мыши по текущим объектам и выберите >> Список объектов> с входящими ссылками
Как видите, объекты javax.management.ObjectName были найдены в качестве источника утечек данных String & char []. Сервер Weblogic Admin передает и получает статистику со своих управляемых серверов через MBeans / JMX, которые создают javax.management.ObjectName для любого типа объекта MBean. Теперь вопрос в том, почему Weblogic 9.2 не выпускает должным образом такие объекты …
Основная причина: утечка Weblogic javax.management.ObjectName!
После нашего анализа дампа кучи был выполнен обзор известных проблем Weblogic, которые выявили следующую ошибку Weblogic 9.2 ниже:
- Weblogic Bug ID: CR327368
- Описание: Утечка памяти объектов javax.management.ObjectName на Сервере администрирования, которая вызвала ошибку OutOfMemory на Сервере администрирования.
- Затронутые версии Weblogic: WLS 9.2
- Исправлено в: WLS 10 MP1
http://download.oracle.com/docs/cd/E11035_01/wls100/issues/known_resolved.html
Этот вывод был довольно убедительным, учитывая идеальное соответствие нашего анализа дампа кучи, версии WLS и этого известного описания проблемы.
Вывод
Я надеюсь, что это руководство вместе с примером поможет вам понять, как вы можете точно определить источник утечки кучи Java с помощью jmap и инструмента Memory Analyzer.
Пожалуйста, не стесняйтесь оставлять комментарии или вопросы.
Я также предоставил бесплатную консультацию по Java EE, поэтому, пожалуйста, просто напишите мне по электронной почте и предоставьте ссылку для загрузки вашего файла дампа кучи, чтобы я мог проанализировать его для вас и создать статью в этом блоге, чтобы описать вашу проблему, первопричину и решение.
Ссылка: HPROF — учебное пособие по анализу утечек памяти от нашего партнера по JCG Пьера-Хьюга Шарбонно из блога учебного курса по шаблонам поддержки Java EE и Java .