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. -- Performance Monitoring * Log Analytics * Search Analytics Solr & Elasticsearch Support * http://sematext.com/ On Thu, Jan 8, 2015 at 3:46 PM, vipins <[email protected]> wrote: > Sorry , I was wrong with number of shards. actual number of shards is 320 > for > the index which i am querying. > > We are using rolling indices on a daily basis. > > max queue size is 1000 for search thread pool. > > We overcome the issue None of the configured nodes are available by keeping > tcp connection alive as true. > > > > > -- > View this message in context: > http://elasticsearch-users.115913.n3.nabble.com/concurrent-search-request-to-elasticsearch-tp4068702p4068711.html > Sent from the ElasticSearch Users mailing list archive at Nabble.com. > > -- > 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/1420724779413-4068711.post%40n3.nabble.com > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAHXA0_00wG%2BNUQQm2_KtH7jKBC7ovN1AXnAf9Jot2VCTppMk9g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
