Skip to content
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

Automatically set GOMAXPROCS and GOMEMLIMIT based on available resources (container cgroups / system) #3941

Open
frittentheke opened this issue Sep 9, 2024 · 2 comments
Assignees

Comments

@frittentheke
Copy link

Feature Description

While k6 itself does take the number of CPUs into account, e.g. at

doneInits := e.initVUsConcurrently(subctx, samplesOut, vusToInitialize, runtime.GOMAXPROCS(0), logger)
(planned at
// change the default of cloudapi.MetricPushConcurrency to use GOMAXPROCS(0)
) the value has to be configured manually and explicitly.

So manual adjustments to GOMAXPROCS and GOMEMLIMIT are required to tune K6 to work best with the available resources of the system (hardware, VM, container).

I use k6s on Kubernetes and via the k6-operator and the provided TestRun CustomResource does allow for requests and limits to be configured. While these settings are then applied to the PodSpec, they are not converted or made available to the corresponding golang settings GOMAXPROCS and GOMEMLIMIT.

While this capability could be added to the k6-operator (shout out to @yorugac), to me it makes more sense to enable k6 itself to auto-tune itself to the available resources as it can be run without the k6 operator or non-containerized and will still benefit from these auto-tuning capabilities. There is a similar suggestion for the Grafana Helm chart, also discussing the use of auto-tuning for the options: grafana/helm-charts#3138 (@jnoordsij, @jkroepke)

Therefore I'd like to propose adding automatic config of the Golang runtime via well established golang libs, which are actually
commonly used for other Grafana tools:

GOMAXPROCS

GOMEMLIMIT

There are many examples / MRs for the proposed mechanisms / libraries for other popular tools ....

Suggested Solution (optional)

No response

Already existing or connected issues / PRs (optional)

No response

@olegbespalov
Copy link
Contributor

@grafana/k6-core, what do you think?

@joanlopez
Copy link
Contributor

@grafana/k6-core, what do you think?

I don't have specific experience with these libraries, but it definitely sounds as something that may worth looking at and trying out.
Although it isn't probably something with really high priority, tbh.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants