Limit no. of thread for msearch

I would like to limit the no of threads allocated to msearch. In my use case, I have users submitting hundreds of query strings, and other users submit single query strings. when these bulk searches show up, they take up all of the threads and cpu usage. I would like leave at least 2 threads on each node to service single queries. How do solve this issue?

You did not say the version.

In 2.x, there is nothing that you can do (other than limit the number of searches in a single msearch request), it is indeed a problem.

In 5.x there is the max_concurrent_searches parameter that you can use to limit the number of concurrent requests from a single msearch batch. This parameter has a reasonable default based on the default size of the search thread pool.

I am running 5.1.2

I want to limit the thread pool that is assigned to bulk, or to make the question more clear how do I ensure the regular searches don't get effected by bulk searches.

You can not, they share the same thread pool. The best that you can do is limit the number of concurrent searches from a single msearch request. This does not limit the thread pool from being consumed if multiple msearch requests are submitted. If you need the fine-grained management that you're describing, you need to put a traffic cop in front of Elasticsearch.

I notice that you are an engineer at elastic. In the future is it a possibility that you implement the option of a queue and set aside thread for multi search or at least prioritize single requests over bulk ones. The third option of having a separate cluster for bulk and single is not very appealing.

I'm reluctant to add yet another thread pool to Elasticsearch, I think that we create too many threads as it is.

Also, prioritizing single requests over bulk thread pools is not something that we are likely to do, single requests are now treated as bulk requests with a single item in the payload anyway.

There have been requests to add the ability to attach a priority to requests, but we've resisted this.

I do not see why you need a separate cluster, I merely meant fronting requests.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.