Комментарии 4
Название статьи не соответствует содержимому. "Гайд по поиску и устранению утечек памяти в Go сервисах" - где поиск локализации утечек? Где гайд по устранению утечек? В статье только визуализация утечек в разрезе времени, и ничего больше (для этого и консольного наблюдения достаточно).
Привет минуса :) Как я написал в последнем абзаце "дать конкретные советы невозможно, каждый проект индивидуален", описать все возможные кейсы не реально. Например Мартин Фаулер издал 8 книг с 1996 года в каждой из которых по 400-500 страниц примеров кода и продолжает вести свой блог по рефакторингу и архитектуре. На сайте govnokod.ru сейчас 28 000 записей :)
"консольного наблюдения достаточно" - если мы говорим про команду top, её большой минус это отсутсвие визуализации изменения значения во времени. Можно пропустить тот момент когда было 10 мегабайт потом стало резко 300, потом 20, но 20 ведь тоже не нормально должно же быть 10. Или как понять что происходило с памятью в течении 2х месяцев эксплуатации сервиса в продакшене, кушает ли он память?
Я могу лишь дать базовые советы по отладке. Пишите debug логи в начале и конце функции, например через defer, так вы сможете отследить ее завершение и понять по логам сервиса при каких обстоятельствах он упал или память начала расти. Не стесняйтесь в лог выводить переменные, например идентификатор клиента, который подключился, параметры "флаги" запуска сервиса. Обычно в логах присутствует timestamp, посмотрев на графике, когда начался рост и почитав логи в ELK за этот период, можно будет понять, что примерно происходило в программе и попытаться воспроизвести этот сценарий. Внимательно проверяйте все ли вы открытое закрываете, особенно это хорошо проявляется при отладке graceful shutdown. Например известный кейс с "close response body". Если интерфейс предоставляет метод close или подобный возьмите за правило после его инициализации писать defer *.close()
Продолжать можно бесконечно долго :)
Я могу лишь дать базовые советы по отладке. Пишите debug логи в начале и конце функции,
Это очень плохие советы по отладке, хотя бы потому что для высоконагруженного приложения это сильная потеря производительности, а утечка, такая зараза, такая любит воспроизводиться только в продакшене, потому что там есть какой-то уникальный фактор а вы не знаете какой, рейт создания объектов определённого типа например.
В го прекрасный тулинг: профилировщик выделений памяти прямо из коробки например, который правда ещё придётся научиться читать, а ковырятель coredump'ов (описанный в https://wiki.crdb.io/wiki/spaces/CRDB/pages/1931018299/Using+viewcore+to+analyze+core+dumps) которым в связке с gdb можно найти "утекшие" или по крайней мере слишком популярные объекты.
Как нетрудно догадаться, я через viewcore дебажил отнюдь не CockroachDB, так что это вполне себе универсальный совет.
Спасибо за ответ :) Когда долго чем-то занимаешься забываешь, что очевидные для тебя вещи не очевидны для других.
По поводу логов, логи важны, логи нужны, но они так же могут являться большой проблемой для производительности это факт. Поэтому как минимум нужно поддерживать различный log level в своих сервисах (debug, warning, info, error), ещё лучше использовать специализированные пакеты для логов в которых был сделан упор на производительность. Так же для меня очевидно, что разработка идёт в разных изолированных окружениях local, dev, test, stage, prod. Так вот если на local, dev, test допускается использовать log level = debug, то для stage и prod это уже не допустимо. Так же как не допустимо вылить на stage сервис с memory leak.
Мой совет по debug logs на функции, касается только local и dev окружения. Для stage и prod это не допустимо.
Гайд по поиску и устранению утечек памяти в Go сервисах