# JVM Heap Advice from documentation

**URL:** <https://discuss.elastic.co/t/jvm-heap-advice-from-documentation/169827>\
**Category:** Elasticsearch\
**Created:** [February 25, 2019, 12:28pm UTC](https://discuss.elastic.co/t/jvm-heap-advice-from-documentation/169827 "2019-02-25T12:28:14Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\
**Post date:** [February 26, 2019, 10:54am UTC](https://discuss.elastic.co/t/jvm-heap-advice-from-documentation/169827/4 "2019-02-26T10:54:09Z")

</div>

> [@truekonrads](#):
>
> OK, so why not ask the reverse question - if heap usage isn't that important to ES beyond certain memory point (say, ability to hold search result set in memory before transmission), why not allocate it _less_ memory, say 25%? Wouldn't that improve performance as now more memory is available for kernel disk cache and off-heap data.

Note that the documentation gives 50% as a recommended upper limit, not a target:

> Set `Xmx` to **no more than** 50% of your physical RAM

You can of course set it lower. I think that reducing the heap size also reduces the space available for off-heap data (they share a limit) but you are right that it increases the space available for filesystem cache. Would that improve performance? It depends™ 🙂 It means a full GC would be faster, but maybe more frequent, and means it can cache less data internally(\*). With some workloads this could be a net win. Only proper benchmarking can tell.

(\*) Elasticsearch relies on the filesystem cache for fast access to on-disk data but it does have its own caches for other data that isn't kept on-disk.

---

_[View the full topic](https://discuss.elastic.co/t/jvm-heap-advice-from-documentation/169827)._