mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-07 05:28:34 +00:00
3879aa2a98
This commit adds a new configuration file jvm.options to centralize and simplify management of JVM options. This separates the configuration of the JVM from the packaging scripts (bin/elasticsearch*, bin/service.bat, and init.d/elasticsearch) simplifying end-user operational management of custom JVM options.
56 lines
1.6 KiB
Plaintext
56 lines
1.6 KiB
Plaintext
[horizontal]
|
|
`ES_USER`::
|
|
|
|
The user to run as, defaults to `elasticsearch`.
|
|
|
|
`ES_GROUP`::
|
|
|
|
The group to run as, defaults to `elasticsearch`.
|
|
|
|
`JAVA_HOME`::
|
|
|
|
Set a custom Java path to be used.
|
|
|
|
`MAX_OPEN_FILES`::
|
|
|
|
Maximum number of open files, defaults to `65536`.
|
|
|
|
`MAX_LOCKED_MEMORY`::
|
|
|
|
Maximum locked memory size. Set to `unlimited if you use the
|
|
`bootstrap.mlockall` option in elasticsearch.yml.
|
|
|
|
`MAX_MAP_COUNT`::
|
|
|
|
Maximum number of memory map areas a process may have. If you use `mmapfs`
|
|
as index store type, make sure this is set to a high value. For more
|
|
information, check the
|
|
https://github.com/torvalds/linux/blob/master/Documentation/sysctl/vm.txt[linux kernel documentation]
|
|
about `max_map_count`. This is set via `sysctl` before starting
|
|
elasticsearch. Defaults to `262144`.
|
|
|
|
`LOG_DIR`::
|
|
|
|
Log directory, defaults to `/var/log/elasticsearch`.
|
|
|
|
`DATA_DIR`::
|
|
|
|
Data directory, defaults to `/var/lib/elasticsearch`.
|
|
|
|
`CONF_DIR`::
|
|
|
|
Configuration file directory (which needs to include `elasticsearch.yml`
|
|
and `logging.yml` files), defaults to `/etc/elasticsearch`.
|
|
|
|
`ES_JAVA_OPTS`::
|
|
|
|
Any additional JVM system properties you may want to apply.
|
|
|
|
`RESTART_ON_UPGRADE`::
|
|
|
|
Configure restart on package upgrade, defaults to `false`. This means you
|
|
will have to restart your elasticsearch instance after installing a
|
|
package manually. The reason for this is to ensure, that upgrades in a
|
|
cluster do not result in a continuous shard reallocation resulting in high
|
|
network traffic and reducing the response times of your cluster.
|