Use the GOGC env value if no configuraiton is used.

This is the opposite?

Yes, the Env var parsing is having to reproduce what Go does internally since this isn't exposed. The source is here.

@roidelapluie The logic flow is a bit hard to follow, let me see if I can refactor it a bit to make it more clear.

@machine424 The reason we want to change the default is that several of us have done reasonably extensive production testing that shows that the additional CPU use for Prometheus is pretty minimal.

Especially as we've made major improvements in the overall rate of allocs over the last few years. If I look at metrics history over the last 2 years, the peak alloc bytes/sec/series is 30-40% of what it used to be.

By reducing the Go default from 100 to 50, we see a significant drop in RSS memory use.

e424 The reason we want to change the default is that several of us have done reasonably extensive production testing that shows that the additional CPU use for Prometheus is pretty minimal.

Especially as we've made major improvements in the overall rate of allocs over the last few years. If I look at metrics history over the last 2 years, the peak alloc bytes/sec/series is 30-40% of what it used to be.

By reducing the Go default from 100 to 50, we see a significant drop in RSS memory use.

Thanks for the context and the details, this looks promising.
Ok, let's give it a try, and if we start yelling about it, we can always adjust or rollback ;)

I've refactored this to create a new top-level runtime section.

Moving the configuration to a separate top level function seems to break the default env var flow. The UnmarshalYAML() seems to not be called if there is no runtime top level key in the config.

Ok, I figured out how to get the empty runtime section to work with the ENV var set.

Good catch!, I’d ask for a regression test for that case, but I think you’ve had enough :).
I’ll add some when I have some time ;)
lgtm