Right now my ES search thread pool config is:
"transient" : {
"threadpool.search.queue_size" : "200",
"threadpool.search.reject_policy" : "abort",
"threadpool.search.size" : "12"
}
The problem is that during peak load most of the search requests are
getting rejected. So I was thinking if I should switch to "caller" reject
policy. But I have some questions for "caller" policy:
- Which thread would be the "caller" who would execute the searches when
the queue is full. Is it the Netty connector?
- If its the Netty connector what would happen to other clients who are
making requests when the Netty "caller" thread is executing the search? In
my local tests they are not failing/rejected. Where would such requests get
queued (client/network)?
- Would this guarantee every search request is eventually served (not
rejected)?
- What is the downside to using "caller", can this lead to network
congestion or have any other issue with the ES node/cluster in case the
there are too many concurrent searches for prolonged duration?
Thanks.
--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/5a8de617-7bb6-4d77-86b4-8744d4a7ce6d%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
