DevOpsナレッジハブ
DevOpsナレッジハブ

ElasticsearchパフォーマンスのためのJVMチューニング：ヒープとガーベージコレクションのヒント

JVMチューニングを習得して、Elasticsearchデプロイメントの最高のパフォーマンスを引き出しましょう。このガイドでは、ヒープメモリ割り当て（RAMの50%ルールに従う）のための重要な設定、G1GCを用いたガーベージコレクションの最適化、そして必須のモニタリング手法について詳述します。実践的な構成を学び、レイテンシーの急増を排除し、大量の検索およびインデックス作成負荷に対して長期的なクラスターの安定性を確保しましょう。

45 ビュー

ElasticsearchのパフォーマンスのためのJVMチューニング：ヒープとガベージコレクションのヒント

ElasticsearchはJava上に構築されており、Java仮想マシン（JVM）内で動作します。特に負荷の高いインデックス作成や複雑なクエリの負荷がかかる状況で、Elasticsearchクラスターの最適なパフォーマンスと安定性は、正しいJVM構成に大きく依存します。メモリ設定の誤設定は、パフォーマンスの低下、予期せぬ停止、およびクエリ応答の遅延の主要な原因となります。このガイドでは、Elasticsearchの必須のJVMチューニングパラメータについて深く掘り下げ、ノードが効率的かつ確実に動作するように、ヒープサイズの設定とガベージコレクター（GC）の監視に焦点を当てます。

これらの基盤となるJava設定を理解することで、管理者はメモリプレッシャーをプロアクティブに管理し、コストのかかるフルガベージコレクションを防ぎ、分散検索および分析エンジンのスループットを最大化できます。

Elasticsearchのメモリ要件の理解

Elasticsearchは、主に2つの領域でメモリを必要とします。ヒープメモリとオフヒープメモリです。適切なチューニングには、ヒープを正しく設定し、オフヒープ要件のためにオペレーティングシステムに残りの物理メモリが十分に確保されていることを確認することが含まれます。

1. ヒープメモリの割り当て（ES_JAVA_OPTS）

ヒープは、Elasticsearchのオブジェクト、インデックス、シャード、およびキャッシュが存在する場所です。これは構成する上で最も重要な設定です。

ヒープサイズの設定

Elasticsearchは、初期ヒープサイズ（-Xms）を最大ヒープサイズ（-Xmx）と等しく設定することを強く推奨しています。これにより、JVMがヒープを動的にリサイズするのを防ぎ、顕著なパフォーマンスの一時停止を引き起こす可能性があります。

ベストプラクティス：50%ルール

Elasticsearchヒープに、物理RAMの50%以上を割り当ててはいけません。残りのメモリは、オペレーティングシステム（OS）のファイルシステムキャッシュにとって非常に重要です。OSはこのキャッシュを使用して、ディスクから頻繁にアクセスされるインデックスデータ（転置インデックス、格納フィールド）を保存しますが、これはディスクからの読み取りよりも格段に高速です。

推奨事項: マシンに64GBのRAMがある場合、-Xmsと-Xmxを31g以下に設定します。

構成の場所

これらの設定は、通常、Elasticsearch構成ディレクトリ（例：$ES_HOME/config/jvm.options）にあるjvm.optionsファイル、または設定を外部で管理する場合（ES_JAVA_OPTSの使用など）は環境変数を通じて構成されます。

構成例（jvm.options内）：

# 初期Javaヒープサイズ (例: 30 ギガバイト)
-Xms30g

# 最大Javaヒープサイズ (必ず -Xms と一致させる)
-Xmx30g

ヒープサイズに関する警告： ヒープサイズを31GB（または約32GB）以上に設定することは避けてください。これは、64ビットJVMが〜32GB未満のヒープに対して圧縮オブジェクトポインタ（Compressed Oops）を使用するためであり、これによりメモリ効率の高いオブジェクトレイアウトが実現します。このしきい値を超えると、この効率性のメリットがしばしば失われます。

2. オフヒープメモリ（ダイレクトメモリ）

ダイレクトメモリは、主にネットワークバッファとLuceneのメモリマッピングなどのネイティブ操作に使用されます。デフォルトでは、ダイレクトメモリの制限はヒープサイズに結びついており、通常、最大ヒープサイズの25%に制限されますが、これはJVMのバージョンによって異なる場合があります。

最新の、大容量のElasticsearchクラスターでは、特にインデックス作成のバースト時など、重いI/O操作を扱う際の安定性を確保するために、ダイレクトメモリの制限をヒープサイズと一致するように明示的に設定するのが一般的な慣行です。

ダイレクトメモリの構成例：

# ダイレクトメモリの制限をヒープサイズと等しく設定する
-XX:MaxDirectMemorySize=30g

ガベージコレクション（GC）のチューニング

ガベージコレクションは、参照されなくなったオブジェクトが使用していたメモリをJVMが再利用するプロセスです。Elasticsearchでは、管理が不十分なGCは、ノードのタイムアウトや不安定性につながる「ストップ・ザ・ワールド」の一時停止と呼ばれる顕著なレイテンシースパイクを引き起こす可能性があります。

適切なコレクターの選択

最新のElasticsearchバージョン（最近のJVMを使用）では、デフォルトでG1ガベージコレクター（G1GC）が使用されます。これは、Elasticsearchのデプロイメントで一般的な、大規模でマルチコアのシステムにとって通常最適な選択肢です。G1GCは、特定の停止時間目標を達成することを目指しています。

G1GCチューニングパラメータ

G1GCの最適化のための主要なパラメータは、最大一時停止時間目標の設定です。これは、コレクターにメモリをどれだけ積極的にクリーンアップすべきかを指示します。

G1GCの構成例：

# G1ガベージコレクターを選択
-XX:+UseG1GC

# 目的の最大一時停止時間目標を設定する（ミリ秒単位）。100msが一般的な開始点です。
-XX:MaxGCPauseMillis=100

GCアクティビティの監視

効果的なチューニングには、GCがいつ実行され、どれくらいの時間がかかるかを知る必要があります。Elasticsearchでは、GCイベントをファイルに直接ログ記録することができ、これはレイテンシーの問題をトラブルシューティングするために不可欠です。

GCロギングの有効化：

詳細なGCロギングを有効にするには、これらのフラグをjvm.optionsファイルに追加します。

# GCロギングを有効にする
-Xlog:gc*:file=logs/gc.log:time,level,tags

# オプション：ログローテーションサイズを指定する (例: 10MB後にローテーション)
-Xlog:gc*:file=logs/gc.log:utctime,level,tags:filecount=10,filesize=10m

GCEasyなどのツールや特定のスクリプトを使用して、結果のgc.logファイルを分析し、以下を特定します。

  1. 頻度: GCが実行される頻度。
  2. 期間: 一時停止の長さ（Total time for GC in...）。
  3. 昇格率: どのくらいのデータが、長期間存続してOld世代に移動しているか。

GCの一時停止がMaxGCPauseMillisの目標を継続的に超えている場合（例：頻繁に500ms以上になる場合）、メモリプレッシャーがあることを示しています。解決策には、ヒープサイズを増やすこと（RAMが許す場合、50%ルールを順守）またはオブジェクトチャーンを減らすためにインデックス作成/クエリパターンを最適化することが含まれます。

実践的なチューニングワークフローとベストプラクティス

ElasticsearchのJVM設定をチューニングするために、この系統的なアプローチに従ってください。

ステップ1：ノード容量の決定

Elasticsearchノードをホストしているマシンで利用可能な合計物理RAMを特定します。

ステップ2：ヒープサイズの計算

最大ヒープサイズを計算します: 最大ヒープ = 物理RAM × 0.5（最も近い安全な分数に切り捨て、通常は1～2GBの空きバッファを残します）。-Xmsと-Xmxをこの値に設定します。

ステップ3：ダイレクトメモリの設定

-XX:MaxDirectMemorySizeを、選択したヒープサイズ（-Xmx）と等しく設定します。

ステップ4：GCの構成

-XX:+UseG1GCが存在することを確認し、-XX:MaxGCPauseMillis=100のような合理的な目標を設定することを検討します。

ステップ5：ロギングの有効化と監視

GCロギングをアクティブ化し、クラスターを一般的な本番環境の負荷で数時間または数日間実行させます。ログを確認します。

ステップ6：ログに基づく反復

  • 一時停止が長すぎる場合: インデックス作成の負荷を減らす必要があるか、RAMが許せば、ヒープサイズをわずかに増やして50%ルールを再評価する必要があるかもしれません。
  • GCが非常に頻繁に実行されるが、一時停止が短い場合: ヒープがわずかに小さすぎるために過度のマイナーコレクションが発生しているか、短命のオブジェクトが多すぎる可能性があります。

シャードサイズ設定のヒント: JVMチューニングは、適切なインデックス作成戦略と組み合わせた場合に最も効果を発揮します。オーバーシャーディング（シャードが小さすぎること）は、JVMに多数のオブジェクトを多数の構造にわたって管理することを強制し、GCのオーバーヘッドを増加させます。ノードあたりのオーバーヘッドを減らすために、より大きなシャード（例：10GBから50GB）を目指してください。

結論

JVMヒープサイズとガベージコレクション戦略を適切にチューニングすることは、安定した高性能のElasticsearchクラスターを実現するための基本です。50% RAMルールを順守し、初期ヒープ設定と最大ヒープ設定を一致させ、G1GCコレクターを利用し、GCログを注意深く監視することで、オペレーターはレイテンシースパイクを軽減し、Elasticsearchが検索とインデックス作成の両方のタスクでシステムリソースを効率的に利用できるようにすることができます。