Как диагностировать и отлаживать проблемы с производительностью сервиса?

Что проверяют

Есть ли у вас метод. Ждут порядок действий от симптома к причине, а не список инструментов.

Как отвечать

Опишите последовательность:

• измерить симптом: что именно медленно, на каких ручках, какой процентиль (среднее скрывает проблему, смотреть надо 95-й и 99-й), когда началось, совпадает ли с релизом или ростом нагрузки;
• сузить слой: приложение, база, внешние вызовы или сеть. Быстрее всего это показывает распределённая трассировка: видно, где в запросе уходит время;
• посмотреть на очевидное: медленные запросы в базе (pg_stat_statements), проблема N+1, отсутствующий индекс, блокировки, исчерпанный пул соединений, зависшие внешние вызовы без таймаута;
• проверить память и сборщик мусора: логи сборки (-Xlog:gc*), частота и длительность пауз, растёт ли занятая память после сборки. Долгие паузы дают ровные всплески задержек;
• профилировать: async-profiler или JFR под нагрузкой, чтобы увидеть горячие методы и блокировки. Профиль снимается на боевом или нагрузочном стенде, а не на холостом сервисе;
• посмотреть потоки: дамп через jstack покажет, стоят ли потоки на блокировке или ждут ответа;
• проверить окружение: ограничения контейнера по процессору и памяти, соседи по машине, сеть.

Заканчивайте проверкой: изменение подтверждается замером до и после на той же нагрузке. Оптимизация без измерения это гадание.

Где спотыкаются

Начинают с переписывания кода вместо измерения.

Смотрят на среднее время ответа и не видят проблемы, которая живёт в хвосте распределения.

Профилируют локально на пустой базе, где узкого места нет по определению.