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_count high enough for mmap-based index storage (for example 1048576 when required).
Increase the maximum number of threads: Allow the Elasticsearch user to create at least 4096 threads 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_retries2 so node and network failures are detected sooner than the Linux default (Linux only).

How these limits are enforced

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.

Tip

For examples of applying the relevant settings in a Docker environment, refer to Using the Docker images in production.

Use dedicated hosts

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.