Elasticsearch集羣中的OOM問題1.1.1環境

我有一個包含兩個節點的Elasticsearch 1.1.1集羣。每個配置18G的堆。（每個節點上的RAM是32G）完全我們有6個碎片和每個碎片一個副本。 ES在Ubuntu上的64位JVM上運行。Elasticsearch集羣中的OOM問題1.1.1環境

我們的羣集中只有一個索引。集羣健康看起來很綠。每個節點的文檔數量接近200萬。每個羣集節點上使用的數據大約爲150GB。沒有未分配的碎片。

系統遇到OOM問題（java.lang.OutOfMemoryError：Java heap space）。

內容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佔據大部分heapspace （約45％）

我是ES新手。有人可以指導（或評論）OOM問題的情況，因爲我們有很多heapspace分配，可能是什麼原因？

來源

2017-03-16 krckumar

生硬：你正在鞭a一匹死馬。 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 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.

來源

2017-03-17 00:27:44 xeraa

感謝Xeraa。你的投入給了好的方向:) – krckumar

Elasticsearch集羣中的OOM問題1.1.1環境

回答

相關問題