Какие инструменты профилирования Java-приложений на production?

А, ну вот, профилирование на продакшене, блядь! Это как ходить по охуенно тонкому льду, понимаешь? С одной стороны, надо понять, где у тебя тормозит, а с другой — не положить всё нахуй своими же инструментами. Ёпта, сейчас разложу по полочкам.

1. Java Flight Recorder (JFR) + Java Mission Control (JMC)

Это, можно сказать, штатная пиздатка от Oracle, но реально годная. Накладные расходы — 1-2%, как муха на лобовом стекле. Не то чтобы прям нихуя, но и не овердохуища.

# Запуск JFR для работающего приложения
jcmd <PID> JFR.start name=prod_profile duration=60s filename=/tmp/prod.jfr

# Постоянная запись с дампом при инциденте
java -XX:StartFlightRecording=settings=profile 
     -XX:FlightRecorderOptions=repository=/tmp/jfr 
     -jar application.jar

Смотри, что он тебе покажет, этот ядрёна вошь:

• CPU: Какие методы жрут проц, как там аллокации прут.
• Memory: Что там GC вытворяет, не пытается ли он всю память в трубу выдуть.
• I/O: Кто и как сильно читает-пишет.
• Locks: Где потоки друг другу еблана ставят, кто кого блокирует. Deadlock'и, блядь, самые любимые.

2. Async-Profiler (профилирование с низкими накладными расходами)

Вот это, сука, мастхэв для любого, у кого руки не из жопы. Овердохуища низкие накладные.

# CPU profiling
./profiler.sh -d 30 -f /tmp/flamegraph.html <PID>

# Allocation profiling
./profiler.sh -d 30 -e alloc -f /tmp/alloc.html <PID>

# Lock contention profiling
./profiler.sh -d 30 -e lock -f /tmp/lock.html <PID>

Flame graph'ы — это вообще песня. Смотришь и сразу видно, где у тебя пиздец горит, а где просто тлеет.

3. Диагностика через дампы

Старый добрый способ, когда уже припёрло и надо ковыряться в кишках.

# Heap dump для анализа утечек памяти
jmap -dump:live,format=b,file=/tmp/heap.hprof <PID>

# Thread dump для анализа deadlocks
jstack <PID> > /tmp/threads.txt
# Или через сигнал
kill -3 <PID>

Только вот, чувак, с jmap осторожнее, он может всё на пару секунд подвесить. В самый пик нагрузки такое вытворять — это чих-пых тебя в сраку, можно пользователей разогнать.

4. APM-системы (Continuous Profiling)

Это для богатых и ленивых, или для тех, у кого терпения ноль ебать всё руками делать.

• Datadog APM: Там профилирование постоянное, трассировка распределённых систем — красота, но стоит, блядь, как чугунный мост.
• New Relic: Аналогично, профилирование потоков, анализ запросов к базе.
• Pyroscope: Опенсорсный вариант, можно профили хранить и сравнивать — «а вот вчера работало, а сегодня — хуй с горы».

Best Practices для production или «как не обосраться»

1. Короткие сессии: Не включай профилирование на сутки, блядь. 30-60 секунд во время пиковой нагрузки — и хватит. Как будто быстрый укол в жопу, а не долгая пытка.
2. Сэмплирование вместо инструментирования: Используй Async-Profiler, а не вот это вот всё -XX:+ExtendedDTraceProbes. Первое — это как послушать разговор ухом к двери, второе — как вломиться в комнату с диктофоном. Разницу чувствуешь?
3. Фокус на проблемах:
   • High CPU? CPU profiling + flame graphs. Ищи, кто греет процессор.
   • Memory leaks? Heap dumps + MAT (Eclipse Memory Analyzer). Кто не отпускает память, тот пидарас шерстяной.
   • Slow requests? Tracing + JFR method profiling. Где запрос пиздюлей получает.
4. Безопасность, ёпта! Не раздавай доступ к jcmd и jstack всем подряд. И дампы с паролями и сессиями пользователей не валяй в открытом доступе, а то сам от себя охуеешь потом.
5. Автоматизация — наше всё: Привяжи сбор дампов к алертам в мониторинге. Сервер начал дико лагать? Пусть система сама снимает thread dump и шлёт тебе в телегу. Волнение ебать, но работать будет.

И главное, блядь, ЗАПОМНИ: Всегда сначала пробуй эту всю хуйню на staging-среде. Прийти на прод с незнакомым инструментом — это как зайти в тёмный подъезд в незнакомом районе. Подозрение ебать чувствую, что кончится всё плохо.