ElasticSearch Fielddata断路器配置

Question

我按照wiki Limiting Memory Usage调整ElasticSearch集群的fielddata缓存。我发现fielddata断路器（indices.breaker.fielddata.limit）没有像维基中所解释的那样工作。我期待它阻止超过限制的查询，但它似乎控制了总fielddata缓存的数量。

系统规范：

• ElasticSearch版本：1.7（旧版系统......）
• 车队中的8名主持人
• 对所有未分析的字段使用doc_value
• Java堆内存大小：4 GB
• indices.fielddata.cache.size =＆＃34; 2gb＆＃34;;
• indices.breaker.fielddata.limit =＆＃34; 200mb＆＃34 ;; //我将其设置为低测试用途

实验：

1. 按curl -XPOST 'http://localhost:9200/_cache/clear?fielddata=true'
清除缓存
2. 通过Kibana对分析的字段A发出简单的排序请求。它成功地平均加载了大约193.05 MB的fielddata。 curl -XGET 'localhost:9200/_cat/fielddata?v&pretty'
3. 再次清除缓存。
4. 通过Kibana对另一个分析的字段B发出排序请求。它成功地平均加载了大约193.9 MB的fielddata。这表明这两个请求都没有加载超过200 MB限制的数据。
5. 在不清除缓存的情况下，在步骤2中发出相同的请求。集群返回部分数据，并且抱怨字段数据的Shard Failure Error太大。如果我检查缓存大小，则字段A仅部分加载到某些主机上，字段A和B上的缓存大小总和接近200 MB。

为什么即使查询未超过断路器中指定的200 MB限制，步骤5中的查询也会被阻止？似乎断路器限制了集群可以加载到fielddata的数据量？是不是由 indices.fielddata.cache.size 控制？

除了有两个部分我在维基中发现令人困惑：

  

如果估计的查询大小大于限制，则断路器将被触发，查询将被中止并返回异常。 这在加载数据之前发生，这意味着您不会遇到OutOfMemoryException。

显然，它为字段B加载了一些数据，或者我读错了吗？

  

但是，使用默认设置，旧索引中的fielddata永远不会被驱逐！ fielddata将继续增长，直到您使用fielddata断路器（参见断路器），这将阻止您加载任何更多的fielddata。

等等，断路器是否应该限制查询？它也限制了总尺寸？

如果我错了，请纠正我。谢谢！