Elasticsearch 1.5.2 部署问题

Elasticsearch 1.5.2 deployment issue

我有 ES 1.5.2 集群，规格如下：

问题是当我使用 Kibana 查询某些东西（非常简单的查询）时，如果它是单个查询它工作正常，但如果我继续查询更多 - 弹性变得如此缓慢并最终卡住是因为 JVM 堆使用率（来自 Marvel）达到 87-95%。当我尝试加载一些 Kibana 仪表板时也会发生这种情况，这种情况的唯一解决方案是重新启动所有节点上的服务。

（这也发生在 ES 2.2.0，1 个节点，Kibana 4）

怎么了，我错过了什么？ 我应该少查询吗？

编辑：

我不得不提一下，我有很多空索引（0 个文档），但分片已计算在内。之所以这样是因为我在文档上设置了 ttl 为 4w，空索引将被 curator 删除。

此外，我们还没有在 1.5.2 和 2.2.0 集群中禁用 doc_values。 准确的规格如下（1.5.2）：

curl _cat/fielddata?v 结果：

1.5.2:

 total os.cpu.usage primaries.indexing.index_total total.fielddata.memory_size_in_bytes jvm.mem.heap_used_percent jvm.gc.collectors.young.collection_time_in_millis primaries.docs.count device.imei fs.total.available_in_bytes os.load_average.1m index.raw @timestamp node.ip_port.raw fs.total.disk_io_op node.name jvm.mem.heap_used_in_bytes jvm.gc.collectors.old.collection_time_in_millis total.merges.total_size_in_bytes jvm.gc.collectors.young.collection_count jvm.gc.collectors.old.collection_count total.search.query_total 
 2.1gb        1.2mb                          3.5mb                                3.4mb                     1.1mb                                                0b                3.5mb       2.1gb                       1.9mb              1.8mb     3.6mb      3.6mb            1.7mb               1.9mb     1.7mb                      1.6mb                                           1.5mb                            3.5mb                                    1.5mb                                  1.5mb                    3.2mb 
 1.9gb        1.2mb                          3.4mb                                3.3mb                     1.1mb                                             1.5mb                3.5mb       1.9gb                       1.9mb              1.8mb     3.5mb      3.6mb            1.7mb               1.9mb     1.7mb                      1.5mb                                           1.5mb                            3.4mb                                       0b                                  1.5mb                    3.2mb 
   2gb           0b                             0b                                   0b                        0b                                                0b                   0b         2gb                          0b                 0b        0b         0b               0b                  0b        0b                         0b                                              0b                               0b                                       0b                                     0b                       0b

2.2.0:

  total index_stats.index node.id node_stats.node_id buildNum endTime location.timestamp userActivity.time startTime   time shard.state shard.node indoorOutdoor.time shard.index dataThroughput.downloadSpeed 
176.2mb                0b      0b                 0b     232b 213.5kb            518.8kb           479.7kb    45.5mb 80.1mb       1.4kb       920b            348.7kb       2.5kb                       49.1mb

如果您的堆在查询时受到快速影响，这意味着您在查询中做了一些非常繁重的事情，例如聚合。正如 val 和 Andrei 所建议的那样，问题可能在于您的现场数据不受限制。我建议检查您的映射并在适用的情况下使用 doc_values and not_analyzed 属性以降低查询成本。

  • 删除空索引
  • 对于 1.5 集群，堆的主要用途是用于字段数据 - 每个节点约 9.5GB，过滤器缓存约 1.2GB，段文件元数据约 1.7GB
    • 即使您的模板中有将 string 设为 not_analyzed 的片段，在 1.5 中这并不自动意味着 ES 将使用 doc_values，您需要specifically enable them.
    • 如果您现在在 1.5.x 集群中启用 doc_values，则更改将对新索引生效。对于旧索引，您需要重新索引数据。或者，如果您有基于时间的索引（每天、每周等创建），您只需要等待创建新索引并删除旧索引。
    • 直到 doc_values 在 1.5 集群的索引中占主导地位，@Val 在评论中建议的是唯一的选择：limit the fielddata cache size or add more nodes to your cluster (and implicitly more memory) or increase the RAM on your nodes. Or manually clear the fielddata cache ;-) 不时。
  • 与内存问题完全无关，但尽量避免使用ttl。如果你不再需要一些数据，直接删除索引，不要依赖ttl，这比简单删除索引的成本要高得多。使用 ttl creates 可能会在搜索时导致问题并影响集群的整体性能，因为它会从索引中删除文档，这意味着对这些索引进行大量更新和大量合并。由于您可能有基于时间的索引（这意味着昨天的数据并没有真正改变），因此使用 ttl 会给数据带来不必要的操作，否则这些数据应该是静态的（并且可能是 optimized）。