JVM Heap Size

First of all, the term JVM heap needs to be cleared.

Java Virtual Machine makes a computer able to run a Java program. Java objects live in the heap area.

As the JVM starts up, it creates a heap memory, and the heap memory size can vary in size while the application is running. Therefore, all Java class instances and arrays are allocated in this are1a.

So JVM heap is the memory containing the objects initialized by the applications running on the JVM. If the heap reaches its limit, garbage collection starts, and unused objects are released from memory. So heap memory will be freed for new objects.

Elasticsearch automatically adjusts the JVM heap size according to the roles of a node and total memory. Therefore, letting Elasticsearch does sizing by default values is often recommended.

The default heap size values can be overridden by adjusting Xms and Xmx settings. Xms for minimum value and Xmx for maximum value. The minimum and the maximum values must be the same also.

Setting Xms and Xmx to more than 50% of the total memory is not recommended because Elasticsearch doesn’t use only heap memory. It uses off-heap buffers and OS’s file system cache. Also, JVM itself needs to use some memory other than the heap. So in the broader perspective, Elasticsearch uses more memory than just Xmx.

If Elasticsearch is running in a container, total memory needs to be considered as the container’s memory, not the total memory installed on the host machine.

JAVA uses compressed ordinary object pointer, and when heap size exceeds 32 GB, JAVA goes for OOP (not compressed), so it uses 40-50 GB of memory instead of 30 GB.

There is not an absolute threshold, but it must be below 32 GB; around 26 GB is a sweet spot.
The larger the heap size, the longer the garbage collection pauses.

20 shards per 1 GB of heap memory shouldn’t be exceeded.