ElasticSearch circuit_breaking_exception(数据太大)与重要的术语聚合

esp*_*esp 9 elasticsearch significant-terms

查询:

{
  "aggregations": {
    "sigTerms": {
      "significant_terms": {
        "field": "translatedTitle"
      },
      "aggs": {
        "assocs": {
          "significant_terms": {
            "field": "translatedTitle"
          }
        }
      }
    }
  },
  "size": 0,
  "from": 0,
  "query": {
    "range": {
      "timestamp": {
        "lt": "now+1d/d",
        "gte": "now/d"
      }
    }
  },
  "track_scores": false
}
Run Code Online (Sandbox Code Playgroud)

错误:

{
  "bytes_limit": 6844055552,
  "bytes_wanted": 6844240272,
  "reason": "[request] Data too large, data for [<reused_arrays>] would be larger than limit of [6844055552/6.3gb]",
  "type": "circuit_breaking_exception"
}
Run Code Online (Sandbox Code Playgroud)

索引大小为 5G。集群需要多少内存来执行这个查询?

And*_*fan 9

我不确定你想要做什么,但我很想知道。既然你得到了那个例外,我可以假设那个字段的基数不小。我想,您基本上是想根据重要性查看该领域中所有术语之间的关系。

第一个significant_terms聚合将考虑该字段中的所有术语并确定它们的“重要性”(计算该术语在整个索引中的频率,然后将这些频率与range查询文档集中的频率进行比较)。

在它这样做之后(对于所有术语),您需要第二个significant_aggregation应该做第一步,但现在考虑每个术语并为它做另一个significant_aggregation。那会很痛苦 基本上,您正在计算number_of_term * number_of_terms重要的术语计算。

最大的问题是你想做什么?

如果您想查看该领域中所有术语之间的关系,由于上述原因,这将是昂贵的。我的建议是运行第一个significant_terms聚合,取前 10 个左右的术语,然后使用另一个significant_terms聚合运行第二个查询,但通过可能进行父terms聚合来限制这些术语,并且只包含第一个查询中的 10 个。

您还可以查看采样器聚合并将其用作唯一一个重要术语聚合的父项。

另外,我不认为增加断路器限制是真正的解决方案。选择这些限制是有原因的。您可以增加它,也许它会起作用,但它必须让您问自己这是否是您的用例的正确查询(因为它听起来不像)。它在异常中的那个限制值可能不是最后一个...reused_arrays指的是 Elasticsearch 中的一个可调整大小的数组类,所以如果需要更多元素,数组大小会增加,你可能会再次击中断路器,对于另一个价值。


Val*_*Val 6

您可以尝试将配置文件中的请求断路器限制增加到 41%(默认为 40%)elasticsearch.yml并重新启动集群:

indices.breaker.request.limit: 41%
Run Code Online (Sandbox Code Playgroud)

或者,如果您不想重新启动集群,则可以使用以下方法动态更改设置:

curl -XPUT localhost:9200/_cluster/settings -d '{
  "persistent" : {
    "indices.breaker.request.limit" : "41%" 
  }
}'
Run Code Online (Sandbox Code Playgroud)

根据显示的数字(即"bytes_limit": 6844055552, "bytes_wanted": 6844240272)判断,您只缺少约 190 KB 的堆,因此增加 1% 到 41% 您应该为您的请求断路器获得 17 MB 的额外堆(您的总堆 = 约 17GB)应该足够了。

请确保不要将此值增加得太高,因为您可能会面临 OOM 的风险,因为请求断路器还与 fielddata 断路器和其他组件共享堆。

  • 这不是所需内存估计的工作方式 - `bytes_wanted` 不是一个准确的数字,而是一个近似值。将限制提高一小部分可能会导致相同的错误,只是 `bytes_limit`/`bytes_wanted` 值略高。 (3认同)

小智 5

断路器旨在处理请求处理需要的内存多于可用内存的情况。您可以使用以下查询设置限制

PUT /_cluster/settings
{
  "persistent" : {
    "indices.breaker.request.limit" : "45%" 
  }
}
Run Code Online (Sandbox Code Playgroud)

您可以获得更多信息

https://www.elastic.co/guide/en/elasticsearch/reference/current/ Circuit -breaker.html https://www.elastic.co/guide/en/elasticsearch/reference/1.4/index-modules-fielddata .html