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

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

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 メモリ負荷をトラブルシューティングする方法の詳細については、Why did my Amazon OpenSearch Service node crash? を参照してください。