By default, Elasticsearch tells the JVM to use a heap with a minimum
and maximum size of 2 GB. When moving to production, it is
important to configure heap size to ensure that Elasticsearch has enough
heap available.

The value for these setting depends on the amount of RAM available on
your server. Good rules of thumb are:

Set the minimum heap size (Xms) and maximum heap size (Xmx) to be
equal to each other.

The more heap available to Elasticsearch, the more memory it can use for
caching. But note that too much heap can subject you to long garbage
collection pauses.

Set Xmx to no more than 50% of your physical RAM, to ensure that there
is enough physical RAM left for kernel file system caches.

Don’t set Xmx to above the cutoff that the JVM uses for compressed
object pointers (compressed oops); the exact cutoff varies but is
near 32 GB. You can verify that you are under the limit by looking
for a line in the logs like the following:

heap size [1.9gb], compressed ordinary object pointers [true]

Even better, try to stay below the threshold for zero-based
compressed oops; the exact cutoff varies but 26 GB is safe on most
systems, but can be as large as 30 GB on some systems. You can verify
that you are under the limit by starting Elasticsearch with the JVM
options -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode
and looking for a line like the following:

Configuring the heap for the Windows service
is different than the above. The values initially populated for the
Windows service can be configured as above but are different after the
service has been installed. Consult the
Windows service documentation for additional
details.