elasticsearch - 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来查询某事(非常简单的查询)时，如果它是单个查询，就可以正常工作，但是如果我继续查询更多的东西- flex 变得非常缓慢，最终由于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 kibana + 23数据

总共有2,564个分片=(1135空+ 31奇迹+ 1 kibana + 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

即使您的模板中包含该代码段，也可以将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 或向群集中添加更多节点(并隐式增加内存)或增加节点上的RAM。或 manually clear the fielddata cache ;-)不时出现。

与内存问题不完全相关，但是尝试避免使用ttl 。如果您不再需要任何数据，只需删除索引，而不依赖ttl，这比简单地删除索引要昂贵得多。使用ttl创建时可能会在搜索时引起问题，并影响集群的整体性能，因为它会从索引中删除文档，这意味着需要进行大量更新并与这些索引进行大量合并。由于您可能具有基于时间的索引(这意味着昨天的数据实际上并没有发生变化)，因此使用ttl会对不必要的静态数据(可能是optimized)带来不必要的操作。