The search threadpool size (that is, how many requests can be actually
worked on at once) defaults to 3 times the number of processors. This might
be reduced in future, though, see:
The queue size (how many requests ES can accept before starting to reject
them) defaults to 1000.
From what I understand, this is per thread, so the answer to your question
depends on how many processors you have and how many shards get hit by each
search. For example, if a search runs on 3 indices, each with 2 shards
(number of replicas is irrelevant, because the search will only hit one
complete set of data) you'll get 6 requests in the threadpool per search.
If you have two servers with 8 cores each, you 832=48 threads available.
So the cluster can work on 8 requests at once. On top of that it can still
queue round-down(2 nodes * 1000 queue size/6 requests per search)=333
searches until it starts rejecting them.
Regarding your scaling question, I can't give you a direct answer,
unfortunately, because it depends on a whole lot of variables, mainly how
your data, queries and hardware look like and what can be changed. The fact
that your threadpool queue got full is just a symptom, it's not clear to me
what happens in there. I usually see this when there are lots of indices
and/or those indices have lots of shards. So a single request takes a lot
of requests in the threadpool, filling it up, even if the ES cluster can
keep up with the load. If that's your case increase the threadpool queue
size and make sure you don't have too many shards per index.
If your cluster can't keep up with the load (a monitoring tool like SPM http://sematext.com/spm/ should show you that), then the first step is to
see where is the bottleneck. Again, monitoring can give some insight: are
queries too expensive, can they be optimized? do you have too many cache
evictions? is the heap size too large or too small? is memory, I/O or CPU
the bottleneck? Things like that. It could also be that you need
more/different hardware.
Finally, you can make scaling ES someone else's problem by using a hosted
service like Logsene http://sematext.com/logsene/index.html. Especially
if you're using ES for log- or metric-like data, you'll get lots of
features out of the box, and we expose most of the ES API to plug in your
custom stuff.
Thanks a lot for your detailed response.
We have got all default settings only.Single node and 5 shards. But there are lot of indices with huge number of records.
search settings:
"threads" : 12,
"queuesize" : 1000,
My query is very simple. which runs on a single index only.
Even with 5 requests in between it is throwing None of the configured nodes are available.
So you're saying you're running 5 searches on a single index with 5 shards
(25 per-shard queries in total) and you're getting an error? I assume that
error doesn't say the queue is full because the queue is 1000. Can you post
the full error and also a gist where you reproduce the issue http://www.elasticsearch.org/help? I might be missing an essential bit
here.
Thanks a lot for your detailed response.
We have got all default settings only.Single node and 5 shards. But there
are lot of indices with huge number of records.
search settings:
"threads" : 12,
"queuesize" : 1000,
My query is very simple. which runs on a single index only.
Even with 5 requests in between it is throwing None of the configured nodes
are available.
OK, now it makes sense. 5 requests with 320 shards might saturate your
queue.
But 320 shards sounds like a lot for one index. I assume you don't need to
scale that very index to 320 nodes (+ replicas). If you can get the number
of shards down (say, to the default of 5) things will surely look better
not only from the queue's perspective, but it should also improve search
performance.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.