Following are some of the basic configuration parameters that can impact the performance of elastic search server.,

Field Data:

As and when the queries are issued, aggregations on analysed strings will load into field data if the field wasn’t previously loaded. This can consume more heap memory and can cause memory leaks. With the setting ( indices.fielddata.cache.size: 20%, Can be set to a percentage of the heap size, or value like 2gb) in place, the least recently used fielddata will be evicted to make space for newly loaded data , this can avoid memory leaks as field data will not be growing abnormally. Also curl API as follows can help in getting fields data usage per node. curl -X GET “localhost:9200/_nodes/stats/indices/fielddata?fields=*”

Index Buffer:

Increase the size of the indexing buffer, This setting (Eg: indices.memory.index_buffer_size 20%) determines how full the buffer can get before its documents are written to a segment on disk. The default setting limits this value to 10 percent of the total heap in order to reserve more of the heap for serving search requests This can also help , with respect to performance.

Swapping

:Elasticsearch performs poorly when the system is swapping the memory, following are some of the options to disable it .

1) sudo swapoff -a , To disable it permanently, you will need to edit the /etc/fstab file and comment out any lines that contain the word swap.

2) Edit config file provided by elastic search with parameter as bootstrap.memory_lock: true. To check these changes are effected , use the curl command. curl -X GET “localhost:9200/_nodes?filter_path=**.mlockall” , If you see that mlockall is false, then it means that the mlockall request has failed. We can do the following to set the same Set ulimit -l unlimited as root before starting Elasticsearch, or set memlock to unlimited in /etc/security/limits.conf.

Threads:

Elasticsearch uses a number of thread pools for different types of operations. Elasticsearch user can create is at least 4096.This can be done by setting ulimit -u 4096 as root before starting Elasticsearch, or by setting nproc to 4096 in /etc/security/limits.conf.

Heap memmory:

Heap size to avoid out of memory ,its recommended to always have maximum heap size to 50% of available physical RAM. Setting the following parameters in JVM.options can help to increase heap space ,eg: -Xms10g -Xmx10gNote: Dont cross Don’t cross the 32 GB limit , using -Xmx32g or higher results in the JVM using larger, 64-bit pointers that need more memory.

Virtual memory:

Elasticsearch uses a mmapfs directory by default to store its indices. The default operating system limits on mmap counts is likely to be too low, which may result in out of memory exceptions. On Linux, you can increase the limits by running the command sysctl -w vm.max_map_count=262144 as rootTo set this value permanently, update the vm.max_map_count setting in /etc/sysctl.conf. To verify after rebooting, run sysctl vm.max_map_count

References:

https://www.oreilly.com/ideas/10-elasticsearch-metrics-to-watch

http://www.pipebug.com/elasticsearch-logstash-kibana-4-mapping-2.html

https://www.elastic.co/blog/support-in-the-wild-my-biggest-elasticsearch-problem-at-scale

https://www.datadoghq.com/blog/elasticsearch-performance-scaling-problems/

https://logz.io/blog/the-top-5-elasticsearch-mistakes-how-to-avoid-them/

https://www.ebayinc.com/stories/blogs/tech/elasticsearch-performance-tuning-practice-at-ebay/

https://www.elastic.co/guide/en/elasticsearch/reference/current/shard-request-cache.html