Important system configuration
Ideally, Elasticsearch should run alone on a server and use all of the resources available to it. In order to do so, you need to configure your operating system to allow the user running Elasticsearch to access more resources than allowed by default.
The following settings must be considered before going to production:
- Elasticsearch service user requirements: Run as a dedicated unprivileged user, keep numeric UID and GID consistent across nodes, and set correct ownership on config and data paths.
- System settings configuration methods: Where and how to apply operating-system limits and environment variables for your install type.
- Disable swapping: Avoid heap or process memory being swapped out; options include disabling swap, lowering swappiness, and
bootstrap.memory_lock. - Increase virtual memory: Set
vm.max_map_counthigh enough for mmap-based index storage (for example1048576when required). - Increase the maximum number of threads: Allow the Elasticsearch user to create at least
4096threads on Linux when you manage limits yourself. - Increase the file descriptor limit: Raise open file handles to at least
65,535(Linux and macOS only). - Ensure JNA temporary directory permits executables: Ensure JNA and native libraries can execute from a temp path that is not mounted
noexec(Linux only). - Decrease the TCP retransmission timeout: Lower
net.ipv4.tcp_retries2so node and network failures are detected sooner than the Linux default (Linux only).
This page lists operating system limits you must set before Elasticsearch serves production traffic. Elasticsearch verifies many of these expectations through bootstrap checks at node startup. In production mode, a failed check stops the node from starting rather than only logging a warning.
For examples of applying the relevant settings in a Docker environment, refer to Using the Docker images in production.
In production, we recommend you run Elasticsearch on a dedicated host or as a primary service. Several Elasticsearch features, such as automatic JVM heap sizing, assume that Elasticsearch is the only resource-intensive application on the host or container. For example, you might run Metricbeat alongside Elasticsearch for cluster statistics, but a resource-heavy Logstash deployment should be on its own host.