# ES Heap and CPU Usage - bigger is better? **URL:** \ **Category:** Elasticsearch\ **Created:** [November 24, 2014, 12:24pm UTC](https://discuss.elastic.co/t/es-heap-and-cpu-usage-bigger-is-better/20910 "2014-11-24T12:24:53Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![sking0333](https://avatars.discourse-cdn.com/v4/letter/s/a587f6/32.png) [@sking0333](https://discuss.elastic.co/u/sking0333)\ **Post date:** [November 24, 2014, 12:24pm UTC](https://discuss.elastic.co/t/es-heap-and-cpu-usage-bigger-is-better/20910/1 "2014-11-24T12:24:53Z")
Hey guys, 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). Anyone with some experience to share? Cheers Stephen -- 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/fdffe493-961a-4158-9585-da324ede5ca6%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/fdffe493-961a-4158-9585-da324ede5ca6%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Gurvinder\_Singh](https://avatars.discourse-cdn.com/v4/letter/g/cab0a1/32.png) [@Gurvinder\_Singh](https://discuss.elastic.co/u/Gurvinder_Singh)\ **Post date:** [November 24, 2014, 12:40pm UTC](https://discuss.elastic.co/t/es-heap-and-cpu-usage-bigger-is-better/20910/2 "2014-11-24T12:40:42Z")
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. > **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)** > > Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today. - Gurvinder On 11/24/2014 01:24 PM, [sking0333@gmail.com](mailto:sking0333@gmail.com) wrote: > Hey guys, > > 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). > > Anyone with some experience to share? > > Cheers > > Stephen > > -- > 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com) > [mailto:elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/fdffe493-961a-4158-9585-da324ede5ca6%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/fdffe493-961a-4158-9585-da324ede5ca6%40googlegroups.com) > [https://groups.google.com/d/msgid/elasticsearch/fdffe493-961a-4158-9585-da324ede5ca6%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/fdffe493-961a-4158-9585-da324ede5ca6%40googlegroups.com?utm_medium=email&utm_source=footer). > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/5473274A.7080604%40gmail.com](https://groups.google.com/d/msgid/elasticsearch/5473274A.7080604%40gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 12:48am UTC](https://discuss.elastic.co/t/es-heap-and-cpu-usage-bigger-is-better/20910/3 "2017-07-06T00:48:07Z")