Elasticsearch 1.5.2部署问题

Question

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

• 3个节点，RAM：32GB，CPU内核：每个8
• 282个总指数
• 总分片2,564
• 799,505,935总文档
• 总数据767.84GB
• ES_HEAP_SIZE = 16克

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

（这在带有Kibana 4的ES 2.2.0，1节点上也发生）

怎么了，我想念什么？我想少查询吗？

编辑：

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

此外，我们尚未在1.5.2或2.2.0群集中禁用doc_values。准确的规格如下（1.5.2）：

• 3个节点，RAM：32GB，CPU内核：每个8
• 282总指数= 227空+ 31奇迹+ 1基巴纳+ 23数据
• 2,564总分片=（1135空+ 31奇迹+ 1基巴纳+ 115数据）* 1个副本
• 799,505,935总文档
• 总数据767.84GB
• ES_HEAP_SIZE = 16克

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

Answer 1

• 删除空索引
• 对于1.5群集，堆的主要用途是用于字段数据-每个节点大约9.5GB，过滤器缓存大约1.2GB，段文件的元数据大约1.7GB
  • 即使你有一个片段在你的模板，使stringS作为not_analyzed，在1.5但这并不意味着ES会使用doc_values，你需要明确启用它们。
  • 如果doc_values现在在1.5.x群集中启用，则更改将对新索引生效。对于旧索引，您需要重新索引数据。或者，如果您有基于时间的索引（每天，每周等创建），则只需要等待新索引的创建和旧索引的删除即可。
  • 直到doc_values将会在1.5群集中的索引中占主导地位，在注释中建议的@Val是唯一的选择：限制字段​​数据缓存大小或将更多节点添加到群集中（并暗含更多内存）或增加节点上的RAM 。或不时手动清除字段数据缓存 ;-)。
• 与内存问题不完全相关，但 请避免使用ttl 。如果您不再需要任何数据，只需删除索引，而不依赖ttl，这比简单地删除索引要昂贵得多。使用ttlcreate可能会在搜索时引起问题，并影响群集的整体性能，因为它会从索引中删除文档，这意味着需要进行大量更新并与这些索引进行大量合并。由于您可能具有基于时间的索引（这意味着昨天的数据并没有真正改变），因此使用ttl会对数据进行不必要的操作，这些操作原本应该是静态的（并且可以进行优化）。