Modifying advanced settings is generally not recommended and could negatively impact performance and stability. Using the Elasticsearch-provided defaults is recommended in most circumstances.
If needed, you can override the default JVM options by adding custom options
files (preferred) or setting the
ES_JAVA_OPTS environment variable.
JVM options files must have the suffix .options and contain a line-delimited list of JVM arguments. JVM processes options files in lexicographic order.
Where you put the JVM options files depends on the type of installation:
tar.gz or .zip: Add custom JVM options files to
Debian or RPM: Add custom JVM options files to
Docker: Bind mount custom JVM options files into
Do not modify the root
jvm.options file. Use files in
A JVM options file contains a line-delimited list of JVM arguments.
Arguments are preceded by a dash (
To apply the setting to specific versions, prepend the version
or a range of versions followed by a colon.
Apply a setting to all versions:
Apply a setting to a specific version:
Apply a setting to a range of versions:
To apply a setting to a specific version and any later versions, omit the upper bound of the range. For example, this setting applies to Java 8 and later:
Blank lines are ignored. Lines beginning with
# are treated as comments
and ignored. Lines that aren’t commented out and aren’t recognized
as valid JVM arguments are rejected and Elasticsearch will fail to start.
In production, use JVM options files to override the
default settings. In testing and development environments,
you can also set JVM options through the
ES_JAVA_OPTS environment variable.
export ES_JAVA_OPTS="$ES_JAVA_OPTS -Djava.io.tmpdir=/path/to/temp/dir" ./bin/elasticsearch
If you’re using the RPM or Debian packages, you can specify
ES_JAVA_OPTS in the system configuration file.
Elasticsearch ignores the
JAVA_OPTS environment variables.
By default, Elasticsearch automatically sets the JVM heap size based on a node’s roles and total memory. Using the default sizing is recommended for most production environments.
To override the default heap size, set the minimum and maximum heap size
Xmx. The minimum and maximum values must be the same.
The heap size should be based on the available RAM:
Xmxto no more than 50% of your total memory. Elasticsearch requires memory for purposes other than the JVM heap. For example, Elasticsearch uses off-heap buffers for efficient network communication and relies on the operating system’s filesystem cache for efficient access to files. The JVM itself also requires some memory. It’s normal for Elasticsearch to use more memory than the limit configured with the
When running in a container, such as Docker, total memory is defined as the amount of memory visible to the container, not the total system memory on the host.
Xmxto no more than the threshold for compressed ordinary object pointers (oops). The exact threshold varies but 26GB is safe on most systems and can be as large as 30GB on some systems. To verify you are under the threshold, check the Elasticsearch log for an entry like this:
heap size [1.9gb], compressed ordinary object pointers [true]
Or check the
jvm.using_compressed_ordinary_object_pointersvalue for the nodes using the nodes info API:
The more heap available to Elasticsearch, the more memory it can use for its internal caches. This leaves less memory for the operating system to use for the filesystem cache. Larger heaps can also cause longer garbage collection pauses.
To configure the heap size, add the
Xmx JVM arguments to a
custom JVM options file with the extension
store it in the
For example, to set the maximum heap size to 2GB, set both
For testing, you can also set the heap sizes using the
ES_JAVA_OPTS="-Xms2g -Xmx2g" ./bin/elasticsearch
ES_JAVA_OPTS variable overrides all other JVM
options. We do not recommend using
ES_JAVA_OPTS in production.
If you are running Elasticsearch as a Windows service, you can change the heap size using the service manager. See Install and run Elasticsearch as a service on Windows.
This functionality is in technical preview and may be changed or removed in a future release. Elastic will apply best effort to fix any issues, but features in technical preview are not subject to the support SLA of official GA features.
If configured, a node can open a TCP port when the node is in a ready state. A node is deemed ready when it has successfully joined a cluster. In a single node configuration, the node is said to be ready, when it’s able to accept requests.
To enable the readiness TCP port, use the
readiness.port setting. The port is
always bound to the loopback address, which defaults to the IPv4 loopback address
To bind the readiness port to the IPv6 loopback address
-Djava.net.preferIPv6Addresses=true to the JVM options.
If the node leaves the cluster, or the Shutdown API is used to mark the node for shutdown, the readiness port is immediately closed.
A successful connection to the readiness TCP port signals that the Elasticsearch node is ready. When a client connects to the readiness port, the server simply terminates the socket connection. No data is sent back to the client. If a client cannot connect to the readiness port, the node is not ready.
Intro to Kibana
ELK for Logs & Metrics