Question

我有一个带有两个节点的Elasticsearch 1.1.1集群。配置堆每个18G。（每个节点上的RAM为32G）每个碎片我们总共有6个碎片和一个复制品。 ES在Ubuntu盒子上的64位JVM上运行。

我们的群集中只有一个索引。群集健康看起来很绿。每个节点上的文档数接近200万。每个群集节点上使用的数据大约为150GB。没有未分配的分片。

系统遇到OOM问题（java.lang.OutOfMemoryError：Java堆空间）。

elasticsearch.yml的内容

bootstrap.mlockall: true

transport.tcp.compress: true

indices.fielddata.cache.size: 35%
indices.cache.filter.size: 30%
indices.cache.filter.terms.size: 1024mb
indices.memory.index_buffer_size: 25%
indices.fielddata.breaker.limit: 20%

threadpool:
    search:
        type: cached
        size: 100
        queue_size: 1000

已经注意到 org.apache.lucene.search.TopFieldCollector $ OneComparatorNonScoringCollector 的实例占用了大部分堆空间（约45％）

我是ES的新手。有人可以指导（或评论）有关OOM问题的情况吗，因为我们分配了大量的堆空间，可能是什么原因？

Answer 1

直言不讳：你正在鞭打一匹死马。 1.x不再维护，并且有充分的理由。对于OOM：Elasticsearch replaced field data尽可能使用doc值并添加更多断路器。

问题的进一步复杂化是官方文档上没有1.1的文档 - 只有0.90,1.3,1.4，......所以至少你应该升级到1.7（最新的1.x版本））。

转到您的OOM问题，您可以尝试：

增加堆大小，减少查询数据量，添加更多节点，使用doc值（在2.x及以上）。
你的indices.fielddata.breaker.limit对我来说很可疑。我认为此配置参数已在1.4和Elasticsearch Guide状态中重命名为indices.breaker.fielddata.limit：

在Fielddata Size中，我们谈到了增加大小的限制 fielddata，以确保可以驱逐旧的未使用的fielddata。该 indices.fielddata.cache.size和。之间的关系 indices.breaker.fielddata.limit是一个重要的。如果断路器限制低于高速缓存大小，不会有任何数据被驱逐。为了使其正常工作，断路器 limit必须高于缓存大小。

Elasticsearch Cluster 1.1.1环境中的OOM问题

1 个答案: