Forgot to reply to your questions, Binh: 1) No I haven't set this. However I wonder if this has any significant effect since swap space is barely used. 2) It seems to happen when the cluster is under high load but I haven't seen any specific pattern so far. 3) No there's not. There's a very small Redis instance running on node1, but there's nothing else on the nodes with shards (where the GC problem happens).
If I was going to disable master on any node that has shards I'd have to add another dummy node with master:true so the cluster is in good state if any one of the nodes is down. On Thursday, March 27, 2014 4:46:41 PM UTC+1, Binh Ly wrote: > > I would probably not master enable any node that can potentially gc for a > couple seconds. You want your master-eligible nodes to make decisions as > quick as possible. > > About your GC situation, I'd find out what the underlying cause is: > > 1) Do you have bootstrap.mlockall set to true? > > 2) Does it usually triggered while running queries? Or is there a pattern > on when it usually triggers? > > 3) Is there anything else running on these nodes that would overload and > affect normal ES operations? > -- 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/0ae93e7c-a6f7-4784-8b4a-71d6f52552a7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
