Amazon OpenSearch Service クラスターで高い JVM メモリ負荷をトラブルシューティングするにはどうすればよいですか?

最終更新日: 2021 年 7 月 23 日

Amazon OpenSearch Service (Amazon Elasticsearch Service の後継サービス) クラスターで、JVM のメモリ負荷が高くなっています。JVM メモリ負荷のレベルはいろいろありますが、それらは何を意味するのでしょうか? また、それらを減らすにはどうすればよいですか?

解決方法

JVM メモリ負荷は、クラスターノード内の Java ヒープの割合を指定します。次のガイドラインは、JVM メモリ負荷の割合が何を意味するかを示しています。

  • JVM メモリ負荷が 75% に達すると、Amazon OpenSearch Service が Concurrent Mark Sweep (CMS) ガベージコレクターをトリガーします。ガベージコレクションは、CPU 負荷が高くなるプロセスです。この割合で JVM メモリ負荷が数分間続くと、ClusterBlockException、JVM OutOfMemoryError、またはその他のクラスターのパフォーマンスに関して問題が発生する可能性があります。
  • JVM メモリ負荷が 30 分間に 92% を超えた場合、OpenSearch Service はすべての書き込みオペレーションをブロックします。
  • JVM メモリ負荷が 100% に達した場合、OpenSearch Service JVM は終了するように設定されており、最終的に OutOfMemory (OOM) で再開されます。

JVM メモリ負荷は、次の理由で発生する可能性があります。

  • クラスターへのリクエスト数のスパイク。
  • 集計、ワイルドカード、クエリでの幅広い時間範囲の選択。
  • ノード間でのシャード割り当ての不均衡、またはクラスター内のシャードが多すぎる。
  • フィールドデータ、またはインデックスマッピングの急激な展開。
  • 着信した負荷を処理できないインスタンスタイプ。

クラスターへのトラフィックを減らすことで、JVM メモリ負荷が高くなる問題を解決できます。クラスターへのトラフィックを減らすには、以下のベストプラクティスに従ってください。

  • POST /index_name/_cache/clear?fielddata=true API オペレーションで、フィールドデータのキャッシュをクリアします。
    注: キャッシュをクリアすると、進行中のクエリが中断される場合があります。
  • テキストフィールドでの集計を回避するか、マッピングタイプをキーワードに変更します。
  • ドメインを (ノードあたりの最大ヒープサイズが 32 GB となるよう) スケーリングします。
  • スローログを有効にして、問題のあるリクエストを特定します。
    注: JVM メモリ負荷が 90% 未満であることを確認します。低速な Elasticsearch クエリの詳細については、Elasticsearch ウェブサイトの Advanced tuning: finding and fixing slow Elasticsearch queries を参照してください。
  • 適切な数のシャードを選択して、検索またはインデックス作成を最適化します。インデックス作成とシャードカウントの詳細については、Get started with Amazon OpenSearch Service: How many shards do I need? を参照してください。
  • 古いまたは未使用のインデックスを削除して、シャードの数を減らします。
  • 上級ユーザーの場合、ユースケースに応じて、親、フィールドデータを更新したり、サーキットブレーカー設定をリクエストしたりできます。JVM サーキットブレーカーの詳細については、JVM OutOfMemoryError を参照してください。

高い JVM メモリ負荷をトラブルシューティングする方法の詳細については、Amazon OpenSearch Service ノードがクラッシュしたのはなぜですか? を参照してください。