16 ノード (13 データ ノード/3 マスター/24 GB RAM/12 GB ヒープ) の Elastic Search 5.2 クラスターがあります。クエリのパフォーマンス テストを行っており、Elastic クラスターで 1 秒あたり 50 回の検索クエリの呼び出しを行っています。私のクエリは次のようになります -
{
"query": {
"bool": {
"must": [
{
"term": {
"cust_id": "AC-90-464690064500"
}
},
{
"range": {
"yy_mo_no": {
"gt": 201701,
"lte": 201710
}
}
}
]
}
}
}
私のインデックスマッピングは次のようなものです -
cust_id Keyword
smry_amt Long
yy_mo_no Integer // doc_values enabled
mkt_id Keyword
. . .
. . .
currency_cd Keyword // Total 10 field with 8 Keyword type
インデックスには 2 億件のレコードが含まれており、各 cust_id には数百件のレコードが存在する場合があります。インデックスには 2 つのレプリカがあります。レコード サイズが 100 バイト未満です。
パフォーマンス テストを 10 分間実行すると、クエリの応答とパフォーマンスが非常に遅くなるようです。Kibana 監視タブでもう少し詳細に調査すると、多くのガベージ コレクション アクティビティが発生しているようです (下の画像を参照してください)。
頭の中にいくつかの疑問点があります。範囲クエリについていくつか調査しましたが、私のようなシナリオで GC アクティビティを引き起こす原因についてはあまり見つかりませんでした。私はメモリ使用量と GC アクティビティについても調査していますが、Elastic ドキュメントのほとんどは、インデックス作成中は若い世代の GC が正常であり、検索アクティビティは主に OS が維持するファイル システム キャッシュを使用すると述べています。そのため、上のグラフでは、検索がファイル システム キャッシュを使用していたため、ヒープはあまり使用されていません。
そう -
- ここでガベージ コレクションが発生する原因は何ですか?
- グラフは、ヒープがまだ Elastic Search で使用可能であり、使用済みヒープが使用可能に比べてまだ非常に少ないことを示しています。では、何が GC をトリガーしているのでしょうか?
- クエリの種類によって、破棄される内部データ構造が作成され、GC が発生していますか?
- CPU スパイクは、GCアクティビティが原因である可能性があります。
- Elastic Search 5.5 より前のバージョンで範囲クエリを実行する効率的な方法は他にありますか?
- クエリをプロファイリングすると、Elastic がTermQueryを実行しており、後者のBooleanQueryが最もコストがかかることがわかります。
ここで何が起こっているのですか？
前もって感謝します、
- SGSI。