2016-04-03 10:09:24 -04:00
|
|
|
|
[[heap-size]]
|
2016-04-11 07:15:19 -04:00
|
|
|
|
=== Set JVM heap size via jvm.options
|
2016-04-03 10:09:24 -04:00
|
|
|
|
|
|
|
|
|
In development mode, Elasticsearch tells the JVM to use a heap with a minimum
|
2016-04-11 07:15:19 -04:00
|
|
|
|
size of 256 MB and a maximum size of 1 GB. When moving to production, it is
|
|
|
|
|
important to configure heap size to ensure that Elasticsearch has enough
|
|
|
|
|
heap available.
|
2016-04-03 10:09:24 -04:00
|
|
|
|
|
2016-04-11 07:15:19 -04:00
|
|
|
|
Elasticsearch will assign the entire heap specified in <<sysconfig,es-java-opts>>
|
|
|
|
|
via the Xms (minimum heap size) and Xmx (maximum heap size) settings.
|
2016-04-03 10:09:24 -04:00
|
|
|
|
|
2016-04-11 07:15:19 -04:00
|
|
|
|
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.
|
2016-04-03 10:09:24 -04:00
|
|
|
|
|
|
|
|
|
* The more heap available to Elasticsearch, the more memory it can use for
|
2016-04-11 07:15:19 -04:00
|
|
|
|
caching. But note that too much heap can subject you to long garbage
|
|
|
|
|
collection pauses.
|
2016-04-03 10:09:24 -04:00
|
|
|
|
|
2016-04-11 07:15:19 -04:00
|
|
|
|
* 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.
|
2016-04-03 10:09:24 -04:00
|
|
|
|
|
2016-04-11 07:15:19 -04:00
|
|
|
|
* 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:
|
2016-04-03 10:09:24 -04:00
|
|
|
|
|
|
|
|
|
heap size [1.9gb], compressed ordinary object pointers [true]
|
|
|
|
|
|
2016-04-11 07:15:19 -04:00
|
|
|
|
* 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 system. 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:
|
2016-04-03 10:09:24 -04:00
|
|
|
|
|
2016-04-11 07:15:19 -04:00
|
|
|
|
heap address: 0x000000011be00000, size: 27648 MB, zero based Compressed Oops
|
|
|
|
|
|
|
|
|
|
showing that zero-based compressed oops are enabled instead of
|
|
|
|
|
|
|
|
|
|
heap address: 0x0000000118400000, size: 28672 MB, Compressed Oops with base: 0x00000001183ff000
|
|
|
|
|
|
|
|
|
|
Here are examples of how to set the heap size via the jvm.options file:
|
|
|
|
|
|
2016-04-13 03:57:00 -04:00
|
|
|
|
[source,txt]
|
2016-04-03 10:09:24 -04:00
|
|
|
|
------------------
|
2016-04-11 07:15:19 -04:00
|
|
|
|
Xms2g <1>
|
|
|
|
|
Xmx2g <2>
|
2016-04-03 10:09:24 -04:00
|
|
|
|
------------------
|
2016-04-11 07:15:19 -04:00
|
|
|
|
<1> Set the minimum heap size to 2g.
|
|
|
|
|
<2> Set the maximum heap size to 2g.
|
|
|
|
|
|
|
|
|
|
It is also possible to set the heap size via an environment variable.
|
|
|
|
|
This can be done by commenting out the `Xms` and `Xmx` settings
|
|
|
|
|
in the jvm.options file and setting these values via `ES_JAVA_OPTS`:
|
2016-04-03 10:09:24 -04:00
|
|
|
|
|
2016-04-11 07:15:19 -04:00
|
|
|
|
[source,sh]
|
|
|
|
|
------------------
|
|
|
|
|
ES_JAVA_OPTS="-Xms2g -Xmx2g" ./bin/elasticsearch <3>
|
|
|
|
|
ES_JAVA_OPTS="-Xmx4000mb -Xmx4000mb" ./bin/elasticsearch <4>
|
|
|
|
|
------------------
|
|
|
|
|
<3> Set the minimum and maximum heap size to 2 GB.
|
|
|
|
|
<4> Set the minimum and maximum heap size to 4000 MB.
|