# JVM Heap size too large?
**URL:** https://discuss.elastic.co/t/jvm-heap-size-too-large/207312
**Category:** Elasticsearch
**Created:** [November 11, 2019, 9:26am UTC](https://discuss.elastic.co/t/jvm-heap-size-too-large/207312 "2019-11-11T09:26:45Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@bruce289](https://discuss.elastic.co/u/bruce289)
#### Post date: [November 11, 2019, 9:26am UTC](https://discuss.elastic.co/t/jvm-heap-size-too-large/207312/1 "2019-11-11T09:26:45Z")
Hi,
The heap size on all our nodes is set to 30GB, but having read [A Heap of Trouble](https://www.elastic.co/blog/a-heap-of-trouble), and looking at the graphs in the Kibana Stack Monitoring application, I believe our heap size is likely too large:
The graphs for all the nodes have a similar shape. Based on this, what would be the recommended heap size setting?
Thanks.
---
### Author:  [@Glen\_Smith](https://discuss.elastic.co/u/Glen_Smith)
#### Post date: [November 12, 2019, 12:29am UTC](https://discuss.elastic.co/t/jvm-heap-size-too-large/207312/2 "2019-11-12T00:29:22Z")
Hello,
It appears from that graph that the node in question bottoms out around 5GB, and that, indeed, the periodicity of GC is quite long. How aggressively I would pursue reducing the allocated heap would depend on how the current usage compares to planned capacity, in terms of volume of retained data, indexing load, search load, number of indices.
If you believe that you are currently at about the expected usage in those terms for a reasonable time horizon (perhaps 3 - 6 months), then you could easily cut that node to, say, 15GB, and continue to monitor for the possibility to cut back more. You could conceivably go as low as 10GB.
If, on the other hand, this is a relatively new cluster and usage is expected to grow substantially in the near future, I would consider waiting until usage is more mature before adjusting - unless you are experiencing latency spikes during GC, in which case, of course, it should be a higher priority.
---
### Author:  [@bruce289](https://discuss.elastic.co/u/bruce289)
#### Post date: [November 13, 2019, 10:52am UTC](https://discuss.elastic.co/t/jvm-heap-size-too-large/207312/3 "2019-11-13T10:52:31Z")
Hi Glen,
Thanks for confirming my suspicions that the heap size could probably do with being reduced, however, since we are currently on-boarding a number of different data streams, I'll revisit this once those are up and running.
Thanks.
---
### Author:  [@linkerc](https://discuss.elastic.co/u/linkerc)
#### Post date: [November 14, 2019, 12:00am UTC](https://discuss.elastic.co/t/jvm-heap-size-too-large/207312/4 "2019-11-14T00:00:16Z")
This is the part that I don't understand. I allocated 30GB heap to my nodes as well. I don't have old GC so that means my RAM usage is pretty healthy. Young GC happens about once in 3 seconds.
But your system's RAM usage requires old GC, which means more intensive than my usage. But the recommendation is to reduce RAM allocation?
We are using G1GC, which improves significantly comparing to the old CMS GC.
Does GC algorithm play bigger role than the actual RAM usage of the cluster?
---
### Author:  [@Glen\_Smith](https://discuss.elastic.co/u/Glen_Smith)
#### Post date: [November 14, 2019, 4:42am UTC](https://discuss.elastic.co/t/jvm-heap-size-too-large/207312/5 "2019-11-14T04:42:33Z")
@linkerc Please open a new topic for your question. Thanks.
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [December 12, 2019, 4:42am UTC](https://discuss.elastic.co/t/jvm-heap-size-too-large/207312/6 "2019-12-12T04:42:36Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.