群集停留在高堆使用率

Question

我有 Elasticsearch v 2.2.0群集，1个节点，4g堆大小，7g RAM，2个cpu核心，401个索引，1,873个分片，107,780,287个文档，总数据70.19GB 。

我还配置了 indices.fielddata.cache.size：40％。

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

为什么堆就像这样？

修改

_node/stats when heap is stuck

_node/stats when cluster in normal state

编辑2：

为了更好地理解这个问题，我一直在分析内存转储。这个分析是在集群尝试了一些Kibana查询后执行的：

问题可疑1：

问题疑似2：

问题可疑3：

在某些索引中，我确实有_ttl的设置无效（_ttl设置为4周，但文档仍在那里......）。我从那以后更改了默认映射，但没有删除“not working ttl”索引。

这可能是主要问题吗？

Answer 1

我认为您现在还有其他选择，而不是向群集添加更多节点，增加当前节点的硬件资源或者不在群集中存储那么多索引

对于这样一个小节点你有很多分片，并且所有这些分片都使用一些内存（767MB）来处理常见的事情：术语，规范和分段使用的整体内存。元数据：

    "segments": {
      "count": 14228,
      "memory_in_bytes": 804235553,
      "terms_memory_in_bytes": 747176621,
      "stored_fields_memory_in_bytes": 31606496,
      "term_vectors_memory_in_bytes": 0,
      "norms_memory_in_bytes": 694880,
      "doc_values_memory_in_bytes": 24757556,
      "index_writer_memory_in_bytes": 0,
      "index_writer_max_memory_in_bytes": 1381097464,
      "version_map_memory_in_bytes": 39362,
      "fixed_bit_set_memory_in_bytes": 0
    }

您已移至ES 2.x，这意味着您现在默认使用doc_values，而fielddata用法实际上非常小（11.8MB）：

    "fielddata": {
      "memory_size_in_bytes": 12301920,
      "evictions": 0
    }

旧的过滤器缓存（现在称为查询缓存）也非常小：

    "query_cache": {
      "memory_size_in_bytes": 302888,

清除缓存（fielddata，查询缓存）我不太确定它会产生很大的不同。在收集统计信息时，堆使用率为2.88GB（72％），这不是那么高（JVM触发旧GC的75％）。但是，对我而言，对于那么多碎片来说，这是一个太小的节点。

还有一点需要注意，与内存问题无关：

    "open_file_descriptors": 29461,
    "max_file_descriptors": 65535,

有了这么多打开的文件描述符，我强烈建议increase the OS limit for the count of open file descriptors。