Приходилось ли работать с профилированием в Go

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

Работали ли вы с pprof руками и понимаете ли, какой профиль отвечает на какой вопрос. Заодно проверяют дисциплину измерения: сравнивали ли вы состояние до и после или оптимизировали по ощущениям.

Как отвечать

Опишите порядок. Сначала метрика, которая показывает проблему: задержка, потребление процессора, растущая память. Затем профиль нужного вида:

• CPU-профиль, если время уходит на вычисления;
• heap, причём inuse_space для поиска утечки и alloc_space для давления на сборщик мусора;
• goroutine, если горутины копятся и не завершаются;
• block и mutex для ожидания на каналах и блокировках, их надо включать явно через SetBlockProfileRate и SetMutexProfileFraction;
• go tool trace, когда нужна картина по планировщику и паузам сборщика.

Инструменты: net/http/pprof в сервисе на внутреннем порту, бенчмарки с флагами профилирования, разбор через go tool pprof командами top и list.

go test -run=^$ -bench=. -benchmem -cpuprofile=cpu.out
go tool pprof -http=:6060 cpu.out

Результат подтверждайте повторными бенчмарками и статистическим сравнением. Находки называйте конкретные: аллокации в горячем цикле, слайс без заранее заданной ёмкости, склейка строк вместо strings.Builder, регулярное выражение, компилируемое на каждый вызов.

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

Ищут в CPU-профиле причину медленных запросов к базе. Ожидание сети процессор не нагружает, график окажется почти пустым, а искать надо в трассировке, block-профиле и метриках самой базы.

Второе: путают inuse_space и alloc_space. Первый показывает, что удерживается прямо сейчас, второй сумму за всё время работы. Утечку ищут по первому, нагрузку на сборщик мусора по второму.

Третье: один прогон до и один после, разница в пару процентов объявляется победой. Без повторов и статистики вы измерили фоновую активность своей машины, а не эффект правки.