Elasticsearch memory requirements

The Elasticsearch process is very memory intensive. Elasticsearch uses a JVM (Java Virtual Machine), and close to 50% of the memory available on a node should be allocated to JVM. The JVM machine uses memory because the Lucene process needs to know where to look for index values on disk. The other 50% is required for the file system cache which keeps data that is regularly accessed in memory.

For a full explanation of JVM management, please see: Heap Size Usage and JVM Garbage Collection in ES – A Detailed Guide. 

It is also common to receive warnings from the different types of circuit breakers. This is discussed here: How to Handle Circuit Breaker Exceptions in Elasticsearch. 

jvm.mem

The most important memory section is the JVM heap. 

GET _nodes/stats/jvm

The output could look like this:

"jvm" : {
    	"timestamp" : 1603351829573,
    	"uptime_in_millis" : 150932107,
    	"mem" : {
      	"heap_used_in_bytes" : 258714272,
      	"heap_used_percent" : 24,
      	"heap_committed_in_bytes" : 1073741824,
      	"heap_max_in_bytes" : 1073741824,
      	"non_heap_used_in_bytes" : 192365488,

      	"non_heap_committed_in_bytes" : 209186816,

Note that the heap_used_in_bytes in a healthy JVM will follow a saw tooth pattern due to the garbage collection process, increasing steadily up to around 70%, then reducing sharply to 30% when garbage collection occurs.  

The JVM heap_max will depend on the value set in jvm.options file, and you should set it to be 50% of the RAM available for your container or server.

For more information on JVM heap issues, please see: Heap Size Usage and JVM Garbage Collection in ES – A Detailed Guide. 

Explaining the different types of memory statistics

When looking at the memory statistics, we need to be aware that many Elasticsearch applications are running inside containers on much larger machines. This is typical if you are using a hosted service such as AWS Elasticsearch service or Elastic cloud, or if you are running Elasticsearch on Docker or Kubernetes. In such cases, it’s important  to be careful to interpret the memory statistics available to us.

There are various memory statistics available from the Elasticsearch monitoring APIs, as explained below:

GET _nodes/stats/os

 	"os" : {
    	"timestamp" : 1603350306857,
    	"cpu" : {
      	"percent" : 13,
      	"load_average" : {
        	"1m" : 3.37,
        	"5m" : 3.18,
        	"15m" : 2.8
      	}
    	},
    	"mem" : {
      	"total_in_bytes" : 16703369216,
      	"free_in_bytes" : 361205760,
      	"used_in_bytes" : 16342163456,
      	"free_percent" : 2,
      	"used_percent" : 98
    	},
    	"swap" : {
      	"total_in_bytes" : 1023406080,
      	"free_in_bytes" : 1302528,
      	"used_in_bytes" : 1022103552
    	},
    	"cgroup" : {
      	"cpuacct" : {
        	"control_group" : "/",
        	"usage_nanos" : 2669636420088
      	},
      	"cpu" : {
        	"control_group" : "/",
        	"cfs_period_micros" : 100000,
        	"cfs_quota_micros" : -1,
        	"stat" : {
          	"number_of_elapsed_periods" : 0,
          	"number_of_times_throttled" : 0,
          	"time_throttled_nanos" : 0
        	}
      	},
      	"memory" : {
        	"control_group" : "/",
        	"limit_in_bytes" : "9223372036854771712",
        	"usage_in_bytes" : "4525641728"
      	}
    	}
  	}

The above statistics are for a development node running on docker. Let’s interpret the sections we received here:

os.mem

The first section “mem” refers to the host server where the machine is running. In this case we are running on docker, so 16GB refers to the memory of the host machine where the container is running. Note that it is quite normal for a machine to be using close to 100% of its memory, and this does not indicate a problem.

os.swap

The swap section again refers to the host machine. In this case, we can see that the host machine allows swapping. This is quite normal when we are running a container inside a host with swapping still enabled. We can double check that inside the docker container no swap is permitted by running:

GET _nodes?filter_path=**.mlockall

os.cgroup

Finally, we can see the cgroup section which refers to the container itself. In this case the container is using 4GB of memory.

process.mem

We also have access to a statistic virtual memory:

GET _nodes/stats/process

  	"process" : {
    	"timestamp" : 1603352751181,
    	"open_file_descriptors" : 436,
    	"max_file_descriptors" : 1048576,
    	"cpu" : {
      	"percent" : 0,
      	"total_in_millis" : 1964850
    	},
    	"mem" : {
      	"total_virtual_in_bytes" : 5035376640
    	}

Note that total_virtual_in_bytes includes the entire memory available to the process including virtual memory available via mmap. 

Overview

A plugin is used to enhance the core functionalities of Elasticsearch. Elasticsearch provides some core plugins as a part of their release installation. In addition to those core plugins, it is possible to write your own custom plugins as well. There are several community plugins available on GitHub for various use cases.

Examples

Get all of the instructions for the plugin:

sudo bin/elasticsearch-plugin -h

Installing the S3 plugin for storing Elasticsearch snapshots on S3:

sudo bin/elasticsearch-plugin install repository-s3

Removing a plugin:

sudo bin/elasticsearch-plugin remove repository-s3

Installing a plugin using the file’s path:

sudo bin/elasticsearch-plugin install file:///path/to/plugin.zip

Notes and good things to know

• Plugins are installed and removed using the elasticsearch-plugin script, which ships as a part of the Elasticsearch installation and can be found inside the bin/ directory of the Elasticsearch installation path.
• A plugin has to be installed on every node of the cluster and each of the nodes has to be restarted to make the plugin visible.
• You can also download the plugin manually and then install it using the elasticsearch-plugin install command, providing the file name/path of the plugin’s source file.
• When a plugin is removed, you will need to restart every Elasticsearch node in order to complete the removal process.

Common issues

• Managing permission issues during and after plugin installation is the most common problem. If Elasticsearch was installed using the DEB or RPM packages then the plugin has to be installed using the root user. Otherwise you can install the plugin as the user that owns all of the Elasticsearch files.
• In the case of DEB or RPM package installation, it is important to check the permissions of the plugins directory after you install it. You can update the permission if it has been modified using the following command:

chown -R elasticsearch:elasticsearch path_to_plugin_directory 

• If your Elasticsearch nodes are running in a private subnet without internet access, you cannot install a plugin directly. In this case, you can simply download the plugins and copy the files inside the plugins directory of the Elasticsearch installation path on every node. The node has to be restarted in this case as well.

Overview

When indexing data, Elasticsearch requires a “refresh” operation to make indexed information available for search. This means that there is a time delay between indexing and the updated information actually becoming available for the client applications.

How it works

Index operations occur in memory. The operations are accumulated in a buffer until refreshed, which requires that the buffer itself be transferred to a newly created lucene segment. Refresh happens by default every second, but it is also possible to change this frequency for a given index, or directly request a refresh through the refresh api.

Examples

You can set the refresh interval on an index like this:

PUT /my_index/_settings
{
    "index" : {
        "refresh_interval" : "30s"
    }
}

You can use a value of -1 to stop refreshing but remember to set it back once you’ve finished indexing!

You can force a refresh on a given index like this:

POST my_index/_refresh

You can also force a refresh at the end of an index operation by adding an extra parameter in the URL like this:

POST /my_index/_index?refresh=waitfor

In this case, the “waitfor” parameter will force the client to wait for the refresh to complete before returning (useful in scripts), or you can use “true” to force the refresh without keeping the script waiting.

Notes and good things to know

Refreshing is very resource intensive, so you can increase indexing speed by reducing the refresh rate. You can do this temporarily if you need to reload a lot of data. For some logging applications it is perfectly acceptable to have a 30s latency, for instance, before data actually becomes available.

Beware of the refresh interval when scripting or updating. Scripts often work faster than the refresh interval, so if necessary, you might need to call a refresh before retrieving or updating data in your scripts, or use the waitfor parameter while indexing as described above.