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仪表板时也会发生这种情况，这种情况的唯一解决方案是在所有节点上重新启动服务。

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

出了什么问题，我错过了什么？我想减少查询吗？

修改

我不得不提到我有很多空索引（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 result：

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群集，堆的主要用途是fielddata - 每个节点大约9.5GB，过滤器缓存大约1.2GB，段文件元数据大约1.7GB
- 即使您的模板中包含该代码段以将string设为not_analyzed，在1.5中这并不意味着ES会使用doc_values，您需要{{ 3}}。
- 如果您现在在1.5.x群集中启用doc_values，则更改将对新索引生效。对于旧索引，您需要重新索引数据。或者，如果您有基于时间的索引（每天创建，每周等），您只需要等待创建新索引并删除旧索引。
- 直到doc_values在1.5集群的索引中占主导地位，@ Val在评论中建议的是唯一的选项：specifically enable them或向集群添加更多节点（并且隐含更多内存））或增加节点上的RAM。或limit the fielddata cache size ;-)不时。
完全与内存问题无关，但尽量避免使用ttl 。如果您不再需要某些数据，只需删除索引，不要依赖ttl，这比简单地删除索引要昂贵得多。使用ttl创建可能会在搜索时引起问题并影响集群的整体性能，因为它会从索引中删除文档，这意味着需要对这些索引进行大量更新和大量合并。由于你可能有基于时间的索引（这意味着来自昨天的数据并没有真正改变），因此使用ttl会对数据带来不必要的操作，否则这些操作应该是静态的（可能是manually clear the fielddata cache）。

Answer 2

如果您的堆在查询时受到快速影响，则表示您在查询中执行了非常繁重的操作，例如聚合。像val和Andrei建议的那样，问题可能在于您的现场数据无限制。我建议检查您的映射，并在适用的地方使用doc_values和not_analyzed属性来降低查询费用。

Elasticsearch 1.5.2部署问题

2 个答案: