OpenSearch/docs/reference/setup/sysconfig/heap_size.asciidoc

75 lines
2.8 KiB
Plaintext
Raw Normal View History

[[heap-size]]
=== Set JVM heap size via jvm.options
By default, Elasticsearch tells the JVM to use a heap with a minimum
and maximum size of 1 GB. When moving to production, it is
important to configure heap size to ensure that Elasticsearch has enough
heap available.
Improve the out-of-the-box experience Elasticsearch can be run in a few different ways: - from the command line on Linux and Windows - as a service on Linux and Windows on both 32-bit client and 64-bit server VMs. We strive for a great out-of-the-box experience any of these combinations but today it is lacking on 32-bit client JVMs and on the Windows service. There are two deficiencies that arise: - on any 32-bit client JVM we fail to start out of the box because we force the server JVM in jvm.options - when installing the Windows service, the thread stack size must be specified in jvm.options This commit attempts to address these deficiencies. We should continue to force the server JVM because there are systems where the server JVM is not active by default (e.g., the 32-bit JDK on Windows). This does mean that if a user tries to run with a client JVM they will see a failure message at startup but this is the best that we can do if we want to continue to force the server JVM. Thus, this commit at least documents this situation. To improve the situation with installing the Windows service, this commit adds a default setting for the thread stack size. This default is chosen based on the default thread stack size across all 64-bit server JVMs. This means that if a user tries to run with a 32-bit JVM they could otherwise see significantly higher memory usage (this situation is complicated, it's really only on Windows where the extra memory usage is egregious, but cutting into the 32-bit address space on any system is bad). So this commit makes it so that the out-of-the-box experience is improved for the Windows service on 64-bit server JVMs and we document the need to adjust this setting on 32-bit JVMs. Again, we are focusing on the out-of-the-box experience here and this means optimizing for the best experience on any 64-bit server JVM as this covers the vast majority of the user base. The users that are on 32-bit JVMs will suffer a little bit but at least now any user on any 64-bit server JVM can start Elasticsearch out of the box. Finally, we fix some references to the jvm.options documentation. Relates #21920
2016-12-01 17:26:29 -05:00
Elasticsearch will assign the entire heap specified in <<jvm-options,jvm.options>>
via the Xms (minimum heap size) and Xmx (maximum heap size) settings.
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.
* Dont 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-13 04:14:09 -04:00
+
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
2016-04-13 04:14:09 -04:00
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
2016-04-13 04:14:09 -04:00
options `-XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode`
and looking for a line like the following:
2016-04-13 04:14:09 -04:00
+
--
heap address: 0x000000011be00000, size: 27648 MB, zero based Compressed Oops
2016-04-13 04:14:09 -04:00
showing that zero-based compressed oops are enabled instead of
heap address: 0x0000000118400000, size: 28672 MB, Compressed Oops with base: 0x00000001183ff000
2016-04-13 04:14:09 -04:00
--
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]
------------------
-Xms2g <1>
-Xmx2g <2>
------------------
<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`:
[source,sh]
------------------
2016-04-13 04:01:33 -04:00
ES_JAVA_OPTS="-Xms2g -Xmx2g" ./bin/elasticsearch <1>
ES_JAVA_OPTS="-Xms4000m -Xmx4000m" ./bin/elasticsearch <2>
------------------
2016-04-13 04:01:33 -04:00
<1> Set the minimum and maximum heap size to 2 GB.
2016-04-13 04:14:09 -04:00
<2> Set the minimum and maximum heap size to 4000 MB.
NOTE: Configuring the heap for the <<windows-service,Windows service>>
2016-10-10 16:51:47 -04:00
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,Windows service documentation>> for additional
details.