i´l just want to ask here if anybody has some better experience with bigger
java heap sizes than me.
Our problem is that we only have 1 big server with 256 gb RAM and 64 for
our ES system which indexes about 4-6k events/s. Actually i have running 3
instances, 2 with 32 GB java heap and slow HDD´s as target for older
indices and 1 with 96GB java heap and fast SSD storage.
I think about splitting the 96GB instance to 2 X 32 GB RAM because our
server sometimes is running out of CPU and given to the ES documentation
heaps larger 32gb lead to uncompressed pointers and so far to much higher
cpu usage.
what make me worry is that instances which that little RAM arent able to
handle the indexing and search load(which is quite high).
I would say decrease your java heap RAM to lower pressure on GC and
switch store type from hybrid to mmapfs. This will enable lucene to use
your RAM to buffer index which will enhance your performance. Test with
these settings to see how the results look like. For us this has been
better than using larger heap with hybrid storage type.
i´l just want to ask here if anybody has some better experience with
bigger java heap sizes than me.
Our problem is that we only have 1 big server with 256 gb RAM and 64 for
our ES system which indexes about 4-6k events/s. Actually i have running
3 instances, 2 with 32 GB java heap and slow HDD´s as target for older
indices and 1 with 96GB java heap and fast SSD storage.
I think about splitting the 96GB instance to 2 X 32 GB RAM because our
server sometimes is running out of CPU and given to the ES documentation
heaps larger 32gb lead to uncompressed pointers and so far to much
higher cpu usage.
what make me worry is that instances which that little RAM arent able to
handle the indexing and search load(which is quite high).
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.