Я написал визуализатор сборщика мусора для Go — теперь GC не чёрный ящик

[gohrytt]

Выглядит круто, а что по оверхеду на всю эту красоту?

[timur-developer]

Основной оверхед здесь даёт скорее не сам gcscope, а GODEBUG=gctrace=1,gcpacertrace=1: это встроенный режим для дебага в рантайме Go, который пишет информацию о событиях GC в stderr, а gcscope уже снаружи это читает и визуализирует. Накладные расходы на чтение и парсинг со стороны gcscope обычно заметно меньше, чем нагрузка от самих gctrace и gcpacertrace.
То есть нагрузка близка к обычному использованию gctrace/gcpacertrace без всякой визуализации. Учитывая, что этот режим, как и другие observability инструменты, обычно включают только на время диагностики, его оверхед на практике вполне приемлем. Это такой же временный инструмент наблюдения, как pprof и другие дебаг инструменты.
Если нужны цифры именно для конкретного сервиса, это уже отдельно измеряется нагрузочно, потому что оверхед сильно зависит от частоты срабатывания GC, характера нагрузки и того, насколько дорог вывод в stderr в конкретной среде.

[AbitLogic]

Оптимизация go должна начинаться командой cargo new, а это всё сведётся к купи мне ещё 10 терабайт ОЗУ, мёртвому припарки

[o_O_Tync]

Вот это вы заморочились, респект :)

А как насчёт просто экспортировать метрики для Prometheus и смотреть всё там?

[timur-developer]

Спасибо :)

Да, Prometheus и Grafana это отличный вариант для постоянного мониторинга и просмотра истории работы. Но gcscope я скорее делал для другого сценария: быстро посмотреть конкретный запуск приложения и понять, что GC делал прямо сейчас, без настройки дашбордов.

То есть Prometheus это для полноценного подробного изучения в проде, а gcscope для быстрой диагностики и сравнения запусков.