elasticsearch jvmヒープ使用の理解

Question

フォーク、

私はelasticsearch展開（シングルノードクラスタ）で自分のメモリ使用量を減らそうとしています。

3GBのJVMヒープスペースが使用されています。 最適化するには、まずボトルネックを理解する必要があります。 JVMの使用方法が分かりません。

フィールドデータが1.5GBを消費し、フィルタキャッシュ&クエリキャッシュの合計消費量が0.5GB未満で、最大で2GBが追加されます。

elasticsearchが1GBの残りの部分をどこまで食べるのか理解できるように助けてくれる人はいますか？

Answer 1

あなたの正確な設定はわかりませんが、ヒープで何が起こっているのかを知るには、jvisualvmツール（jdkにバンドルされています）を驚きやbigdesk plugin（自分の好み） _cat APIs何が起こっているのかを分析する。あなたは間違いなく気づいてきたよう

、ヒープホスト三つの主要なキャッシュ、すなわち：

• fielddata cache：（あなたのケースで、50％程度であるように思わデフォルトで無制限、しかしindices.fielddata.cache.sizeで制御することができますヒープの、おそらくfielddata circuit breaker）
• node query/filter cacheへ：ヒープの10％
• shard request cache：デフォルトでは無効ヒープの1％が、

キャッシュの役割をまとめたnice mindmapがあります。here（IgorKupczyńskiへの名誉）これにより、ESが正しく機能するために作成する必要がある他のすべてのオブジェクトインスタンスに対して、ヒープの約30％（ケースでは1GB）が残ります（詳細は後で説明します）。

ここで私のローカルenvをどのように進めていますか。まず、自分のノードを新しく（Xmx1gで）開始し、緑の状態を待っていました。それから私はjvisualvmを起動し、それを私のelasticsearchプロセスに引っ掛けました。私はサンプラータブからヒープダンプを取ったので、後で別のダンプと比較することができます。

：私も私のフィールドデータとフィルタキャッシュが空であったことが確認され

：私のヒープは、この最初に（1/3だけ、これまでに割り当てられた最大ヒープの）ように見えます念のため、私はまた、/_cat/fielddataを実行して、フィールドのデータではまだ始まったばかりのノードから使用何らヒープはありません見ることができるように。

$ curl 'localhost:9200/_cat/fielddata?bytes=b&v' 
id      host  ip   node total 
TMVa3S2oTUWOElsBrgFhuw iMac.local 192.168.1.100 Tumbler  0 

これは初期の状況です。これですべてを少し温かくする必要があるので、私はバックエンドとフロントエンドのアプリを起動して、ローカルESノードにある程度のプレッシャーをかけるようにしました。その大きさは、多かれ少なかれ300メガバイト増加しているので、しばらくして、私のヒープは、次のようになります

（139メガバイト - > 452メガバイト、あまり私は小さなデータセットでこの実験を実行した）

私のキャッシュはまた、数メガバイトに少し成長しています。この時点で

$ curl 'localhost:9200/_cat/fielddata?bytes=b&v' 
id      host  ip   node  total 
TMVa3S2oTUWOElsBrgFhuw iMac.local 192.168.1.100 Tumbler 9066424 

は私が撮ったanothヒープが進化したのかについての洞察を得るためにヒープダンプをえー、私は、オブジェクトのretained sizeを計算し、私はちょうどノードを起動した後に取った最初のダンプとそれを比較しました。比較は次のようになります。保持サイズを大きくするオブジェクトの中で

、彼の通常の容疑者はもちろんのマップ、および任意のキャッシュ関連のエンティティです。 char配列またはバイト配列の形式で、ファイルシステム上のLuceneのセグメントファイルを読み取るために使用されている

• NIOFSDirectory
• インターン文字列の多く
• 関連ドキュメント値：しかし、我々はまた、次のクラスを見つけることができますクラス
• ビットセット
• など

あなたが見ることができるように

は、ヒープは、3つの主要なキャッシュをホストしているが、それはまた、他のすべてのJavaオブジェクトに存在する場所であることを必ずしもキャッシュ関連していないElasticsearchプロセスのニーズと。あなたは、ヒープの使用量を制御する場合

だから、あなたは明らかにESが正しく機能するために必要な内部オブジェクトを制御することはできませんが、あなたは間違いなくあなたのキャッシュのサイズに影響を与えることができます。最初の箇条書きのリストにあるリンクをたどると、どのような設定を調整できるかが正確に分かります。

チューニングキャッシュは唯一のオプションではないかもしれません。多分メモリにやさしくなるようにクエリの一部を書き直すか、アナライザやマッピングなどのフィールドタイプを変更する必要があります。これ以上の情報はありませんが、これはあなたにいくつかのリードを与えるはずです。

私がここでやったのと同じ方法でjvisualvmを起動し、アプリ（検索+索引付け）がESに当たる間にヒープがどのように成長しているかを学び、そこで何が起こっているのかをすぐに知るべきです。

Answer 2

マーベルは、この場合のキャッシュのように監視する必要があるヒープ上のいくつかの事例をプロットします。

キャッシュは、合計ヒープ使用量の一部のみを表します。ヒープメモリを占有する多くの他のインスタンスがあり、これらのインスタンスはこの驚異的なインターフェイスに直接プロットすることはできません。

したがって、ESで占有されるヒープはすべてキャッシュによってのみ使用されるわけではありません。

異なるインスタンスによるヒープの正確な使用状況を明確に理解するには、プロセスのヒープダンプを取得し、正確な画像を提供できるMemory Analyzerツールを使用して解析する必要があります。