WARNING: Version 1.5 of Elasticsearch has passed its EOL date.
This documentation is no longer being maintained and may be removed. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.
Configuration
editConfiguration
editEnvironment Variables
editWithin the scripts, Elasticsearch comes with built in JAVA_OPTS
passed
to the JVM started. The most important setting for that is the -Xmx
to
control the maximum allowed memory for the process, and -Xms
to
control the minimum allocated memory for the process (in general, the
more memory allocated to the process, the better).
Most times it is better to leave the default JAVA_OPTS
as they are,
and use the ES_JAVA_OPTS
environment variable in order to set / change
JVM settings or arguments.
The ES_HEAP_SIZE
environment variable allows to set the heap memory
that will be allocated to elasticsearch java process. It will allocate
the same value to both min and max values, though those can be set
explicitly (not recommended) by setting ES_MIN_MEM
(defaults to
256m
), and ES_MAX_MEM
(defaults to 1g
).
It is recommended to set the min and max memory to the same value, and
enable mlockall
.
System Configuration
editFile Descriptors
editMake sure to increase the number of open files descriptors on the machine (or for the user running elasticsearch). Setting it to 32k or even 64k is recommended.
In order to test how many open files the process can open, start it with
-Des.max-open-files
set to true
. This will print the number of open
files the process can open on startup.
Alternatively, you can retrieve the max_file_descriptors
for each node
using the Nodes Info API, with:
curl localhost:9200/_nodes/process?pretty
Virtual memory
editElasticsearch uses a hybrid mmapfs / niofs
directory by default to store its indices. The default
operating system limits on mmap counts is likely to be too low, which may
result in out of memory exceptions. On Linux, you can increase the limits by
running the following command as root
:
sysctl -w vm.max_map_count=262144
To set this value permanently, update the vm.max_map_count
setting in
/etc/sysctl.conf
.
If you installed Elasticsearch using a package (.deb, .rpm) this setting will be changed automatically. To verify, run sysctl vm.max_map_count
.
Memory Settings
editThe Linux kernel tries to use as much memory as possible for file system caches and eagerly swaps out unused application memory, possibly resulting in the elasticsearch process being swapped. Swapping is very bad for performance and for node stability, so it should be avoided at all costs.
There are three options:
-
Disable swap
The simplest option is to completely disable swap. Usually Elasticsearch is the only service running on a box, and its memory usage is controlled by the
ES_HEAP_SIZE
environment variable. There should be no need to have swap enabled. On Linux systems, you can disable swap temporarily by running:sudo swapoff -a
. To disable it permanently, you will need to edit the/etc/fstab
file and comment out any lines that contain the wordswap
. -
Configure
swappiness
The second option is to ensure that the sysctl value
vm.swappiness
is set to0
. This reduces the kernel’s tendency to swap and should not lead to swapping under normal circumstances, while still allowing the whole system to swap in emergency conditions.From kernel version 3.5-rc1 and above, a
swappiness
of0
will cause the OOM killer to kill the process instead of allowing swapping. You will need to setswappiness
to1
to still allow swapping in emergencies. -
mlockall
The third option on Linux/Unix systems only, is to use mlockall to try to lock the process address space into RAM, preventing any Elasticsearch memory from being swapped out. This can be done, by adding this line to the
config/elasticsearch.yml
file:bootstrap.mlockall: true
After starting Elasticsearch, you can see whether this setting was applied successfully by checking the value of
mlockall
in the output from this request:curl http://localhost:9200/_nodes/process?pretty
If you see that
mlockall
isfalse
, then it means that the themlockall
request has failed. The most probable reason is that the user running Elasticsearch doesn’t have permission to lock memory. This can be granted by runningulimit -l unlimited
asroot
before starting Elasticsearch.Another possible reason why
mlockall
can fail is that the temporary directory (usually/tmp
) is mounted with thenoexec
option. This can be solved by specifying a new temp directory, by starting Elasticsearch with:./bin/elasticsearch -Djna.tmpdir=/path/to/new/dir
mlockall
might cause the JVM or shell session to exit if it tries to allocate more memory than is available!
Elasticsearch Settings
editelasticsearch configuration files can be found under ES_HOME/config
folder. The folder comes with two files, the elasticsearch.yml
for
configuring Elasticsearch different
modules, and logging.yml
for
configuring the Elasticsearch logging.
The configuration format is YAML. Here is an example of changing the address all network based modules will use to bind and publish to:
network : host : 10.0.0.4
Paths
editIn production use, you will almost certainly want to change paths for data and log files:
path: logs: /var/log/elasticsearch data: /var/data/elasticsearch
Cluster name
editAlso, don’t forget to give your production cluster a name, which is used to discover and auto-join other nodes:
cluster: name: <NAME OF YOUR CLUSTER>
Node name
editYou may also want to change the default node name for each node to something like the display hostname. By default Elasticsearch will randomly pick a Marvel character name from a list of around 3000 names when your node starts up.
node: name: <NAME OF YOUR NODE>
Internally, all settings are collapsed into "namespaced" settings. For
example, the above gets collapsed into node.name
. This means that
its easy to support other configuration formats, for example,
JSON. If JSON is a preferred configuration format,
simply rename the elasticsearch.yml
file to elasticsearch.json
and
add:
Configuration styles
edit{ "network" : { "host" : "10.0.0.4" } }
It also means that its easy to provide the settings externally either
using the ES_JAVA_OPTS
or as parameters to the elasticsearch
command, for example:
$ elasticsearch -Des.network.host=10.0.0.4
Another option is to set es.default.
prefix instead of es.
prefix,
which means the default setting will be used only if not explicitly set
in the configuration file.
Another option is to use the ${...}
notation within the configuration
file which will resolve to an environment setting, for example:
{ "network" : { "host" : "${ES_NET_HOST}" } }
The location of the configuration file can be set externally using a system property:
$ elasticsearch -Des.config=/path/to/config/file
Index Settings
editIndices created within the cluster can provide their own settings. For example, the following creates an index with memory based storage instead of the default file system based one (the format can be either YAML or JSON):
$ curl -XPUT http://localhost:9200/kimchy/ -d \ ' index : store: type: memory '
Index level settings can be set on the node level as well, for example,
within the elasticsearch.yml
file, the following can be set:
index : store: type: memory
This means that every index that gets created on the specific node started with the mentioned configuration will store the index in memory unless the index explicitly sets it. In other words, any index level settings override what is set in the node configuration. Of course, the above can also be set as a "collapsed" setting, for example:
$ elasticsearch -Des.index.store.type=memory
All of the index level configuration can be found within each index module.
Logging
editElasticsearch uses an internal logging abstraction and comes, out of the
box, with log4j. It tries to simplify
log4j configuration by using YAML to configure it,
and the logging configuration file is config/logging.yml
. The
JSON and
properties formats are also
supported. Multiple configuration files can be loaded, in which case they will
get merged, as long as they start with the logging.
prefix and end with one
of the supported suffixes (either .yml
, .yaml
, .json
or .properties
)
[1.5.0]
Added in 1.5.0. Previously only the logging.
prefix was required
.
The logger section contains the java packages and their corresponding log
level, where it is possible to omit the org.elasticsearch
prefix. The
appender section contains the destinations for the logs. Extensive information
on how to customize logging and all the supported appenders can be found on
the log4j documentation.
[1.5.0] Added in 1.5.0. Additional Appenders and other logging classes provided by log4j-extras are also available, out of the box.