elasticsearch Elasticsearch 1.5.2部署问题,elasticsearch,kibana,elasticsearch,Kibana" /> elasticsearch Elasticsearch 1.5.2部署问题,elasticsearch,kibana,elasticsearch,Kibana" />
Fatal编程技术网

elasticsearch Elasticsearch 1.5.2部署问题

kibana

elasticsearch Elasticsearch 1.5.2部署问题,elasticsearch,kibana,elasticsearch,Kibana,我有以下规格的ES 1.5.2群集： 3个节点，RAM:32GB，每个CPU核8个 282总指数 2564总碎片数 799505935总文档数 767.84GB总数据量 ES_堆大小=16g 问题是，当我使用Kibana查询某些东西（非常简单的查询）时，如果它只是一个查询，那么它工作得很好，但是如果我继续查询一些更灵活的东西，那么弹性会变得非常慢，最终会被卡住，因为JVM堆使用率（来自Marvel）将达到87-95%。当我尝试加载一些Kibana仪表板时也会发生这种情况，这种情况的唯一解决方

我有以下规格的ES 1.5.2群集：

  • 3个节点，RAM:32GB，每个CPU核8个
  • 282总指数
  • 2564总碎片数
  • 799505935总文档数
  • 767.84GB总数据量
  • ES_堆大小=16g
问题是，当我使用Kibana查询某些东西（非常简单的查询）时，如果它只是一个查询，那么它工作得很好，但是如果我继续查询一些更灵活的东西，那么弹性会变得非常慢，最终会被卡住，因为JVM堆使用率（来自Marvel）将达到87-95%。当我尝试加载一些Kibana仪表板时也会发生这种情况，这种情况的唯一解决方案是重新启动所有节点上的服务

（这也发生在ES 2.2.0、1节点和Kibana 4上）

怎么了，我错过了什么？ 我应该少问一点吗

编辑：

我不得不提到，我有很多空索引（0个文档），但是碎片被计算在内。这是因为我在4w的文档上设置了ttl，空索引将被curator删除

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

  • 3个节点，RAM:32GB，每个CPU核8个
  • 282总指数=227空+31惊奇漫画+1基巴纳+23数据
  • 2564个碎片总数=（1135个空碎片+31个惊奇漫画+1个kibana+115个数据）*1个副本
  • 799505935总文档数
  • 767.84GB总数据量
  • ES_堆大小=16g
curl\u 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所建议的，问题可能在于字段数据没有边界。我建议在适当的地方检查您的映射、使用和属性，以降低查询成本。

  • 删除空索引
  • 对于1.5集群，堆的主要用途是用于fielddata—每个节点约9.5GB，过滤器缓存约1.2GB，段文件元数据约1.7GB
    • 即使您的模板中有该代码片段，使
      字符串成为
      未分析的
      ，在1.5中，这并不自动意味着ES将使用
      文档值
      ，您也需要这样做
    • 如果现在在1.5.x集群中启用
      doc\u值
      ，则更改将在新索引中生效。对于旧索引，您需要重新索引数据。或者，如果你有基于时间的索引（每天、每周等），你只需要等待新的索引被创建，旧的索引被删除
    • 在
      doc_值
      将在1.5集群的索引中占据主导地位之前，@Val在评论中建议的是唯一的选项：或向集群添加更多节点（隐含更多内存），或增加节点上的RAM。或；-）不时地
  • 与内存问题无关，但尽量避免使用ttl。如果您不再需要一些数据，只需删除索引，不要依赖于
    ttl
    ，这比简单地删除索引要昂贵得多。使用
    ttl
    creates可能会在搜索时引起问题，并影响集群的整体性能，因为它会从索引中删除文档，这意味着需要大量更新和合并这些索引。由于您可能有基于时间的索引（这意味着昨天的数据实际上没有变化），因此使用ttl会对本来应该是静态的（并且可能是静态的）数据进行不必要的操作
好的，这些是大量的碎片，我几乎可以肯定，给定正确的查询和正确的时间跨度，您将用fielddata填充内存。达到高堆使用率后，运行
GET/_nodes/stats
，并在gist中的某个地方提供输出。提供指向该输出的链接。在ES 2.x.@Rada中也要这样做，如果fielddata的使用确实是问题所在（而且可能是问题所在），一个解决方案是在
elasticsearch.yml
配置文件中添加以下设置：
index.fielddata.cache:node
和
index.fielddata.cache.size:30%
。30%对我来说是一个负载相似的1.5 ES群集，但您的里程数可能会有所不同。将会发生的是，堆不会被fielddata耗尽，fielddata永远不会超过堆的30%。当然，您将得到大量的逐出（因此查询速度较慢），但至少您不需要如此频繁地重新启动。您还可以添加更多节点以共享负载。请删除空索引。堆的主要用途是用于fielddata—每个节点约9.5GB，过滤器缓存约1.2GB，段文件元数据约1.7GB。奇怪的是，对于2.x来说，仍然有那么多的字段数据。ES 2.x在可能的情况下默认使用
doc\u值。唯一不可能的字段类型是分析字符串。另外，我几乎可以肯定你提供的要点不是来自2.2.0集群，它一定是1.5集群。不，主要问题是1.5.2集群中的fielddata使用情况。我看到了您提供的模板中的代码片段，但是该模板是否正确地应用于索引，这意味着您是否真的将
string
字段设置为
not_analysis
？此外，仅使字符串不在1.5.2中进行分析是不够的，您还需要启用
doc\u值
：直到
doc\u值
在1.5集群的索引中占主导地位，@Val建议的是唯一选项：限制fielddata缓存大小或向集群添加更多节点。或手动清除fielddata缓存；-）我在默认映射中不时使用not_analyze:“default”：{“dynamic_templates”：[{“template_1”：{“mapping”：{“index”：“not_analyze”，“type”：“string”}，