За редкими исключениями (раз, два << оригинал отформатирован хуже, IMO) статьи про "профилирование" в golang представляют собой перепечатку аннотации к пакету pprof (даже не этой старой статьи) и дальше немного личного опыта про то как (не) удалось с помощью pprof найти проблему. Замечу, что поисковик google судя по всему "сопротивляется" "нубским" запросам. Потому что после некоторого "обучения" с уточняющими формулировками в ответ на "базовый" поиск "golang pprof" начало появляться кое-что интересное. Например, статья довольно известного автора. В общем, ощущается пробел в материалах "среднего" уровня. Когда есть более-менее разумный/рабочий код, он проходит тесты на соответствие модели, имеет документированные ТТХ и вообще всё (почти) хорошо. Потому что всего этого можно добиться и "по старинке", вообще только отладочными сообщениями и соответствующими тестами. Но вот незадача: собранное "изделие" явно где-то "подтекает". (Не как на КДПВ, но всё же.) Потому что (в моём случае) сервис "без состояния", не набирающий кэшей (прямо таки "идеальный передаст") ну ни как не должен за месяц эксплуатации раздуваться на 20+МБ. Я как "не программист" периодически делаю что-то что должно "работать как заявлено". То есть выпускаемый код решает достаточно узкие задачи (что позволяет стабилизировать поведение за разумное время) и сопровождается достаточной для дальнейшей эксплуатации документацией. Короче, зная характеристики "протечки", я мог бы ограничиться документированием и "костылём". Но мне так делать стыдно, потому что задача "найти постоянно проявляющуюся неисправность" решается за ограниченное время. Одного порядка с "закостыливанием". В описываемом далее случае время пришлось потратить на приведение собственной "картины мира" в соответствие с реальностью. И ещё. Возможно, знатоки подскажут в комментариях, до какой степени (порядок величин) безопасно плодить "сирот" в go. Что-то подсказывает мне, что goroutines не обладают свойством бесконечно малой нагрузки на местный шедулер…  Забегая вперёд, для профилирования достаточно периодически куда-нибудь писа́ть "pprof.WriteHeapProfile()". Но есть нюанс: "из коробки" в профиль попадут только аллокации "жирнее" 512кБ. Мне осознание этого факта стоило почти целого рабочего дня (классическое "ЧЯНТД"). Вроде как есть вариант "писа́ть всё": вызывать "WriteTo()" для "кучи" с аргументом "debug=2": Я успел закончить отладку раньше чем разобрался во всех нюансах pprof, так что эксперименты оставляю читателям статьи. Сейчас не найду, но там было примечание что так не делают "из коробки" потому что медленно. Разумеется, ничто не мешает подключить "net/http/pprof" и таскать профили через curl/wget. Хотя, в моём случае опять таки обнаружился нюанс: просто воткнув "http.ListenAndServe()" в конце инициализации, получаем не завершаемый по сигналам процесс. Т.к. сам "ListenAndServe()" сигналов не ловит. Не стесняйтесь воткнуть "go …" для выпуска интерфейса внутри goroutine. Не буду копипастить методики применения pprof (и так весь поиск ими забит). Показываю конкретно то что понадобилось для решения задачи. У меня в коде есть место, которое вызывается раз в несколько минут. Не было бы — воткнул бы последнюю закомментированную строку и стал дёргать дампы через curl. В моём случае память текла крайне медленно (первые 512 кБ набирались за 4…6 часов), поэтому 99% что ищем продолбанные ссылки. В показанном ниже выводе безымянная goroutine "main.apiCall.func1()" успела натаскать себе более 10923 "объектов". (Более, т.к. в профиль попали два "забитых" по 512 кБ блока. А что-то ведь почти наверняка осталось в недозаполненном третьем…) Примерно так это выглядело в момент начала отладки: Как видим, первое "мутное" место ссылается на "commands.UUID" за пределами асинхронной функции (commands объявлен в "родительской" функции). Вроде бы так можно, т.к. в этот момент переменная не "зачищена" и должна быть скопирована в defer. Но всё равно, лучше не лениться и явно протащить копию. Чтобы когда-нибудь потом не подпрыгивать. Как-то так: Зачем я пытался перехватывать SIGKILL ("девятку"), я вам таки не скажу. Видимо, в момент копи-пасты думал о чём-то другом. Наконец, переходим к "сладкому". А течёт-то где? А вот: То есть, для своего модуля я "defer report.DelNotifier()" написать не забыл. А что при выходе из функции никто за меня подписку на "signal.Notify()" не разберёт, в голову не пришло. Потому что в интернетах все кому не лень этот паттерн копипастят, а авторы "os.Signal" "как надо" проиллюстрировать постеснялись. Совсем. Чтобы, видимо, не отлынивали от чтения документации "от корки до корки". В этом, на самом деле, достаточно распространённая ловушка языков с "управляемой памятью". То что по выходе из функции никто не будет разбираться что она там "снаружи" понасоздавала, а просто "занулит" канал со своего конца — не так уж и очевидно. Добавляем в код: Тестируем, через сутки видим: Никто за без малого сутки ничего (заметного) не нацеплял. И это прекрасно. Потому что "транслирующий прокси" так и был задуман. Описывать однопоточные сценарии практически ни на одном ЯП сложностей не представляет. Ходят слухи, что "функциональные" ЯП избавляют и от многих проблем многопоточного программирования (за счёт построения кода "наоборот"). Но я их (почти) не использую, т.к. сам "прикладник" (и черновик решения привык достраивать в "прямом" порядке). В golang, несмотря на весьма удачную реализацию многопоточного процедурного программирования, есть ряд возможностей "нацеплять проблем". Из моей (не самой большой) практики: Отсутствие статического анализатора. Раз уж ошибки асинхронного использования объектов (хотя бы "первого порядка") поддаются анализу "глазами", можно и инструмент сделать. Но — нету до сих пор… Запись в "занулённый" канал из ранее запущенной goroutine (завешивает "навечно" функцию со всеми объектами). "defer …" не в том месте (когда для чего-то часть кода выносится в goroutine, можно напортачить). Создание "асинхронного" объекта во внешнем модуле (вот как "signal.Notify()") без явной его зачистки. Отладка проводилась под go1.14. Но в целом всё справедливо как минимум с версии 1.8. И статически слинкованный бинарник под 1.8 будет процентов на 30 легче. Если не нужны последние фичи. От желания попробовать go1.15 пришлось воздержаться. Потому что пробравшиеся хипстеры резко сломали поддержку X.509 "CommonName" при проверке сертификатов. (Традиционно) не зная, что кроме публичного Интернет есть ещё всякие "закрытые" сегменты, с высокими лагами по внесению изменений. Ну, вот и всё. Приветствуется конструктивная критика и тыканье пальцем "где я дурак". Пользуясь случаем, всех с наступающим 2021 годом! Инженер-конструктор систем массового обслуживания