-
Notifications
You must be signed in to change notification settings - Fork 8.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add auto-gomaxprocs optional feature #10498
Conversation
Thanks for your contribution. Until the go runtime figures this out, can we have this behind a feature flag rather than having it enabled by default? |
I think having a side-effect caused by |
I agree with @roidelapluie and @bboreham.
Is this a limitation of prometheus-operator specifically, or operators in general? |
Feature flag added. 🙂 |
It depends. Maybe there are some operators which expose env field via theirs CRD. Prometheus-operator doesn't do so. |
I'll add feature description to the documentation tomorrow. |
cmd/prometheus/main.go
Outdated
@@ -186,6 +189,9 @@ func (c *flagConfig) setFeatureListOptions(logger log.Logger) error { | |||
case "promql-per-step-stats": | |||
c.enablePerStepStats = true | |||
level.Info(logger).Log("msg", "Experimental per-step statistics reporting") | |||
case "auto-gomaxprocs": | |||
c.enableAutoGOMAXPROCS = true | |||
level.Info(logger).Log("msg", "Automatically set GOMAXPROCS to cpu.limits when running in container.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this feature flag is enabled, but Prometheus is not running in a container, will the maxprocs.Set
call (below) fail and emit a warning?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'll not fail nor emit warning, it'll leave the default which is equal to number of CPUs.
I'm not sure under which conditions would Set fail. I've added warning for user to know why the GOMAXPROCS is not set when this feature is enabled.
This LGTM besides my comment. Can you please add a note in the Feature Flags documentation? |
Note added. I've tried to describe it, but I'm not sure that it's described good enough. 🙂 Could you have an additional look please? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, thanks! 💪
Do you mind singing commit for DCO bot to work? (Instructions can be found when you click on DCO failure) |
Yay, sure thing! |
Signed-off-by: Tomas Kohout <tomas.kohout1995@gmail.com>
Signed-off-by: Tomas Kohout <tomas.kohout1995@gmail.com>
Signed-off-by: Tomas Kohout <tomas.kohout1995@gmail.com>
Signed-off-by: Tomas Kohout <tomas.kohout1995@gmail.com>
Co-authored-by: Peter Bourgon <peterbourgon@users.noreply.github.com> Signed-off-by: Tomas Kohout <tomas.kohout1995@gmail.com>
Co-authored-by: Peter Bourgon <peterbourgon@users.noreply.github.com> Signed-off-by: Tomas Kohout <tomas.kohout1995@gmail.com>
Signed-off-by: Tomas Kohout <tomas.kohout1995@gmail.com>
Co-authored-by: Julien Pivotto <roidelapluie@gmail.com> Signed-off-by: Tomas Kohout <tomas.kohout1995@gmail.com>
Signed-off-by: Tomas Kohout <tomas.kohout1995@gmail.com>
Thanks! |
That was fast! I should thank you for help. 🙂 |
@TomasKohout I'm not sure where you get the idea that the Prometheus-Operator can't inject env vars. From the CRD API docs
You should easily be able to something like this containers:
- name: prometheus
env:
- name: GOMAXPROCS
value: 16 |
@SuperQ well, that sounds nice, but why should I do something that could break at any time without notice? Edit: IMHO it's better for prometheus to determine GOMAXPROCS automatically from cpu.limits, sorry for misleading information. ;-) |
May I suggest editing the PR title and description to match what was merged? |
Can you please make auto-gomaxprocs configurable from the helm chart also? |
No helm chart in this repo. Probably best to ask wherever the one you use is maintained. |
Signed-off-by: Tomas Kohout tomas.kohout1995@gmail.com
Hi,
this PR is about adding a new dependency on go.uber.go/automaxprocs.
Why we need that?
As you all know nodes come with different sizes. For example, we use quite huge nodes with up to 104 CPUs and because we use prometheus-operator, we aren't able to set environment variables to set GOMAXPROCS to the value of
cpu.limit
. automaxprocs package does this automatically without any additional pain. If there are not limits specified, default value (number of cores) will be left in place.