Question

以下聚合查询用于在10秒内运行。突然间完成需要5分钟以上。不知道改变了什么。

查询：

    time curl -XGET http://localhost:9200/metric_alias/metrics/_search\?pretty\&routing\=123456 -d '{
      "size": 0,
      "query": { 
        "bool": { 
          "must": [ { 
               "term": { 
                  "tenantId": 123456 
               } 
             }, 
                { 
                "regexp": { 
                   "metric_name": {
                       "value": "[^.]*[.][^.]*" 
                   } 
                } 
             } ] 
          } 
       },
      "aggs": {
          "metric_name_tokens": {
              "terms": {
                  "field" : "metric_name",
                  "include": "[^.]*[.][^.]*",
                  "execution_hint": "map",
                  "size": 0
              }
          }
      }
  }' -o test.out

我甚至尝试使用以下命令清除字段数据缓存后运行查询

curl -XPOST 'http://localhost:9200/_cache/clear' -d '{ "fielddata": "true" }'

几个月前我们改变了这些设置。不要相信我们看到的问题与此相关，因为它甚至在清除了字段数据缓存后也会发生。

indices.breaker.fielddata.limit is set to 85%
indices.fielddata.cache.size is set to 75%

我在查询运行时记录了热线程。我在这里复制了输出 https://gist.github.com/ChandraAddala/180e1d7df9e6f232344c1fe0109b01be

有关如何调试问题的任何想法？

环境：弹性搜索1.7.1。它是一个3节点集群，具有125G RAM和40个内核。 ES运行时堆大小为31G。 metric_alias仅触及2个索引（一个不再更新）。大约20GB的数据。运行查询时，我没有看到CPU和堆使用情况有任何不同。

Answer 1

根据elastic.co's doc

indices.fielddata.cache.size和indices.breaker.fielddata.limit之间的关系非常重要。如果断路器限制低于高速缓存大小，则不会驱逐任何数据。为了使其正常工作，断路器限制必须高于缓存大小。

indices.breaker.fielddata.limit is set to 85%
indices.fielddata.cache.size is set to 75%

我认为您的indices.breaker.total.limit未设置，默认为70%。因此，即使您的indices.breaker.fielddata.limit设置为85% indices.breaker.total.limit，也会限制其功能。

indices.breaker.total.limit：总断路器包裹请求和fielddata断路器，以确保两者的组合默认不超过70％的堆。

尝试：

将indices.breaker.fielddata.limit增加到>85%值。
减少indices.breaker.fielddata.limit和indices.fielddata.cache.size小于60%，因为为什么单个查询需要超过堆的60％？

弹性搜索：聚合查询非常慢

1 个答案: