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

Introduce a search_throttled threadpool #33732

Merged
merged 12 commits into from Sep 20, 2018

Conversation

s1monw
Copy link
Contributor

@s1monw s1monw commented Sep 15, 2018

Today all searches happen on the search threadpool which is the correct
behavior in almost any case. Yet, there are exceptions where for instance
searches searches should be passed through a single-thread
threadpool to reduce impact on a node. This change adds a index-private setting that allows to mark an index as throttled for searches and forks off all non-stats searcher access to this threadpool for indices that are marked as index.search.throttled

Today all searches happen on the search threadpool which is the correct
behavior in almost any case. Yet, there are exceptions where for instance
searches are required to succeed ie. in the case of a .security index.
These searches should not be rejected if a node is under load. There are other
more specialized usecases were searches should be passed through a single-thread
threadpool to reduce impact on a node.

Relates to elastic#33205
@s1monw s1monw added >enhancement :Search/Search Search-related issues that do not fall into other categories v7.0.0 v6.5.0 labels Sep 15, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search-aggs

@s1monw
Copy link
Contributor Author

s1monw commented Sep 15, 2018

the majority of the change is cutting SearchService over to async execution. The actual addition of the setting and such is really a smallish change.

Copy link
Member

@tlrx tlrx left a comment

Choose a reason for hiding this comment

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

LGTM - I didn't expect this change to be so simple.

cleanContext(context);
}
public void executeQueryPhase(InternalScrollSearchRequest request, SearchTask task,
ActionListener<ScrollQuerySearchResult> listener) {
Copy link
Member

Choose a reason for hiding this comment

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

Nit: ident

this.canMatch = canMatch;
}


Copy link
Member

Choose a reason for hiding this comment

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

Nit: extra line

@jpountz
Copy link
Contributor

jpountz commented Sep 17, 2018

I'm curious why we now fork can_match tasks unless the default threadpool is used, what is the benefit compared to never forking?

}
if (ThreadPool.Names.SEARCH.equals(s) == false && ThreadPool.Names.GENERIC.equals(s) == false &&
ThreadPool.THREAD_POOL_TYPES.containsKey(s)) {
throw new IllegalArgumentException("Invalid valid for [index.search.threadpool] - " + s + " is a reserved built-in " +
Copy link
Member

Choose a reason for hiding this comment

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

valid -> value

Copy link
Member

@jasontedor jasontedor left a comment

Choose a reason for hiding this comment

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

I have some concerns.

if (s == null || s.isEmpty()) {
throw new IllegalArgumentException("Value for [index.search.threadpool] must be a non-empty string.");
}
if (ThreadPool.Names.SEARCH.equals(s) == false && ThreadPool.Names.GENERIC.equals(s) == false &&
Copy link
Member

Choose a reason for hiding this comment

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

I really do not like that these can go on the generic thread pool. This thread pool can be quite large (we only recently bound it but it's a really large bound) and it has no queue. Especially since the need for this only arises if the node is under load, now that we are going unbounded it might only add to the pain the node is already experiencing. I understand the entire point is so that certain search requests never get rejected but I think we should find a different solution than using the generic thread pool for that. For example, could we force put them? Could we enable force putting them at the top of the queue?

@s1monw
Copy link
Contributor Author

s1monw commented Sep 17, 2018

@jasontedor here is my suggestion.

  1. I will add a search_single threadpool with a single thread and a queue.
  2. users can either decide to go to search_single or search
  3. in a seperate PR I add an option on the SearchRequest that does a force put on the queue that way we can fix Reduce the need to reload roles from index #33205 by special casing where necessary and not globally on the index.

@jpountz with 2. I think your question is more clear as well. for the search_single case we need to make sure nobody accesses more than one reader of an index that is marked as search_single at the same time.

I guess that makes this change more contained and addresses all concerns.

@jasontedor
Copy link
Member

jasontedor commented Sep 17, 2018

@s1monw The plan sounds good, I think that we are mostly on the same page. I do wonder if we need to allow users to use search_single AKA frozen, I think we can do it automatically for frozen indices and otherwise use search? Then this would not need to be user configurable at all?

@s1monw
Copy link
Contributor Author

s1monw commented Sep 17, 2018

@s1monw The plan sounds good, I think that we are mostly on the same page. I do wonder if we need to allow users to use search_single AKA frozen, i think we can do it automatically for frozen indices and otherwise use search? Then this would not need to be user configurable at all?

I can do that. Private setting sounds good to me. then this PR will only add the setting and the reading. The test can add a plugin that allows changing it.

@jasontedor
Copy link
Member

Thanks @s1monw.

@jpountz
Copy link
Contributor

jpountz commented Sep 17, 2018

The plan sounds good to me too. Then maybe call the setting "frozen_search" rather than "search_single" since it would be dedicated to frozen indices?

@s1monw
Copy link
Contributor Author

s1monw commented Sep 18, 2018

@jpountz @jasontedor I pushed a new commit implementing the first 2 steps. I still need to do some followups to ensure respect the search sequential in all places.

@s1monw
Copy link
Contributor Author

s1monw commented Sep 18, 2018

@elasticmachine test this please

@s1monw
Copy link
Contributor Author

s1monw commented Sep 19, 2018

@jasontedor @jpountz I pushed more changes

Copy link
Member

@jasontedor jasontedor left a comment

Choose a reason for hiding this comment

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

Looks phenomenal @s1monw. Thank you for the extra iterations.

@s1monw s1monw changed the title Allow for pluggable search threadpool Introduce a search_throttled threadpool Sep 20, 2018
@s1monw s1monw merged commit 3522b90 into elastic:master Sep 20, 2018
s1monw added a commit that referenced this pull request Sep 20, 2018
Today all searches happen on the search threadpool which is the correct
behavior in almost any case. Yet, there are exceptions where for instance
searches searches should be passed through a single-thread
thread-pool to reduce impact on a node. This change adds a index-private
setting that allows to mark an index as throttled for searches and forks
off all non-stats searcher access to this thread-pool for indices that
are marked as `index.search.throttled`
kcm pushed a commit that referenced this pull request Oct 30, 2018
Today all searches happen on the search threadpool which is the correct
behavior in almost any case. Yet, there are exceptions where for instance
searches searches should be passed through a single-thread
thread-pool to reduce impact on a node. This change adds a index-private setting that allows to mark an index as throttled for searches and forks off all non-stats searcher access to this thread-pool for indices that are marked as `index.search.throttled`
s1monw pushed a commit that referenced this pull request Jan 15, 2019
The executor was missed in the backport of #33732- Due to the internal forking to search or search_throttled threadpool there is no reason to fork to the search thread pool twice.

Closes #37392
Relates to #33732
s1monw pushed a commit that referenced this pull request Jan 15, 2019
The executor was missed in the backport of #33732- Due to the internal forking to search or search_throttled threadpool there is no reason to fork to the search thread pool twice.

Closes #37392
Relates to #33732
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>enhancement :Search/Search Search-related issues that do not fall into other categories v6.5.0 v7.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants