123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103 |
- [[setup-configuration-memory]]
- === Disable swapping
- Most operating systems try to use as much memory as possible for file system
- caches and eagerly swap out unused application memory. This can result in
- parts of the JVM heap being swapped out to disk.
- Swapping is very bad for performance and for node stability and should be
- avoided at all costs. It can cause garbage collections to last for **minutes**
- instead of milliseconds and can cause nodes to respond slowly or even to
- disconnect from the cluster.
- There are three approaches to disabling swapping:
- [[mlockall]]
- ==== Enable `bootstrap.memory_lock`
- The first option is to use
- http://opengroup.org/onlinepubs/007908799/xsh/mlockall.html[mlockall] on Linux/Unix systems, or https://msdn.microsoft.com/en-us/library/windows/desktop/aa366895%28v=vs.85%29.aspx[VirtualLock] on Windows, 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:
- [source,yaml]
- --------------
- bootstrap.memory_lock: true
- --------------
- WARNING: `mlockall` might cause the JVM or shell session to exit if it tries
- to allocate more memory than is available!
- After starting Elasticsearch, you can see whether this setting was applied
- successfully by checking the value of `mlockall` in the output from this
- request:
- [source,sh]
- --------------
- GET _nodes?filter_path=**.mlockall
- --------------
- // CONSOLE
- If you see that `mlockall` is `false`, then it means that the `mlockall`
- request has failed. You will also see a line with more information in the
- logs with the words `Unable to lock JVM Memory`.
- The most probable reason, on Linux/Unix systems, is that the user running
- Elasticsearch doesn't have permission to lock memory. This can be granted as follows:
- `.zip` and `.tar.gz`::
- Set <<ulimit,`ulimit -l unlimited`>> as root before starting Elasticsearch,
- or set `memlock` to `unlimited` in
- <<limits.conf,`/etc/security/limits.conf`>>.
- RPM and Debian::
- Set `MAX_LOCKED_MEMORY` to `unlimited` in the
- <<sysconfig,system configuration file>> (or see below for systems using `systemd`).
- Systems using `systemd`::
- Set `LimitMEMLOCK` to `infinity` in the <<systemd,systemd configuration>>.
- Another possible reason why `mlockall` can fail is that the temporary directory
- (usually `/tmp`) is mounted with the `noexec` option. This can be solved by
- specifying a new temp directory, by starting Elasticsearch with:
- [source,sh]
- --------------
- ./bin/elasticsearch -Djava.io.tmpdir=/path/to/temp/dir
- --------------
- or using the `ES_JAVA_OPTS` environment variable:
- [source,sh]
- --------------
- export ES_JAVA_OPTS="$ES_JAVA_OPTS -Djava.io.tmpdir=/path/to/temp/dir"
- ./bin/elasticsearch
- --------------
- [[disable-swap-files]]
- ==== Disable all swap files
- The second option is to completely disable swap. Usually Elasticsearch
- is the only service running on a box, and its memory usage is controlled
- by the JVM options. 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
- word `swap`.
- On Windows, the equivalent can be achieved by disabling the paging file entirely
- via `System Properties → Advanced → Performance → Advanced → Virtual memory`.
- [[swappiness]]
- ==== Configure `swappiness`
- The second option available on Linux systems is to ensure that the sysctl value
- `vm.swappiness` is set to `1`. 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.
|