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

Deprecate setting processors to more than available #44889

Merged
merged 5 commits into from
Jul 26, 2019

Conversation

jasontedor
Copy link
Member

@jasontedor jasontedor commented Jul 26, 2019

Today the processors setting is permitted to be set to more than the number of processors available to the JVM. The processors setting directly sizes the number of threads in the various thread pools, with most of these sizes being a linear function in the number of processors. It doesn't make any sense to set processors very high as the overhead from context switching amongst all the threads will overwhelm, and changing the setting does not control how many physical CPU resources there are on which to schedule the additional threads. We have to draw a line somewhere and this commit deprecates setting processors to more than the number of available processors. This is the right place to draw the line given the linear growth as a function of processors in most of the thread pools, and that some are capped at the number of available processors already.

Today the processors setting is permitted to be set to more than the
number of processors available to the JVM. The processors setting
directly sizes the number of threads in the various pool, with most of
these sizes being a linear function in the number of processors. It
doesn't make any sense to set processors more than the number of
available processors, as there will not be any physical CPU resources on
which to schedule the additional threads. This commit deprecates setting
processors to more than the number of available processors.
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

@jasontedor
Copy link
Member Author

This change will be followed up with another to make the breaking change in master.

@jasontedor jasontedor requested a review from jpountz July 26, 2019 07:21
Copy link
Contributor

@jpountz jpountz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with the reasoning. My only reluctance would be if the JVM sometimes gets this number wrong, but I have no idea whether this ever happens in our supported environments?

@jasontedor
Copy link
Member Author

jasontedor commented Jul 26, 2019

My only reluctance would be if the JVM sometimes gets this number wrong, but I have no idea whether this ever happens in our supported environments?

Of course it's possible although I am not aware of an instance of this happening (only the JVM over-stating the number of available processors in some cases, for example, in response to taskset on older JVMs). We will have a deprecation period from the time 7.4 is released to adjust if needed before the breaking change is released from master. Also, the JVM has an escape hatch if ever we are desperate (that we will not document here).

@jasontedor jasontedor merged commit 16a4aa5 into elastic:master Jul 26, 2019
jasontedor added a commit that referenced this pull request Jul 26, 2019
Today the processors setting is permitted to be set to more than the
number of processors available to the JVM. The processors setting
directly sizes the number of threads in the various thread pools, with
most of these sizes being a linear function in the number of
processors. It doesn't make any sense to set processors very high as the
overhead from context switching amongst all the threads will overwhelm,
and changing the setting does not control how many physical CPU
resources there are on which to schedule the additional threads. We have
to draw a line somewhere and this commit deprecates setting processors
to more than the number of available processors. This is the right place
to draw the line given the linear growth as a function of processors in
most of the thread pools, and that some are capped at the number of
available processors already.
@jasontedor jasontedor deleted the processors-more-than-available branch July 26, 2019 08:06
@jpountz
Copy link
Contributor

jpountz commented Jul 26, 2019

👍

jkakavas pushed a commit that referenced this pull request Jul 31, 2019
Today the processors setting is permitted to be set to more than the
number of processors available to the JVM. The processors setting
directly sizes the number of threads in the various thread pools, with
most of these sizes being a linear function in the number of
processors. It doesn't make any sense to set processors very high as the
overhead from context switching amongst all the threads will overwhelm,
and changing the setting does not control how many physical CPU
resources there are on which to schedule the additional threads. We have
to draw a line somewhere and this commit deprecates setting processors
to more than the number of available processors. This is the right place
to draw the line given the linear growth as a function of processors in
most of the thread pools, and that some are capped at the number of
available processors already.
@korjavin
Copy link

What will happen if I start node in k8s with limit set. Will it adjust according to limit or according to CPU on node?

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

Successfully merging this pull request may close these issues.

None yet

5 participants