gpt4 book ai didi

elasticsearch - Elasticsearch Cluster 1.1.1环境中的OOM问题

转载 作者:行者123 更新时间:2023-12-03 01:47:25 25 4
gpt4 key购买 nike

我有一个带有两个节点的Elasticsearch 1.1.1集群。每个配置的堆18G。 (每个节点上的RAM为32G)
总共我们有6个碎片,每个碎片有一个副本。 ES在Ubuntu机器上的64位JVM上运行。

我们的集群中只有一个索引。群集运行状况看起来绿色。每个节点上的文档数接近2亿。
每个群集节点上使用的数据约为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问题的情况进行指导(或评论)吗,由于我们分配了很多堆空间,这可能是什么原因?

最佳答案

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

使问题进一步复杂化的是,官方文档上没有更多关于1.1的文档-只有0.90、1.3、1.4等。因此,至少您应该升级到1.7(最新的1.x版本)。

谈到您的OOM问题,您可以尝试以下操作:

  • 增加堆大小,减少查询的数据量,添加更多节点,使用doc值(在2.x及更高版本上)。
  • 对我来说,您的indices.fielddata.breaker.limit看起来像鱼。我认为此配置参数已在1.4中重命名为indices.breaker.fielddata.limit,并且Elasticsearch Guide状态为:

  • In Fielddata Size, we spoke about adding a limit to the size of fielddata, to ensure that old unused fielddata can be evicted. The relationship between indices.fielddata.cache.size and indices.breaker.fielddata.limit is an important one. If the circuit-breaker limit is lower than the cache size, no data will ever be evicted. In order for it to work properly, the circuit breaker limit must be higher than the cache size.

    关于elasticsearch - Elasticsearch Cluster 1.1.1环境中的OOM问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/42827120/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com