Important system configuration
Self Managed
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:
- Configure system settings
- Disable swapping
- Increase virtual memory
- Increase the maximum number of threads
- DNS cache settings
- Increase the file descriptor limit (Linux and MacOS only)
- Ensure JNA temporary directory permits executables (Linux only)
- Decrease the TCP retransmission timeout (Linux only)
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.
Elasticsearch has bootstrap checks that run at startup to ensure that users have configured all important settings.
For a list of the checks and their meaning, refer to Bootstrap checks.
By default, Elasticsearch assumes that you are working in development mode. If any of the above settings are not configured correctly, the relevant bootstrap check will fail and a warning will be written to the log file, but you will be able to start and run your Elasticsearch node.
As soon as you configure a network setting like network.host, Elasticsearch assumes that you are moving to production and will upgrade the above warnings to exceptions. These exceptions will prevent your Elasticsearch node from starting. This is an important safety measure to ensure that you will not lose data because of a misconfigured server.