Комментарии 9
Я часто пользуюсь SJK для снятия флейм-графов с джава-приложений. У неё есть несколько достоинств:
- не обязательно прописывать дополнительные флаги для приложения, то есть можно снимать прямо на проде;
- не нужен перл-скрипт для получения svg, всё уже есть внутри;
- кроме svg, она умеет выдавать html+js, в котором можно динамически включать-выключать потоки, или, например, посмотреть более крупно только тот стек вызовов, который нас интересует.
Из недостатков можно отметить, что стек не будет включать нативные вызовы ОС (зеленая часть на графиках в статье), но для моих задач возможностей SJK было более чем достаточно.
Упомянутый в статье async-profiler тоже не требует дополнительных флагов JVM, вносит меньший оверхед при профилирования в проде, тоже сам генерирует flame graph без сторонних перл-скриптов, но при этом показывает нативные стеки и стеки ядра. Но главное, лишён проблемы safepoint bias.
Сразу скажу, что мой ответ не для флейма, я просто постараюсь объяснить свою позицию. Я с большим уважением отношусь и к SJK Алексея, и к вашему, Андрей, async-профайлеру.
В SJK мне нравится, во-первых, вывод в html+js, он намного удобнее svg. Он, например, позволяет выделить фрейм, и он подсветится в нескольких стек трейсах, и выдаст суммарную частоту, с которой этот фрейм встречался. И это мне действительно было полезно в работе, когда, например, в сумме по трём стэкам один фрейм встречался с частотой в 77%.
А во вторых, я профилирую энтерпрайз-приложения, которые находятся в зелёной зоне кривой Шипилёва, то есть мне нет никакой необходимости ни в нативных стеках, ни в том, чтобы профайлер был лишён проблемы safepoint bias. Обычно мои перформанс-слонопотамы отнимают 60-80% работы программы. Их с любым профайлером будет видно, просто мне нравятся флейм-графы за их наглядность.
Через функцию Search можно так же подсветить фрейм во всех стеках и увидеть суммарный процент. А начиная с версии 1.8, async-profiler умеет генерировать HTML Flame Graph (на основе Canvas) — такой граф рендерится в десятки раз быстрее, чем svg.
Андрей, приветствую!
Также пользуюсь SJK, также как и коллега выше работаю с Enterprise-приложениями.
А async-profiler может формировать отчетность не на станции, на которой выполняется профилирование, а на машине инженера? Не нашел такой возможности изучив документацию
- collapsed — простейший текстовый формат, который тривиально парсить и фильтровать хоть grep'ом;
- jfr — бинарный формат, совместимый с Java Flight Recorder. Его можно открывать в Mission Control и там уже по-всякому анализировать: по классам, пакетам, потокам, временным интервалам и т. д.
В обоих этих форматах можно объединить несколько профилей простой конкатенацией файлов.
Могу перечислить что нахожу удобным в SJK.
- Неплохая документация. Нет большого количества примеров, часть примеров использования пришлось в свое время подсматривать в тестах инструмента, но она неплохая.
- Явное разделение на процесс сбора метрик и процесс формирования отчета по метрикам. Что очень удобно.
- Работа с Windows и Linux, успешно профилировал службы на JVM 6 для Windows (и они были запущены от SYSTEM, это был отдельный квест), все получилось
- Удобный вывод в виде CSV и текстовых файлов легко передается в InfluxDB, что позволяет организовать непрерывный мониторинг с отображением результатов в Grafana
- Механизм фильтров и опция categorize для меня является очень удобной фичей, позволяя превратить результаты профилирования в статистику, но вот как раз по ней лучшей документацией являются тесты, а сама документация пока непонятная
- Возможность объединить результаты профилирования с нескольких POD-ов/экземпляров приложения в один отчет
За счет фильтров, возможности отдельно собрать sdt-файл статистики и отдельно сформировать отчетность в разной форме от csv до svg и html, возможности работы на Windows/Linux/MacOS сделал удобный способ профилирования:
- Подключиться к серверу
- Запустить там профилирование
- Скачать себе назад результаты профилирования
- Превратить результаты в отчеты.
Отчеты формируются сложные и долго, по 15-20 минут: объединение результатов профилирования с разных POD-ов микросервисов, с использованием массы фильтров — по потокам, по методам сервиса, по отдельным узким местам. Поэтому удобно, что это делается не на самой POD-е, а на моей машине.
Сложности SJK — нет пока документации на categorize, кроме самих исходников:
- https://github.com/aragozin/jvm-tools/blob/jvmtool-umbrella-pom-0.17/sjk-core/src/test/java/org/gridkit/jvmtool/CliCheck.java#L541
- https://github.com/aragozin/jvm-tools/blob/jvmtool-umbrella-pom-0.17/sjk-core/src/test/resources/sample-seam-jsf-profile.ctz
- фича categorize секретная, это думаю сам поправить — сделать PR
Сложности SJK — не запустить профилирование, если есть только JRE, а нет JDK/JDK-devel
- К счастью. В базовых образах Docker, используемых разработчиками на текущем проекте, есть jdk-devel, поэтому SJK тут работает без дополнительных yum install или apk…
- Но если бы в контейнерах был бы только JRE, было бы здорово, чтобы инструмент профилирования мог нести с собой tools.jar или какой-то другой механизм подключаться к JRE-процессам, а не только к JDK/JDK-devel-процессам
Раньше наличие только JRE на станции, где нужно выполнить профилирование, было проблемой. Когда надо было профилировать на продуктиве, а там не было возможности поставить что-то дополнительное — нет прав на это. И приходилось копировать вместе с sjk на станцию и папку с jdk — на Windows способ работает хорошо, а вот на Linux нет одной папки с jdk-devel, там нужны и нативные библиотеки и около 5-6-ти разных пакетов, в общем, не просто
Flame-графики: «огонь» из всех движков