Indices.breaker.fielddata.limit

[jeroen1]

I am running ES 6 in production and was testing our application in development for use with the latest ES 7. Things break. The issue is related to the default value of indices.breaker.fielddata.limit. In 6, the default is 60% https://www.elastic.co/guide/en/elasticsearch/reference/6.6/circuit-breaker.html, in 7 it is 40% https://www.elastic.co/guide/en/elasticsearch/reference/7.2/circuit-breaker.html. What's the reason behind this significant change?

Also I noted that for our application, indices.breaker.fielddata.limit needs to be increased even further on ES 7, using the same jvm.options. So it seems that ES 7 is using more memory. What is the cause of this (new bundled JVM, Lucene 8, ...)?

Thanks!

[HenningAndersen]

@jeroen1 the primary reason the default has been lowered is that most use cases should now use doc values instead.

This was noted here:
https://www.elastic.co/guide/en/elasticsearch/reference/current/breaking-changes-7.0.html#_field_data_circuit_breaker_changes

and this issue contains the background.

Issue: Cap indices.fielddata.cache.size by default?

If possible, converting to using doc values instead of field data is preferable.

[jeroen1]

Thanks! Although I still don't fully understand: doc_values was already enabled in ES 5 by default

My other (unanswered) question: why do I need a higher value for indices.breaker.fielddata.limit in ES 7, compared to same setup in ES 6 (same dataset, same system, same JVM settings)? Are there more changes under the hood? Or is this related to the bundled JVM (I was using OpenJDK8 before) or Lucene 7 --> 8?

[HenningAndersen]

@jeroen1, yes, this could have been narrowed that in 5, but finally got included into 7.

I have not found a cause for needing a higher limit. One option could be that your shards have moved around during upgrade and thus might be less perfectly balanced towards fielddata?

I would doubt that the JVM change has anything to do with it unless you are using very close to 32GB heap and it crossed the line to not use compressed oops.