Какие инструменты кроме трассировки используются для диагностики производительности
Что проверяют
Знаете ли вы, какой инструмент отвечает на какой вопрос: где сгорает CPU, кто аллоцирует, почему горутины стоят. Трассировка показывает события во времени, а сэмплирующий профилировщик показывает, куда уходят ресурсы в сумме. Следом обычно просят описать, как вы снимете профиль с живого сервиса и как докажете, что оптимизация помогла.
Как отвечать
- pprof: главный инструмент. Импорт
_ "net/http/pprof"регистрирует/debug/pprof/, аgo tool pprof -http=:8080с адресом профиля открывает флеймграф и топ функций. Профили:profile(CPU, по умолчанию 30 секунд с частотой 100 Гц),heap(режимыinuse_spaceиalloc_space),allocs,goroutine, а такжеblockиmutex, которые выключены по умолчанию и включаются черезruntime.SetBlockProfileRateиruntime.SetMutexProfileFraction; - бенчмарки:
go test -bench=. -benchmem, профили из теста через-cpuprofileи-memprofile, сравнение до и после черезbenchstatна нескольких прогонах (-count=10); - анализ компилятора:
go build -gcflags=-mпоказывает, какие значения убегают в кучу; - сборщик мусора:
GODEBUG=gctrace=1, пакетruntime/metrics, настройкиGOGCиGOMEMLIMIT; - метрики:
client_golangдля Prometheus сразу отдаётgo_goroutines, паузы GC и память, по ним деградация видна ещё до профилирования; - непрерывное профилирование: Pyroscope или Parca снимают профили постоянно, и можно сравнить картину до релиза и после;
- нагрузка: vegeta, k6 или
hey, чтобы воспроизвести проблему на стенде; - PGO: профиль
default.pgoв каталоге пакетаmainпомогает компилятору оптимизировать горячие пути.
Где спотыкаются
Оптимизируют без профиля, на глаз. Узкое место почти всегда оказывается не там, где его ждали, а без замера эффект нечем показать.
Смотрят только CPU. Если сервис тормозит на блокировках или в ожидании сети, CPU-профиль почти пустой, и нужны block, mutex и goroutine.
Открывают /debug/pprof/ на публичном порту. Эндпоинт должен слушать отдельный внутренний адрес: он раскрывает устройство сервиса и позволяет его нагрузить.