Elasticsearchの実行プロセスでは、メモリを適切に割り当てて設定する方法が非常に重要です。そうしないと、さまざまな問題が発生しやすくなります。
1. Elasticsearchがメモリを消費するのはなぜですか？
まず、ESサーバーの全体的なメモリ消費量を見てみましょう。
クエリキャッシュ、リクエストキャッシュ、フィールドデータキャッシュ、インデックスバッファ、セグメントの導入は前の記事で紹介されており、ここでは繰り返さないことにします。
Elasticsearchがなぜこれほど多くのメモリを消費するのかという質問に答えるには、次の2つの角度から切り込む必要があります。
（1）ESはJAVAアプリケーションであるため、JVMおよびGCと密接に関連しています。ここでは、JVM GCについて詳しく説明しません。アプリケーション層が、ヒープに圧力がかかる主な理由である、ライフサイクルの長い多数のオブジェクトを生成することを知っているだけです。たとえば、大量のデータがメモリで読み取られて並べ替えられた場合、または大量のデータがヒープにキャッシュされた場合、GCによって解放されるスペースが限られていて、アプリケーション層が引き続き多数の新しいデータを適用する場合オブジェクトの場合、GCの頻度が増加し始め、CPU時間を大量に消費するだけでなく、深刻な悪循環が発生し、クラスター全体がシャットダウンする可能性があります。
（2）ESの基盤となるストレージエンジンはLuceneに基づいており、Luceneの転置インデックスは最初にメモリで生成され、次にセグメントファイルの形式で定期的にディスクにフラッシュされます。各セグメントは実際には完全な転置インデックスであり、ディスクに書き込まれると変更されません。APIレベルでのドキュメントの更新と削除は、実際には段階的に書き込まれる特別な種類のドキュメントであり、新しいセグメントに保存されるため、変更されていないセグメントファイルはオペレーティングシステムによって非常に簡単にキャッシュされ、ホットデータはメモリアクセスとほぼ同等です。
次に、Elasticsearchのメモリ割り当て：
ESに割り当てられたヒープメモリを物理マシンメモリの半分以上にできないのはなぜですか？
1.Luceneが使用するためにメモリの半分を予約します。
Lucene用にメモリの半分を予約する必要があるのはなぜですか。すべてのメモリをElasticsearchに割り当てる方がよいのではないでしょうか。言うまでもなく、ヒープメモリはESにとって絶対的に重要ですが、もう1つの非常に重要なメモリコンシューマーであるLuceneがあります。
Luceneについて話す前に、セグメントを簡単に紹介しましょう。各セグメントは、セグメントファイルという1つのファイルに保存されます。これは実際には、前方行（スペースの90〜95％）+後方行（5〜10％）を含む完全なインデックスファイルであり、ディスクに書き込まれると変更されません。ESでのドキュメントの更新と削除は実際には古いセグメントを変更せずに新しいセグメントに保存される特別な種類の増分書き込み。
Luceneに戻ると、Luceneの実際の目的は、基盤となるOSのデータをメモリにキャッシュすることです。Luceneのセグメントセグメントは変更されないため、キャッシュすることは非常に有益であり、オペレーティングシステムはこれらのセグメントファイルをキャッシュしてアクセスを高速化します。これらのセグメントには、転置インデックス（全文検索用）とドキュメント値（集計用）が含まれます。
Luceneのパフォーマンスは、このOSとの相互作用に依存します。すべてのメモリがESのヒープメモリに割り当てられ、Luceneに少なからず残されている場合、フルテキスト検索のパフォーマンスは非常に低くなります。したがって、公式の推奨事項は、使用可能なメモリの50％をESヒープに提供することです。残りのメモリの残りの50％はアイドル状態になりません。これは、Luceneがそれらを使用して読み取られたセグメントファイルをキャッシュするためです。
ESのファイルストレージタイプは、デフォルトでmmapメモリマッピングを使用します。これにより、Luceneインデックスファイルがメモリにマップされるため、プロセスはメモリからLuceneデータを直接読み取ることができます。メモリマッピングを使用しているため、ESプロセスがLuceneファイルを読み取るときに読み取られるデータは、オフヒープメモリのスペースを占有します。
2. ESに割り当てられるヒープメモリは、32Gを超えてはなりません。
ヒープメモリが32GBを超えないのはなぜですか？実際、メモリが32G未満の場合、JVMはメモリオブジェクトポインタ圧縮テクノロジを使用します。
Javaでは、すべてのオブジェクトがヒープに割り当てられ、それへのポインタがあります。これらのオブジェクトへのポインターのサイズは、通常、CPUのワードサイズであり、プロセッサーに応じて32ビットまたは64ビットのいずれかであり、ポインターは値の正確な位置を指します。32ビットシステムの場合、最大4GBのメモリを使用できます。64システムでより多くのメモリを使用できます。ただし、64ビットポインターは、ポインター自体が大きいため、無駄が多くなります。また、無駄なスペースよりも悪いことに、メインメモリとキャッシュ（LLC、L1など）の間でデータを移動するときに、ポインタが大きいほど多くの帯域幅を使用します。
Javaは、この問題を解決するためにメモリポインタ圧縮と呼ばれる手法を使用します。そのポインタは、メモリ内のオブジェクトの正確な位置を表すのではなく、オフセットを表します。これは、32ビットポインタが40億バイトではなく、40億オブジェクトを参照できることを意味します。つまり、ヒープメモリは32 Gの物理メモリに増大します。これは、32ビットポインタで表すこともできます。
その魔法の30〜32 Gの境界を越えると、ポインタは通常のオブジェクトのポインタに戻り、各オブジェクトのポインタは長くなり、より多くのCPUメモリ帯域幅を使用します。つまり、より多くのメモリを効果的に失うことになります。実際、メモリが40〜50 GBに達すると、メモリオブジェクトポインタ圧縮テクノロジを使用した場合の実効メモリは32GBのメモリに相当します。
したがって、十分なメモリがある場合でも、32 Gを超えないようにしてください。これは、メモリを浪費し、CPUパフォーマンスを低下させ、GCが大容量メモリに対応できるようにするためです。
3.ElasticSearchのヒープメモリが設定されます。
ヒープに割り当てられるメモリは、Luceneシステムファイルキャッシュ用に十分な物理メモリが予約されるように、システムで使用可能な物理メモリの半分を超えてはならず、32GBを超えてはなりません。JVM引数はどうですか？最小ヒープサイズ（Xms）と最大ヒープサイズ（Xmx）をヒープと同じサイズに設定するだけで、ヒープサイズを動的に割り当てることは避けてください。XmsとXmxのサイズを同じにするために、Javaガベージコレクションメカニズムがヒープ領域をクリーンアップした後、ヒープ領域のサイズを再分割せずにリソースを浪費し、拡張によって生じる圧力を減らすことが目的です。ヒープサイズの縮小。
ESのメモリ設定制限は32GBですが、マシンに大量のメモリがある場合はどうなりますか？たとえば、現在のマシンのメモリは一般的に大きく、300〜500GBのメモリを搭載したマシンが設定されています。もちろん、そのようなマシンがあれば素晴らしいと思います。2つのオプションがあります。
（1）主にフルテキスト検索を行う場合は、Elasticsearch 32 Gメモリを割り当て、残りをオペレーティングシステムのファイルシステムキャッシュとしてLuceneに渡すことを検討できます。すべてのセグメントがキャッシュされるため、フルテキストが高速化されます。検索。
（2）より多くのソートと集約が必要な場合は、より大きなヒープメモリが必要になります。32 GB以上のメモリを搭載した1つのノードを展開するのではなく、1台のマシンに2つ以上のESノードを作成することを検討してください。引き続き50％のルールを守り、128 GBのメモリを搭載したマシンがあると仮定すると、32GBのメモリを搭載した2つのノードを作成できます。つまり、64 GのメモリがESのヒープメモリに割り当てられ、残りの64GがLuceneに割り当てられます。
PS：2番目のオプションを選択する場合は、cluster.routing.allocation.same_shard.host：trueを構成して、同じシャードのマスターコピーが同じ物理マシンに存在しないようにする必要があります。コピーの高可用性は失われます。
推奨記事：ESメモリの問題分析：