Elasticsearch Cluster 1.1.1環境でのOOM問題

Question

2つのノードを持つElasticsearch 1.1.1クラスタがあります。構成されたヒープはそれぞれ18Gです。 （各ノードのRAMは32Gです） 完全に6個のシャードと1個のシャードがあります。 ESはUbuntuボックスの64ビットJVM上で動作します。

私たちのクラスタには1つのインデックスしかありません。クラスタの状態は緑色に見えます。各ノードの文書数は200Millionに近いです。 各クラスタノードで使用されるデータは約150GBです。割り当てられていない破片はありません。

システムでOOMの問題（java.lang.OutOfMemoryError：Javaヒープスペース）が発生しています。 org.apache.lucene.search.TopFieldCollector $ OneComparatorNonScoringCollectorのインスタンスが45％前後heapspace （のほとんどを占めていることに注目されている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 

の

コンテンツ）

私はESを初めて利用しています。誰かがOOMの問題の状況をガイド（またはコメント）することができましたか、多くのヒープスペースが割り当てられているため、何が原因でしょうか？

Answer 1

鈍くなる：あなたは死んだ馬を鞭打っている。 1.xはもはや維持されておらず、その理由があります。 OOM：Elasticsearch replaced field dataの場合は、可能であれば文書の値で、さらに多くの回路ブレーカーが追加されています。

さらに問題が複雑になるのは、公式ドキュメントに1.1のドキュメントがもうないことです.0.91,1.3,1.4などです。少なくとも、1.7（最新の1.xリリース）。

あなたが試みることができるものをごOOMの問題に目を向ける：

• は（2.xの上で、最大）DOC値を使用し、より多くのノードを追加し、あなたが照会されているデータの量を減少させ、あなたのヒープサイズを大きくします。
• あなたのindices.fielddata.breaker.limitは私に怪しいようです。おかげXeraaを

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.