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