0

我有一个具有 16 个节点（13 个数据节点/3 个主节点/24 GB RAM/12 GB 堆）的 Elastic Search 5.2 集群。我正在对查询进行性能测试，并在 Elastic 集群上每秒调用 50 次搜索查询。我的查询如下所示 -

{
    "query": {
        "bool": {
            "must": [
                {
                    "term": {
                        "cust_id": "AC-90-464690064500"
                    }
                },
                {
                    "range": {
                        "yy_mo_no": {
                            "gt": 201701,
                            "lte": 201710
                        }
                    }
                }
            ]
        }
    }
}

我的索引映射如下 -

cust_id      Keyword
smry_amt     Long
yy_mo_no     Integer    // doc_values enabled
mkt_id       Keyword
. . .
. . .
currency_cd  Keyword   // Total 10 field with 8 Keyword type

该索引包含 2 亿条记录，对于每个 cust_id，可能有 100 条记录。索引有 2 个副本。记录大小小于 100 字节。

当我运行性能测试 10 分钟时，查询响应和性能似乎很慢。在 Kibana 监控选项卡中进行更多详细调查后，似乎发生了很多垃圾收集活动（请参见下图）-

范围搜索操作时的垃圾收集

我有几个问题在我脑海中浮现。我对 Range 查询进行了一些研究，但在与我的情况类似的情况下没有发现什么会导致 GC 活动。我还研究了内存使用和 GC 活动，但大多数 Elastic 文档都提到年轻代 GC 在 Indexing 时是正常的，而搜索活动主要使用 OS 维护的文件系统缓存。这就是为什么在上面的图表中，由于搜索使用的是文件系统缓存，所以堆的使用并不多。

所以 -

  1. 什么可能导致垃圾收集在这里发生？
  2. 该图表显示，Elastic Search 仍然可以使用堆，与可用堆相比，使用的堆仍然非常少。那么是什么触发了 GC 呢？
  3. 查询类型是否会导致创建任何内部数据结构被丢弃，从而导致 GC ？
  4. CPU 峰值可能是由于GC活动造成的。
  5. 在 Elastic Search 5.5 之前的版本中是否有其他有效的方法来运行 Range 查询？
  6. 分析查询表明 Elastic 正在运行TermQuery和BooleanQuery，后者的成本最高。

知道这里发生了什么吗？

提前致谢，

  • SGSI。
4

1 回答 1

0

正确答案取决于索引设置，但我猜您使用的是启用了 docValues 的整数类型。该数据结构应该支持聚合和排序，但不支持范围查询。正确的数据类型是range。

如果 DocValues 弹性/lucene 迭代所有文档（即全扫描）以匹配范围查询 - 这需要读取和解码 DV 列中的每个值 - 此操作非常昂贵，特别是当索引不能被缓存时操作系统。

于 2017-10-23T20:50:54.857 回答