Как стать автором
Обновить

Комментарии 22

Прежде всего, нужно запустить приложение со следующими флагами JVM:
-XX:+UnlockCommercialFeatures
-XX:+FlightRecorder

Эти опции позволят запустить Flight Recorder – утилита, которая поможет собрать информацию об использовании памяти (и много другой важной информации) во время выполнения программы. Я не буду описывать здесь как запустить Flight Recorder, эта информация легко гуглится. В моем случае было достаточно запустить FR на 10-11 минут.

К этому всегда полезно добавлять дисклеймер, о том что эти фичи нельзя использовать в production-окружении не имея коммерческой лицензии на Oracle JDK. Для разработки/отладки JMC использовать можно спокойно.

Спасибо за замечание, добавил предупрежение

Ещё полезная ссылка: http://blogs.atlassian.com/2013/03/so-you-want-your-jvms-heap/


Описано как снимать дапм памяти максимально быстро (в случае если надо снять дамп на проде и нужно минимизировать время простоя). Фактически, при таком способе, скорость создания дампа ограничена только скоростью дисковой подсистемы, что на нормальных серверах весьма приятно.


Результат спокойно открывается в современной версии MAT без предварительных преобразований. Главное чтобы версия JVM совпадала с версией с которой дамп снимался.

Спасибо, изучу материал по ссылке
Затверждаю. Очень полезная метода.
Только так удалось снять дамп с живого прода.

К стати, если делать дамп таким макаром, то там ещё и информация о потоках сохраняется, Это позволяет сразу переходить к списку потоков (большая жёлтая шестерёнка на скриншоте MAT) и смотреть какой поток сколько памяти удерживает и почему. Сокращает время поиска причины утечки памяти буквально до нескольких минут.


Буквально вот только что очередной дамп расковырял. Основное время ушло на перекачку дампа к себе на комп и его индексирование. Далее буквально за пару минут виноватого нашёл.

При использовании Commercial Features надо не забыть купить лицензию на Java SE Advanced Desktop (40$) или Java SE Advanced (5000$) или Java SE Suite (15000$).

Как я говорил выше, для разработки (не в production) можно использовать JRF не имея коммерческой лицензии:


The Java Flight Recorder (JFR) is a commercial feature. You can use it for free on developer desktops/laptops, and for evaluation purposes in test, development, and production environments. However, to enable JFR on a production server, you require a commercial license. Using JMC UI for other purposes on the JDK does not require a commercial license.

https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr002.html

Не думаю, что в этом контексте вообще нужно упоминать про коммерческие фичи. Все это видно и через JMX в том же VisualVM.

Как только вы набрали -XX:+UnlockCommercialFeatures, нужно говорить про коммерческие фичи, если вы сделали это на проде (если говорить в контексте JMC/JFR). Может, конечно, факт неиспользования включенной фичи уменьшит штраф в судебном решении ,)

Статья в стиле «чтобы нарисовать кошку надо нарисовать кружок, потом треугольники ушей, несколько сосисок- лап, а потом дорировать кошку».

Чтобы искать утечку памяти надо глубоко понимать программу, в которой утечки ищутся. Чтобы заметить странность. А как её видеть- объяснить сложно. Временами методика поиска напоминает анекдот про апельсин.
Действительно, в каждой программе могут быть свои особенности утечки памяти, статья показывает лишь общие принципы поиска утечек, которые будут одинаковы для всех программ. Естественно, это не единственный способ, всего лишь один из
А принципиальные отличия/преимущества от VisualVM? Какое-то сравнение с VisualVM можете сделать?
Например такое принципиальное отличие как возможность сделать запись работы VM и потом подробно изучать его. В Visual VM можно смотреть только в реалтайме.
Если речь про JMC — то ещё возможность семплирования (но работает только в safe-points, а это недостоверно).
Если про EMT — то GC-root как-то лучше работает (в visualVM оно то ли не работает, то ли неработоспособно). Но памяти этот зверь кушает- очень хорошо.

PS: apangin вроде как делал своё семплирование, которое работает вне safe-point — но всё ссылку на утилитку не могу найти. Подскажите, кто помнит, пожалуйста :)
Да, только это для профилирования CPU, а не Memory.
https://github.com/apangin/async-profiler

Кстати говоря, на предстоящем JPoint будем с коллегой подробно рассказывать как раз про методики семлирования, и к этому событию приурочу кое-какие интересные обновления в async-profiler… Следите за новостями :)
Сказали о JMC и MAT, а в чем главное отличие не сказали. Для меня главное отличие в том что MAT подходит только для статического анализа дампа. С JMC можно увидеть динамику расхода памяти по методам и к тому же по потокам пока программа еще работает. Это функция бывает незаменима.
> «Пила» все время как бы ползет вверх. Это значит, что какие-то объекты не достижимы для очистки и накапливаются в old space, что со временем приведет к переполнению этой области памяти.

Плохая иллюстрация, мы просто не увидели full GC — который собрал бы мусор, случайно попадающий в old space. Соответственно на хорошей иллюстрации должно быть более одного цикла такого full gc для понимания его динамики.

И, кстати, зачем надо было частично(!) неодинаково(!) замазывать одинаковые(!) имена пакетов на скриншоте? они же легко мержатся и начинают читаться: image
мы просто не увидели full GC — который собрал бы мусор, случайно попадающий в old space


Случайно? В янг спейс не влезло — это сегодня называется «случайно»? При условии, что в дефолтных настройках хип делится в соотношении 1 к 2 (1/3 для янг спейса, 2/3 для олд)
Кстати, в NetBeans есть встроенный профайлер, который позволит сделать (даже в динамике) тоже самое не покидая родную IDE.
Да, это вроде VisualVM.
Только жаль, что в Java6 не работает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории