JVM GC監視サービスのオーバーヘッド: 根本原因と推奨事項

問題の説明

The JvmGcMonitorService オーバーヘッド警告は、Java 仮想マシン (JVM) がオールド・ジェネレーションのガベージ・コレクション (GC) を実行していることを示しています。このプロセス中、JVM は他のすべての活動を一時停止してメモリを回収するため、以下のような潜在的な中断を引き起こすことがあります。

• レスポンスがないElasticsearch ノードのクライアントやクラスターリクエストへの。
• ノードの切断、これによりクラスターの不安定性を引き起こす可能性があります。

1. 過剰なヒープ使用: 多数の複雑なクエリまたは設定された JVM ヒープサイズに対して過剰に割り当てられたシャード。
2. 不適切なリソース構成: 不適切な JVM 設定またはシャードの分布。

初期の発見と観察

1. ヒープ使用量の傾向:

• Kibana の Stack Monitoring や _nodes/stats API のメトリクスを使用して、時間経過による JVM ヒープ使用量を確認します。
• ヒープの飽和期間や長時間の GC 停止を特定します。

1. 使用するコマンド:
2. GET /_nodes/stats/jvm
3. シャードの割り当てとサイズ:

• ノードごとのシャード数とそのサイズを _cat/shards で確認します。過剰なシャード数はメモリ消費を増加させます。

1. 使用するコマンド:
2. GET /_cat/shards?v
3. クエリの複雑性:

• スロークエリログを分析したり、頻繁に実行されるクエリを監視します。複雑な集約やワイルドカード検索はしばしば JVM メモリに負荷をかけます。

1. スローログを有効にするコマンド:
2. # elasticsearch.yml に追加
3. index.search.slowlog.threshold.query.warn: 10s
4. index.search.slowlog.threshold.fetch.warn: 5s
5. 異常なパターン:

• GC オーバーヘッドの発生中にインデックス作成、検索速度、または他の異常な活動のスパイクがないか確認します。

推奨事項

JVM ヒープ設定の最適化:

• ヒープサイズは適切に設定されていることを確認します（利用可能なメモリの 50%、圧縮オブジェクトポインタが無効にならないよう30GBに制限）。
• 大規模なヒープや高スループットのシナリオでより良いパフォーマンスを提供する G1GC を有効にします。

シャード数を減らす:

• 小さなインデックスを結合するか、 Rollover API を使用してインデックスの成長を管理します。
• ヒープメモリの 1GB あたり 20 シャードを目安にします。

クエリのチューニング:

• 高価なクエリを再作成して効率を改善します（例：ワイルドカードで *や ? を避ける）。
• 頻繁に使用されるクエリは検索クエリキャッシュを使用してキャッシュします。

監視とアラートの実装:

• Elastic の監視ツールを使用して、高ヒープ使用量や遅い GC 時間のアラートを作成します。

クラスターの拡張:

• 作業負荷が常に容量を超えている場合、負荷を分散するためにクラスターにノードを追加することを検討します。

結論