4 ms·
> ES recently moved over to openJDK, so there's a couple intricacies there (i.e. JVM heap size) My current employers uses ES - we're on 6.8, planning to move t
by vosper 7y ago
> ES recently moved over to openJDK, so there's a couple intricacies there (i.e. JVM heap size)
My current employers uses ES - we're on 6.8, planning to move to 7 in a few months. Judging by the other replies here I'd say we have a reasonably large cluster (150+ i3.2xlarge instances, billions of documents), so tuning the cluster is very relevant to us. Could you expand on how things have changed with the move to OpenJDK?
I've seen some claims online that, contrary to what Elastic recommends in their docs, a few machines with huge heaps (100+ gb) is the way to go, rather than many machines with 20gb heaps.
- yehosef 7y ago>I've seen some claims online that, contrary to what Elastic recommends in their docs, a few machines with huge heaps (100+ gb) is the way to go, rather than many machines with 20gb heaps. Usually the recommendation is less than 32GB - this link has some more discussion about it: From https://discuss.elastic.co/t/es-lucene-32gb-heap-myth-or-fact/22920/9 https://discuss.elastic.co/t/es-lucene-32gb-heap-myth-or-fac... It seems whether it's better or worse depends on your data set . But I would love to see tests of different kinds of workloads with large or smaller heaps.