範囲検索クエリにより、エラスティック検索でガベージコレクションが発生しています

Question

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はあまり使われていません。

そう - ここで発生するガベージコレクションを引き起こしている可能性がありますどのような

1. ？
2. グラフには、ヒープがまだElastic Searchで使用可能であることが示されています。使用されているヒープは、利用可能なものと比べるとまだ非常に少ないです。それではGCをトリガーするのは何ですか？
3. クエリタイプによって、内部データ構造が作成され、処理が中断され、GCが発生しますか？
4. CPUのスパイクは、GCというアクティビティによるものかもしれません。
5. Elastic Search pre 5.5バージョンでRangeクエリを実行する他の効率的な方法はありますか？
6. クエリをプロファイリングすると、TermQueryとBooleanQueryが実行され、後で最もコストがかかります。

ここで何が起こっているのですか？事前に

おかげで、

• SGSI。

Answer 1

正解はインデックス設定によって異なりますが、有効なdocValuesで整数型を使用していると思います。このデータ構造は集計とソートをサポートしていますが、範囲照会はサポートしていません。正しいデータ型はrangeです。

DocValuesの場合、elastic/luceneはすべてのドキュメントを繰り返し処理します。範囲の照会に一致させるためにフルスキャン） - これはDV列からすべての値を読み取り、デコードする必要があります。特に、この索引をオペレーティングシステムによってキャッシュできない場合は、この操作は非常に高価です。