Thanks Jörg, Mark and Nikolas, some great information here. The 6x6 configuration was something of a worst case example, the farthest we'd probably stretch it would be 3 nodes per host on 16-18 hosts, which should be a little more reasonable. Hopefully we'll be able to do a support contract with the commercial side of ES and get some help building out a system that meets our exact needs.
On Wednesday, January 29, 2014 5:02:05 PM UTC-8, Jörg Prante wrote: > > You should consider the RAM to CPU/Disk ratio. On systems with huge > memory, CPUs have the tendency to become weak, and the I/O subsystem must > push data with higher pressure from RAM to drive (spindle or SSD). > Huge RAM helps for caching strategies but also creates headaches, large > caches must be long lived and must not collapse, which is hard in a large > JVM heap, and JVM garbage collection will take more resources and time. > > Running multiple JVMs on a single host only looks like a viable solution, > but that is not how ES scales. ES scales horizontally over many machines, > not vertically over RAM size. > > So you should take care that your CPU performance is not suffering. There > is overhead also on the OS layer and it depends on the setup. > > A 36 node cluster on 6 machines adds another challenge. You must tell ES > how your nodes are organized, in order to get a reliable green/yellow/red > cluster health for your shard allocation. > > Jörg > > -- 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/156f7ee8-c66c-40e0-9774-e442dd2f1976%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
