Elasticsearch Mastering Elasticsearch Configuration for Optimal Performance

By Opster Team

Updated: Jul 23, 2023

| 2 min read


Elasticsearch, a highly scalable open-source full-text search and analytics engine, is known for its flexibility and ability to handle a large volume of data. However, to fully leverage its capabilities and ensure optimal performance, it’s crucial to understand and correctly configure its settings. This article will delve into the intricacies of Elasticsearch configuration, providing you with the knowledge to fine-tune your Elasticsearch cluster for maximum efficiency.

Understanding Elasticsearch Configuration Files

Elasticsearch uses three main configuration files: `elasticsearch.yml`, `jvm.options`, and `log4j2.properties`. 

  • `elasticsearch.yml`: This YAML file contains settings that pertain to the Elasticsearch node and cluster, such as node name, cluster name, and network settings.
  • `jvm.options`: This file contains settings for the JVM, including initial and maximum heap size.
  • `log4j2.properties`: This file controls the logging level and appender.

Key Elasticsearch Configuration Settings

Cluster and Node Settings

The `elasticsearch.yml` file contains settings that are crucial for the operation of your Elasticsearch cluster. Here are some of the key settings:

  • `cluster.name`: This setting defines the name of your cluster and is essential for the node to join the correct cluster.
  • `node.name`: This setting defines the name of the node. If not set, Elasticsearch will generate a random name at startup.
  • `network.host`: This setting defines the network interface(s) a node should bind to.

JVM Settings

The `jvm.options` file contains settings for the JVM. Here are some of the key settings:

  • `-Xms` and `-Xmx`: These settings define the minimum and maximum heap size, respectively. It’s recommended to set both to the same value to prevent the heap from resizing at runtime, a process that can cause a performance hit.
  • `-XX:+UseConcMarkSweepGC`: This setting enables the CMS garbage collector, which is designed for applications with a large amount of heap memory and short garbage collection pauses. This is the default garbage collector used up until JVM version 13 (i.e. Elasticsearch 7.6 and earlier).
  • `-XX:+UseG1GC`: This setting enables the G1GC garbage collector. This is the default garbage collector used from JVM version 14 and up (i.e. Elasticsearch 7.7+).

It is worth noting that the `jvm.options` file should NOT be modified. If you need to customize the default JVM options for your specific needs, you need to create a new JVM options file with the `.options` extension in the `config/jvm.options.d/` folder. That custom JVM options file will be picked up by Elasticsearch and override the default options.

Logging Settings

The `log4j2.properties` file controls the logging level and appender. Here are some of the key settings:

  • `logger.name.level`: This setting controls the logging level for a specific logger. The level can be set to `TRACE`, `DEBUG`, `INFO`, `WARN`, `ERROR`, or `FATAL`.
  • `appender.name.type`: This setting defines the type of appender. Elasticsearch supports several types of appenders, including `Console`, `File`, and `RollingFile`.

Configuring Elasticsearch for Optimal Performance

To configure Elasticsearch for optimal performance, you need to consider the specific requirements of your use case. However, here are some general recommendations:

  • Set the heap size appropriately: The heap size should be set to a maximum of 50% of your available RAM, but not more than ~30GB. This is to ensure that there’s enough memory left for the operating system and file system cache.
  • Enable bootstrap checks: Bootstrap checks are a set of checks that Elasticsearch performs at startup to prevent common configuration errors. These bootstrap checks are always enabled. A production cluster will refuse to start if any of the bootstrap check fails, while a development cluster will start but log the check failures as a warning.
  • Configure the number of shards and replicas: The number of shards and replicas can have a significant impact on the performance of your cluster. As a general rule, you should aim for a shard size of between 10GB and 50GB and set the number of replicas based on your availability requirements.


In conclusion, understanding and correctly configuring Elasticsearch can significantly improve the performance of your cluster. By mastering the settings in the `elasticsearch.yml`, `jvm.options`, and `log4j2.properties` files, you can fine-tune your Elasticsearch cluster to meet the specific requirements of your use case.

How helpful was this guide?

We are sorry that this post was not useful for you!

Let us improve this post!

Tell us how we can improve this post?