2016-04-03 10:09:24 -04:00
|
|
|
[horizontal]
|
|
|
|
`ES_USER`::
|
|
|
|
|
|
|
|
The user to run as, defaults to `elasticsearch`.
|
|
|
|
|
|
|
|
`ES_GROUP`::
|
|
|
|
|
|
|
|
The group to run as, defaults to `elasticsearch`.
|
|
|
|
|
2016-04-06 17:06:30 -04:00
|
|
|
`JAVA_HOME`::
|
|
|
|
|
|
|
|
Set a custom Java path to be used.
|
|
|
|
|
2016-04-03 10:09:24 -04:00
|
|
|
`MAX_OPEN_FILES`::
|
|
|
|
|
|
|
|
Maximum number of open files, defaults to `65536`.
|
|
|
|
|
|
|
|
`MAX_LOCKED_MEMORY`::
|
|
|
|
|
2016-11-08 08:33:07 -05:00
|
|
|
Maximum locked memory size. Set to `unlimited` if you use the
|
2016-06-01 16:25:51 -04:00
|
|
|
`bootstrap.memory_lock` option in elasticsearch.yml.
|
2016-04-03 10:09:24 -04:00
|
|
|
|
|
|
|
`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`
|
2016-08-31 15:51:52 -04:00
|
|
|
and `log4j2.properties` files), defaults to `/etc/elasticsearch`.
|
2016-04-03 10:09:24 -04:00
|
|
|
|
|
|
|
`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.
|