Using Java Flight Recorder (JFR) for JVM Applications

[RustamKuramshin]

Привет.

Удивило решение для профилирования JVM приложений - https://perforator.tech/docs/en/guides/jvm.

Использование -XX:+PreserveFramePointer не кажется удачным решением.

Стандартом профилирования JVM является Java Flight Recorder (JFR):

https://docs.oracle.com/en/java/java-components/jdk-mission-control/9/user-guide/using-jdk-flight-recorder.html#GUID-D38849B6-61C7-4ED6-A395-EA4BC32A9FD6

https://dev.java/learn/jvm/jfr/

JFR очень гибкий и настраиваемый, собирает много событий JVM. Можно без проблем строить flame-графы, если есть парсер JFR.
Если JVM рассматривают просто как процесс, то используют async prifiler - https://github.com/async-profiler/async-profiler.
Однако JFR нативно поддерживется начиная с Java 11 и его использование приоритетное.

Аналогичный продукт у Grafana - Pyroscope, для непрерывного профилирования JVM-приложений использует JFR -
https://grafana.com/docs/pyroscope/latest/configure-client/language-sdks/java/

perforator на C++ написан, если я правильно понимаю. Я мог бы законтрибьютить использование JFR, если бы можно было это реализовать на Java или Go, C++ на таком уровне не владею к сожалению.

[MikailBag]

JFR очень гибкий и настраиваемый, собирает много событий JVM

Кажется, это несколько другой кейс. Можно профилировать JVM-специфичные события вроде аллокаций, плохой парковки виртуальных тредов или класслоадинга. Перфоратор сейчас целится в профилирование конкретно CPU, то есть "просто как процесс".

то используют async prifiler

Если рассматривать Java-приложение в отрыве от всего остального, то в данный момент async-profiler, вероятно, будет лучшим вариантом (правда, настроить его доставку и обновление до всех Java-приложений будет сложнее, чем поставить на каждый хост агент перфоратора). Но уровень поддержки мы будем повышать в будущем. Помимо этого, если приложение сочетает Java и нативный код, то на нативном коде будет выигрывать уже перфоратор. Наконец, тут видится возможность кооперации - если научиться автоматически отгружать собранные async-profiler-ом профили в перфоратор, то можно будет из UI удобно смотреть на агрегированные профили по кластеру, и так далее.
В целом, это уже затрагивалось в посте на хабре - даже частичная поддержка непосрественно раскрутки и символизации далее выигрывает от всех языконезависимых возможностей.

Возвращаясь к вопросу о JFR - прямо сейчас мы таким не занимаемся, но на мой взгляд это хороший feature request.

[MikailBag]

Завел #3

perforator на C++ написан, если я правильно понимаю

Вообще хостовый агент написан на Go (на C написана eBPF программа, раскручивающая стэки из контекста ядра, предполагаю что в затрагиваемой интеграции она участвовать не будет).

Но на мой взгляд, в данный момент нужен не код, а дизайн. Например у меня сходу имеются такие вопросы:

• Какие данные собирать? (Не уверен, что все события JFR осмысленны в виде флеймграфов)
• Как их собирать? (Должны ли мы реимплементировать кусок JFR на го, линковаться с ним, запускать как отдельный процесс, что-то еще?)
• Как подмешивать их в профили?

В команде мы это тоже обсудим (но по срокам обещать ничего не могу).

[RustamKuramshin]

JFR встроен в JVM. Есть несколько способ записи снепшотов: через XX-флаги, JMX и jcmd. Через XX-флаги это выглядит примерно так: java -XX:+FlightRecorder -XX:StartFlightRecording=duration=60s,filename=myrecording.jfr MemoryIssue.java
JFR по-умному буферизирует записи событий, они могу храниться на диске или стримиться и обрабатываться программно, в коде. Можно например написать свой java agent, который будет собирать нужные события и отправлять их куда нужно в формате, в котором вы придумаете.

По опыту разбора различных инцидентов с java-сервисами анализ флэйм графа далеко не всегда нужен, возможно если вы свой "фреймворк/очень большую библиотеку" написали и там очень много вашего, кода, который никогда не профилировался локально бенчмарками.

Обычно в продакшне мы имеем дело с использованием heap'а в jvm и OutOfMemory. Нужно смотреть как работал GC, какие объекты в памяти занимают больше всего места и т.п. JFR собирает достаточно событий чтобы с этим разбираться. Например в случае OutOfMemory можно смотреть memory allocation события:

и по ним так же можно построить флэйм граф использования памяти:

Кроме того можно покрыть приложение своими метриками и выводить их через JFR. Условное приложение на Spring Boot принимает запросы, ходит в БД, кэши и смежные сервисы. Можно собирать метрики задержек, чтобы "раскручивать" чего именно мы ждали на запросе в ендпойнт. Но это уже по сути трассировка и есть устоявшиеся решения на grafana stack (loki, tempo, OpenTelemetry).
Смотреть через флейм граф, какой сетевой запрос, сделанный сервисом, внес большую задержку кажется не подходящим решением, потому что это в java-проектах очень давно делают иначе. Или какие методы, делающие запросы в БД, заняли больше времени опять таки странно смотреть через флэйм граф.

Флейм графы с длительностью выполнения методов могут быть полезны, когда есть много логики, которая сильно CPU нагружает. Типовые java-приложения чаще страдают проблемами с использованием памяти, а не CPU.

Поэтому я бы посмотрел в сторону профилирования java-приложений еще и по памяти. А JFR дает столько событий, что там только под них можно сделать отдельный дашборд.