How To Solve Issues Related to Log – Updated breaker settings fielddata:

Get an Elasticsearch Check-Up

Check if your ES issues are caused from misconfigured settings
(Free 2 min process)


Last update: Feb-20

Elasticsearch Error Guide In Page Navigation (click to jump) :

Troubleshooting Background – start here to get the full picture       
Related Issues – selected resources on related issues  
Log Context – usefull for experts
About Opster – offering a diffrent approach to troubleshoot Elasticsearch

Check Your Elasticsearch Settings for Painfull Mistakes 

Troubleshooting background

To troubleshoot Elasticsearch log “Updated breaker settings fielddata:” it’s important to know common problems related to Elasticsearch concepts: breaker, circuit, indices, settings. See below-detailed explanations complete with common problems, examples and useful tips.

Circuit in Elasticsearch

What it is

Circuit breakers are used to prevent operations from causing an OutOfMemoryError in Elasticsearch. There are many settings related to circuit breakers, and each of those settings can be configured using the cluster update API.

There are many types of circuit breakers, such as parent level circuit breakers, request circuit breakers, field data circuit breakers, script compilation circuit breakers and more. All of these put default limits on the amount of memory/heap size that can be used or set a limit on the rate of some other operations that can be done.


Limit the amount of memory used by fielddata to use up to 30% of JVM heap:

PUT /_cluster/settings
    "persistent" : {
           “indices.breaker.fielddata.limit”: “30%”

Putting a limit on the number of dynamic scripts to be compiled in 5 minutes:

PUT /_cluster/settings
    "persistent" : {
        “script.max_compilations_rate” : “50/5m”

Notes and Good Things to Know
  • Script.max_compilations_rate limits the number of scripts that can be compiled in a given time interval, the default is 75 per 5 minutes. If you compile too many unique scripts within a small amount of time, Elasticsearch will reject the new dynamic scripts and throw a circuit_breaking_exception error.
Common Problems:
  • In production you need to limit the amount of heap size used by memory intensive search queries by setting indices.breaker.request.limit to a lower value such as 40%, otherwise this will crash Elasticsearch nodes if the settings are left unbounded or above 70%.
  • Similarly, the nodes can also crash if other circuit breaker limits are not properly configured.
  • In addition, apart from circuit breakers, you will need to limit the number of max search buckets for aggregations as well.

Index in Elasticsearch

What it is

In Elasticsearch, an index (indices in plural) can be thought of as a table inside a database that has a schema and can have one or more shards and replicas. An Elasticsearch index is divided into shards and each shard is an instance of a Lucene index.

Indices are used to store the documents in dedicated data structures corresponding to the data type of fields. For example, text fields are stored inside an inverted index whereas numeric and geo fields are stored inside BKD trees.

Create Index

The following example is based on Elasticsearch version 5.x onwards. An index with two shards, each having one replica will be created with the name test_index1

PUT /test_index1?pretty
    "settings" : {
        "number_of_shards" : 2,
        "number_of_replicas" : 1
    "mappings" : {
        "properties" : {
            "tags" : { "type" : "keyword" },
            "updated_at" : { "type" : "date" }
List Indices

All the index names and their basic information can be retrieved using the following command:

GET _cat/indices?v
Index a document

Let’s add a document in the index with below command:

PUT test_index1/_doc/1
  "tags": [
  "date": "01-01-2020"
Query an index
GET test_index1/_search
  "query": {
    "match_all": {}
Query Multiple Indices

It is possible to search multiple indices with a single request. If it is a raw HTTP request, Index names should be sent in comma-separated format, as shown in the example below, and in the case of a query via a programming language client such as python or Java, index names are to be sent in a list format.

GET test_index1,test_index2/_search
Delete Indices
DELETE test_index1
Common Problems
  • It is good practice to define the settings and mapping of an Index wherever possible because if this is not done, Elasticsearch tries to automatically guess the data type of fields at the time of indexing. This automatic process may have disadvantages, such as mapping conflicts, duplicate data and incorrect data types being set in the index. If the fields are not known in advance, it’s better to use dynamic index templates.
  • Elasticsearch supports wildcard patterns in Index names, which sometimes aids with querying multiple indices, but can also be very destructive too. For example, It is possible to delete all the indices in a single command using the following commands:

To disable this, you can add the following lines in the elasticsearch.yml:

action.destructive_requires_name: true

To help troubleshoot related issues we have gathered selected Q&A from the community and issues from Github , please review the following for further information :

1. Elasticsearch indices.breaker.fielddata.limit settings – Stats : ♥ 4.09 K  Ι √ 2

2. FIELDDATA Data is too large – Stats : ♥ 17.22 K  Ι √    13

Log Context

Log ”Updated breaker settings fielddata:” classname is
We have extracted the following from Elasticsearch source code to get an in-depth context :

                BreakerSettings newFielddataSettings = new BreakerSettings(CircuitBreaker.FIELDDATA; newFielddataLimitBytes; newFielddataOverhead;
                HierarchyCircuitBreakerService.this.fielddataSettings = newFielddataSettings;
      "Updated breaker settings fielddata: {}"; newFielddataSettings);

            // Request settings
            ByteSizeValue newRequestMax = settings.getAsMemory(REQUEST_CIRCUIT_BREAKER_LIMIT_SETTING; null);
            Double newRequestOverhead = settings.getAsDouble(REQUEST_CIRCUIT_BREAKER_OVERHEAD_SETTING; null);

About Opster

Incorporating deep knowledge and broad history of Elasticsearch issues. Opster’s solution identifies and predicts root causes of Elasticsearch problems, provides recommendations and can automatically perform various actions to manage, troubleshoot and prevent issues

Learn more: Glossary | Blog| Troubleshooting guides | Error Repository

Need help with any Elasticsearch issue ? Contact Opster

Did this page help you?