Elasticsearch ヒープサイズの使用量と JVM ガベージコレクション
Elasticsearch のヒープ サイズの使用と JVM ガベージ コレクションについて説明します。ベスト プラクティスや、ヒープ メモリの使用量が高すぎる場合や JVM のパフォーマンスが最適でない場合の問題を解決する方法も説明します。
ヒープ サイズは、Elasticsearch ノードの Java 仮想マシンに割り当てられる RAM の量です。
バージョン 7.11 以降、Elasticsearch はデフォルトで、ノードのロールと合計メモリに基づいて JVM ヒープ サイズを自動的に設定します。ほとんどの運用環境では、デフォルトのサイズ設定を使用することをお勧めします。ただし、JVM ヒープ サイズを手動で設定する場合は、一般的なルールとして、-Xms と -Xmx を同じ値に設定する必要があります。これは、使用可能な RAM の合計の 50% で、最大 (約) 31 GB になります。
ヒープ サイズを大きくすると、インデックス作成と検索操作に使用できるメモリがノードに多く割り当てられます。ただし、ノードにはキャッシュ用のメモリも必要なので、50% を使用すると 2 つのメモリのバランスが適切に保たれます。同じ理由から、本番環境では、Elasticsearch と同じノードで他のメモリを大量に消費するプロセスを使用することは避けてください。
通常、ヒープ使用量は鋸歯状のパターンに従い、使用されている最大ヒープの約 30 ～ 70% の間を変動します。これは、ガベージ コレクション プロセスによってメモリが再び解放されるまで、JVM がヒープ使用率を着実に増加させるためです。ガベージ コレクション プロセスが追いつかない場合、ヒープ使用率が高くなります。ヒープ使用量が高いことを示す指標は、ガベージ コレクションでヒープ使用量を約 30% まで削減できない場合です。
上の画像では、JVM ヒープの通常のノコギリ波を見ることができます。
また、ガベージ コレクションには、若い GC と古い GC の 2 種類があることもわかります。
正常な JVM では、ガベージ コレクションは理想的には次の条件を満たす必要があります。
Young GC は迅速に処理されます (50 ミリ秒以内)。
Young GC は頻繁に実行されません (約 10 秒)。
古い GC はすぐに処理されます (1 秒以内)。
古い GC は頻繁に実行されません (10 分に 1 回以上)。
ヒープメモリ使用量が高すぎる場合やJVMパフォーマンスが最適でない場合の解決方法
ヒープ メモリの使用量が増える理由はさまざまです。
オーバーシャーディング
オーバーシャーディングに関するドキュメントはここを参照してください。
大規模な集約サイズ
集約サイズが大きくなるのを避けるには、クエリ内の集約バケットの数 (サイズ) を最小限に抑えます。
GET /_search
{
"aggs" : {
"products" : {
"terms" : {
"field" : "product",
"size" : 5
}
}
}
}低速クエリ ログ (スロー ログ) を使用し、次のように特定のインデックスに実装することができます。
PUT /my_index/_settings
{
"index.search.slowlog.threshold.query.warn": "10s",
"index.search.slowlog.threshold.query.info": "5s",
"index.search.slowlog.threshold.query.debug": "2s",
"index.search.slowlog.threshold.query.trace": "500ms",
"index.search.slowlog.threshold.fetch.warn": "1s",
"index.search.slowlog.threshold.fetch.info": "800ms",
"index.search.slowlog.threshold.fetch.debug": "500ms",
"index.search.slowlog.threshold.fetch.trace": "200ms",
"index.search.slowlog.level": "info"
}結果を返すのに長い時間がかかるクエリは、リソースを大量に消費するクエリである可能性が高くなります。
バルクインデックスのサイズが大きすぎる
大きなリクエストを送信する場合、ヒープ消費量が多くなる原因となる可能性があります。一括インデックス要求のサイズを小さくしてみてください。
マッピングの問題
特に、「fielddata: true」を使用する場合、これが JVM ヒープの主要なユーザーになる可能性があります。
ヒープサイズが正しく設定されていません
ヒープ サイズは次のように手動で定義できます。
環境変数の設定:
ES_JAVA_OPTS="-Xms2g -Xmx2g"Elasticsearch 構成ディレクトリ内の jvm.options ファイルを編集します。
-Xms2g
-Xmx2g環境変数の設定はファイルの設定よりも優先されます。
設定を有効にするにはノードを再起動する必要があります。
JVM の新しい比率が正しく設定されていません
Elasticsearch はデフォルトでこの値を設定するため、通常はこれを設定する必要はありません。このパラメータは、JVM 内の「新世代」オブジェクトと「旧世代」オブジェクトに使用可能なスペースの比率を定義します。
古い GC が非常に頻繁に発生していることがわかった場合は、Elasticsearch 構成ディレクトリの jvm.options ファイルでこの値を具体的に設定してみてください。
-XX:NewRatio=3大規模な Elasticsearch クラスターでヒープサイズの使用量と JVM ガベージコレクションを管理するためのベストプラクティスは何ですか?
大規模な Elasticsearch クラスターでヒープ サイズの使用量と JVM ガベージ コレクションを管理するためのベスト プラクティスは、ヒープ サイズが使用可能な RAM の最大 50% に設定され、JVM ガベージ コレクション設定が特定のユース ケースに合わせて最適化されていることを確認することです。クラスターが最適に実行されていることを確認するには、ヒープ サイズとガベージ コレクション メトリックを監視することが重要です。具体的には、JVM ヒープ サイズ、ガベージ コレクション時間、ガベージ コレクションの一時停止を監視することが重要です。さらに、ガベージ コレクション サイクルの数とガベージ コレクションに費やされた時間を監視することも重要です。これらのメトリックを監視することで、ヒープ サイズやガベージ コレクションの設定に関する潜在的な問題を特定し、必要に応じて修正措置を講じることができます。
