16ノード(13データノード/ 3マスタ/ 24 GB RAM/12 GBヒープ)のElastic Search 5.2クラスタがあります。私は、クエリのパフォーマンスをテストして、Elasticクラスタ上で毎秒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
指数を200万件のレコードが含まれており、それぞれのcust_idのために、レコードの数百があるかもしれません。インデックスには2つのレプリカがあります。レコードサイズは100バイト未満です。
パフォーマンステストを10分間実行すると、クエリの応答とパフォーマンスが非常に遅くなるようです。 Kibana監視]タブで詳細にもう少し調査をしたら、起こってガベージコレクションの活動がたくさんあることが表示されます(plsは下の画像を参照してください。) -
私は私の心の中でいくつかの質問の曇りを持っています。私はレンジクエリーについていくつかの調査をしましたが、私のようなシナリオではGC活動を引き起こす可能性のあるものはあまり見つかりませんでした。私はまた、メモリの使用状況とGCの活動についても研究していますが、Elasticのドキュメントのほとんどは、若い世代のGCは通常のインデックス作成中であり、検索活動は主にOSが維持するファイルシステムキャッシュを使用します。それで、上記のチャートでは、検索でファイルシステムキャッシュが使用されて以来、Heapはあまり使われていません。
そう - ここで発生するガベージコレクションを引き起こしている可能性がありますどのような
- ?
- グラフには、ヒープがまだElastic Searchで使用可能であることが示されています。使用されているヒープは、利用可能なものと比べるとまだ非常に少ないです。それではGCをトリガーするのは何ですか?
- クエリタイプによって、内部データ構造が作成され、処理が中断され、GCが発生しますか?
- CPUのスパイクは、GCというアクティビティによるものかもしれません。
- Elastic Search pre 5.5バージョンでRangeクエリを実行する他の効率的な方法はありますか?
- クエリをプロファイリングすると、TermQueryとBooleanQueryが実行され、後で最もコストがかかります。
ここで何が起こっているのですか?事前に
おかげで、
- SGSI。
あなたのグラフによると、1分間に4つのコレクションがあり、合計の持続時間は約100ミリ秒で、GCに関連する問題はないと思います。 IO統計(ディスクの読み書き)を提供してください。 – Ivan