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

[ML] improve reliability of job stats in larger clusters #86305

Merged
merged 3 commits into from
Apr 29, 2022

Conversation

benwtrent
Copy link
Member

When gather job stats for closed jobs, we may be inadvertently executing on a transport thread. Typically, this is acceptable. But, when there are many jobs and many indices, this has a cascading effect and may cause the cluster to enter a troubling state.

This is main due to how slow security checks can be for search requests when the cluster has many indices.

To alleviate, gathering information about closed jobs is forked to the ML utility thread pool

related: #82255

@elasticmachine
Copy link
Collaborator

Pinging @elastic/ml-core (Team:ML)

@benwtrent benwtrent requested a review from droberts195 April 29, 2022 17:58
@elasticsearchmachine
Copy link
Collaborator

Hi @benwtrent, I've created a changelog YAML for you.

@benwtrent
Copy link
Member Author

@droberts195 I did some tests locally printing out the thread names on every call.

Indeed we would be on a transport thread before this change. Meaning we would spin up N requests from that thread pool. Those executions would then occur on the search pool (eventually).

In the call back, we are usually in the search pool, so I decided to fork that as well when gathering data stats (especially since in 7.17 its still multiple searches correct?).

Project Loom cannot come fast enough...

Copy link
Contributor

@droberts195 droberts195 left a comment

Choose a reason for hiding this comment

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

LGTM - thanks for doing this

@benwtrent benwtrent merged commit 4e481c3 into elastic:master Apr 29, 2022
@benwtrent benwtrent deleted the bugfix/job-stats-improvements branch April 29, 2022 20:11
benwtrent added a commit to benwtrent/elasticsearch that referenced this pull request Apr 29, 2022
When gather job stats for closed jobs, we may be inadvertently executing on a transport thread. Typically, this is acceptable. But, when there are many jobs and many indices, this has a cascading effect and may cause the cluster to enter a troubling state.

This is main due to how slow security checks can be for search requests when the cluster has many indices.

To alleviate, gathering information about closed jobs is forked to the ML utility thread pool

related: elastic#82255
@elasticsearchmachine
Copy link
Collaborator

💔 Backport failed

Status Branch Result
8.2
7.17 Commit could not be cherrypicked due to conflicts

You can use sqren/backport to manually backport by running backport --upstream elastic/elasticsearch --pr 86305

@benwtrent
Copy link
Member Author

💚 All backports created successfully

Status Branch Result
7.17

Questions ?

Please refer to the Backport tool documentation

benwtrent added a commit to benwtrent/elasticsearch that referenced this pull request Apr 29, 2022
When gather job stats for closed jobs, we may be inadvertently executing on a transport thread. Typically, this is acceptable. But, when there are many jobs and many indices, this has a cascading effect and may cause the cluster to enter a troubling state.

This is main due to how slow security checks can be for search requests when the cluster has many indices.

To alleviate, gathering information about closed jobs is forked to the ML utility thread pool

related: elastic#82255
(cherry picked from commit 4e481c3)
elasticsearchmachine pushed a commit that referenced this pull request Apr 29, 2022
…6309)

When gather job stats for closed jobs, we may be inadvertently executing on a transport thread. Typically, this is acceptable. But, when there are many jobs and many indices, this has a cascading effect and may cause the cluster to enter a troubling state.

This is main due to how slow security checks can be for search requests when the cluster has many indices.

To alleviate, gathering information about closed jobs is forked to the ML utility thread pool

related: #82255
elasticsearchmachine pushed a commit that referenced this pull request Apr 29, 2022
…6310)

When gather job stats for closed jobs, we may be inadvertently executing on a transport thread. Typically, this is acceptable. But, when there are many jobs and many indices, this has a cascading effect and may cause the cluster to enter a troubling state.

This is main due to how slow security checks can be for search requests when the cluster has many indices.

To alleviate, gathering information about closed jobs is forked to the ML utility thread pool

related: #82255
(cherry picked from commit 4e481c3)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :ml Machine learning Team:ML Meta label for the ML team v7.17.4 v8.2.1 v8.3.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants