只有 8 个索引的 ElasticSearch 查询已经填满了 search.queue(容量 1000)

Question

我们正在运行版本为 2.3.1 的单个 ES 节点。

有一个查询基本上返回上周(168 小时)每日存储桶中的一些唯一用户(用户 ID 字段的唯一值)。此查询影响 8 个索引。

过去，这样的查询运行得很快。随着时间的推移它变慢了，但现在我们收到了拒绝并且无法弄清楚原因。我们发现当我们运行此查询时 search.queue 立即填满 - 它达到大约 350，然后是 640，然后是 1000，并且拒绝进来(这些步骤在几秒钟内发生，而查询正在运行)。

我不明白这怎么可能，因为它应该只影响 8 个索引，每个索引有 2 个分片，而且它在过去运行良好。

查询是:

GET /abcdefg-2016.09.05%2Cabcdefg-2016.09.06%2Cabcdefg-2016.09.07%2Cabcdefg-2016.09.08%2Cabcdefg-2016.09.09%2Cabcdefg-2016.09.10%2Cabcdefg-2016.09.11%2Cabcdefg-2016.09.12/abcdefg/_search
{
  "sort": {},
  "from": 0,
  "size": 0,
  "fields": [
    "*",
    "_source",
    "_field_names"
  ],
  "fielddata_fields": [
    "@timestamp"
  ],
  "query": {
    "filtered": {
      "filter": {
        "bool": {
          "must": [
            {
              "range": {
                "@timestamp": {
                  "gte": 1473073782735,
                  "lte": 1473678582735
                }
              }
            },
            {
              "missing": {
                "field": "demo"
              }
            }
          ],
          "must_not": [],
          "should": []
        }
      }
    }
  },
  "aggs": {
    "date_histogram": {
      "date_histogram": {
        "field": "@timestamp",
        "interval": "1d",
        "min_doc_count": 0,
        "extended_bounds": {
          "min": 1473073782735,
          "max": 1473678582735
        }
      },
      "aggs": {
        "unique_users_count": {
          "cardinality": {
            "field": "usedUID"
          }
        }
      }
    },
    "unique_users_count": {
      "cardinality": {
        "field": "usedUID"
      }
    }
  }
}

当查询卡住时运行 curl localhost:9200/_cat/thread_pool?v 显示:

host      ip        bulk.active bulk.queue bulk.rejected index.active index.queue index.rejected search.active search.queue search.rejected
127.0.0.1 127.0.0.1           0          0             0            0           0              0             4         1000          132228

它将保持这种状态几分钟，然后队列将归零。

可能是什么问题？

编辑: 添加 profile:true 给出此输出:http://pastebin.com/s4jpw36d

EDIT2:最奇怪的是，在配置文件输出中我看到 ES 向 Lucene 发送了大量这些奇怪的查询:

  {
    "query_type": "BooleanQuery",
    "lucene": "@timestamp:0 \u0000\u0000\n[xD @timestamp:0 \u0000\u0000\n[xE @timestamp:0 \u0000\u0000\n[xF @timestamp:0 \u0000\u0000\n[xG @timestamp:0 \u0000\u0000\n[xH @timestamp:0 \u0000\u0000\n[xI @timestamp:0 \u0000\u0000\n[xJ @timestamp:0 \u0000\u0000\n[xK @timestamp:0 \u0000\u0000\n[xL @timestamp:0 \u0000\u0000\n[xM @timestamp:0 \u0000\u0000\n[xN @timestamp:0 \u0000\u0000\n[xO @timestamp:0 \u0000\u0000\n[xP @timestamp:0 \u0000\u0000\n[xQ",
    "time": "61.40814100ms",
    "breakdown": {
      "score": 0,
      "create_weight": 357521,
      "next_doc": 40988029,
      "match": 0,
      "build_scorer": 2733654,
      "advance": 0
    },
    "children": [
      {
        "query_type": "TermQuery",
        "lucene": "@timestamp:0 \u0000\u0000\n[xD",
        "time": "0.1429700000ms",
        "breakdown": {
          "score": 0,
          "create_weight": 21940,
          "next_doc": 99164,
          "match": 0,
          "build_scorer": 21866,
          "advance": 0
        }
      },
      {
        "query_type": "TermQuery",
        "lucene": "@timestamp:0 \u0000\u0000\n[xE",
        "time": "0.5797620000ms",
        "breakdown": {
          "score": 0,
          "create_weight": 64810,
          "next_doc": 501767,
          "match": 0,
          "build_scorer": 13185,
          "advance": 0
        }
      }, 
      ...
    ]
  }

EDIT3: 好吧，这似乎是故意的:https://discuss.elastic.co/t/es-rewriting-range-to-timestamp-to-booleanquery-termquery-why/56363 - 然而，它现在会使查询无法使用，阻塞否则为空的队列，这对我来说没有意义...

Answer 1

回复:EDIT3。我预感该优化中存在错误(“重写范围...”)

切换代码看TermsEnum MultiTermQueryConstantScoreWrapper.java:147在决定是否将范围查询重写为 bool 值时。如果 TermsEnum.next() 返回 null(我相信它会，当该字段没有术语向量时)，那么 collectTerms方法返回 true(并且查询被重写为 bool 查询......即使没有术语向量!)

通过从此处查询的字段缓存中提取 @timestamp，您正在做一些不标准的事情:

  "fielddata_fields": [
    "@timestamp"
  ],

您正在使用 fielddata 解决方法这一事实表明您可能没有使用范围优化所期望的时间戳字段存储术语信息(无论如何您为什么要这样做？!)。但是随后您要传递对在查询时从字段缓存重建的字段的引用(这不太可能是预先存在的测试覆盖范围)。

---

作为解决方法和一般调优改进，我会确保您没有禁用 docvalues对于您的时间戳字段(在您的索引映射中)，然后直接在您的聚合中引用您的时间戳字段(timestamp vs @timestamp)。如果您在映射中明确禁用了 timestamp 的文档值，那么您将不得不重新索引旧数据，或者只是等到您的索引更改向前滚动到足以让您的查询成功(所有干净的索引).

Docvalues 是当今聚合的最佳实践。对于支持它们的字段类型，它们在 ES 2.0+ 中默认启用，并且它们可以避免许多性能问题 w.r.t.聚合(并且还可能让您避免任何意想不到的“优化”问题!)

这是一篇很好的帖子，讨论了字段缓存引入的规模问题以及为什么应该使用文档值:https://www.elastic.co/blog/support-in-the-wild-my-biggest-elasticsearch-problem-at-scale