Re: Help with cluster.routing.allocation.enable Property
sagarl wrote: Drew, Sorry I din't get the part when you said "There's nothing wrong with having a yellow cluster" And yes I agree ES does a good job of rebalancing but just think of a case where you have close to few hundred GBs of data per shard which will move around the cluster even though the new node takes only few minutes to come back up. Hence, looking to avoid unnecessary network i/O. If you were referring to /planned/ node outages, then I agree. I thought you were trying to reinvent schemes for dealing with the unpredictable. Apologies for misinterpreting! Drew -- 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/m2ppilwicj.fsf%40mid.raines.me. For more options, visit https://groups.google.com/d/optout.
Re: Help with cluster.routing.allocation.enable Property
sagarl wrote: We have our ES cluster running on aws instances where nodes can come and go. We would like to disable Shard reallocation on cluster in Normal state so that Node going down should not rebalance the shards.(Just to avoid unnecessary Network i/o). If your shard topology is relatively static, you could just leave allocation disabled (or set it to new_primaries for the occasional index creation). But honestly you're trying to micro-manage a process that ES does pretty well. There's nothing wrong with having a yellow cluster. If you're concerned about availability you should add replicas. Drew -- 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/m2y4x9wwax.fsf%40mid.raines.me. For more options, visit https://groups.google.com/d/optout.
Re: Is it possible to configure ES to listen on 2 different http ports at the same time?
Lance Lakey wrote: Leave port 9200 open to everything but only allow search requests so that all web clients can access ES but can only search Configure application servers to use port 9500 to communicate with ES Configure firewalls to only allow application servers access to ES port 9500 Allow all commands on port 9500 Eventually set up authentication on port 9500 Use a proxy listening on different ports (or vhosts, each with different authorization) to redirect to the single ES port. Drew -- 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/m238fuyk54.fsf%40mid.raines.me. For more options, visit https://groups.google.com/d/optout.
Re: bulk thread pool rejections
shift wrote:
I am seeing a high number of rejections for the bulk thread pool
on a 32 core system. Should I leave the thread pool size fixed
to the # of cores and the default queue size at 50? Are these
rejections re-processed?
From my clients sending bulk documents (logstash), do I need to
limit the number of connections to 32? I currently have 200
output threads to each elasticsearch node.
The rejections are telling you that ES's bulk thread pool is busy
and it can't enqueue any more to wait for an open thread. They
aren't retried. The exception your client gets is the final word
for that request.
Lower your logstash threads to 16 or 32, monitor rejections, and
gradually raise. You could also increase the queue size, but keep
in mind that's only useful to handle spikes. You probably don't
want to keep thousands around waiting since they take resources.
Drew
"bulk" : {
"threads" : 32,
* "queue" : 50,*
"active" : 32,
* "rejected" : 12592108,*
"largest" : 32,
"completed" : 584407554
}
Thanks! Any feedback is appreciated.
--
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 elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/m2lhvnpwx8.fsf%40mid.raines.me.
For more options, visit https://groups.google.com/d/optout.
0.90.11 and 1.0.0.RC2 released
Greetings! 0.90.11 is out, with caching improvements and added visibility into Lucene's memory use. We've also released what's hopefully going to be our final RC before 1.0.0. Check here for more info: http://www.elasticsearch.org/blog/0-90-11-1-0-0-rc2-released/ Thanks! Elasticsearch developers -- 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/dc8aa58f-d8c6-48ef-a2bc-75a31e0ba386%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
