ウォーミングクエリのパフォーマンスチューニング方法
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/5h185ssdd5zb1zc2hgmm1qwws5xpn3fg into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
私のウォーミングがなぜそんなに時間がかかるのかを理解しようとしています。平均で20〜40秒かかります。ウォーミングが時間を費やしている場所を測定できますか？
最初の検索者と新しい検索者は次のように設定されています：
<listener event="firstSearcher" class="solr.QuerySenderListener">
<arr name="queries">
<lst>
...
<str name="q">world</str>
<str name="sort">popular_score desc, grouping asc, copyrightyear desc, flrid asc</str>
<str name="rows">2500</str>
<str name="fq">(languagecode:"eng")</str>
<str name="fq">(titletype:"BK")</str>
<str name="fq">((grouping:"1" OR grouping:"2" OR grouping:"4"))</str>
<str name="fq">(languagecode:"eng" OR solrtype:"N")</str>
<str name="fq">(ib_searchable:"Y")</str>
<str name="fq">((grouping:"1" OR grouping:"2"))</str>
…
<str name="facet.range">arrl</str>
<str name="f.arrl.facet.range.start">0</str>
<str name="f.arrl.facet.range.end">17.9</str>
<str name="f.arrl.facet.range.gap">2</str>
<str name="f.arrl.facet.range.other">before</str>
<str name="facet.field">itemtypesubcode</str>
<str name="f.itemtypesubcode.facet.method">fc</str>
すべてのFQは、アプリケーションログの分析から得られる最も一般的なFQです。約35個あります。ファセットクエリは、アプリが要求するすべてのファセットです。facet.field、facet.range、facet.queryのすべてが含まれます。約25個あります。
私が心配しているのは、ウォーミングのファセットまたはFQの1つがすべての時間を取ってしまっている可能性です。ウォーマーが時間を費やしている場所を特定できますか？
ありがとうございます、
Andy
巨大なクエリのどの部分が最も時間がかかるかを特定する方法はわかりません。デバッグを有効にしてクエリを手動で実行し、報告されたタイミングが役立つかどうかを確認することができます。一般的に有用であるかもしれませんが、具体的な部分には適していないかもしれません。
私がお勧めするのは、（クエリトラフィックが最小の場合に）すべてのウォーミングをオフにして、再起動し、その後、各fqとfacetを個別にチェックする手動クエリを実行することです。各クエリテストの前にOSディスクキャッシュを再起動するかクリアすると、最悪のケースの情報を得ることができます。
最初は、すべてのファセットを削除するか、すべてのfqを削除して、どこにテスト時間を費やす必要があるかを確認してください。
私は個人的には、newSearcher構成からすべてのfqsを削除し、filterCacheの自動ウォーミングに一般的に使用されるfq値のウォーミングを任せます。firstSearcherにはそれらを残し、cold searcherを使用するようにsolrを構成します。自動ウォーミングがファセットを処理できるかどうかはわかりませんが、私にとっては不可能に見えます。
ファセットに使用するすべてのフィールドがdocValuesで構成されていることを確認し、その構成を追加する必要がある場合は、必要に応じてゼロから再インデックスを行ってください。ファセットに使用するTextFieldベースのフィールドがある場合、これらはdocValuesで構成することはできません。TextFieldを使用するフィールドは、通常、カーディナリティが非常に高いため、ファセットには適していない可能性があります。高いカーディナリティは、極めて遅いファセットを作成します。
そして、ファセットのために十分な余分なメモリがあることが非常に重要です。OSがインデックスデータを効果的にキャッシュできるようにする必要があります。
ここで大きな問題がファセットにあると予想しています。一部のファセットが主な問題であることがわかった場合、それらをウォーミングから削除し、多くのユーザーの一般的なパフォーマンスを改善するために、特定のクエリが遅くなる必要があることをユーザーに通知できます。
ありがとうございます、
Shawn
大変ありがとうございます。これは非常に助かります。
それが私の計画ですが、まず最初に退屈な作業から救ってくれるツールがあるかどうかを確認したかったのです。
既存の検索ノードからキャッシュされたFQを新しい検索ノードに持ってくる場合、newSearcherの起動クエリには何を持っているべきですか？
よろしくお願いします、
Andy
フィルターキャッシュはfqパラメーターの自動ウォーミングを処理することを知っています。queryResultCacheがファセット関連の情報を保存しているかどうかはわかりませんが、おそらく保存していないと思います。
もし、あなたのファセットフィールドがすべてdocValuesを持っている場合、OSディスクキャッシングがそれらを高速化するために必要なものであると考えます。Solr/Luceneのキャッシュではなく。docValuesがない場合、ファセットのために必要なデータ構造はJavaヒープ内で生成されるため、時間とメモリーがかかり、多くの場合、大量になります。
私が詳細を間違えている可能性もありますが。
ありがとうございます、
Shawn
これは、新しい検索者でのウォーミングクエリには価値がないと言っているように聞こえますね。それで合っていますか？
もし私の理解が完全に正しいのであれば、その主張に同意せざるを得ません。fqの場合はfilterCacheの自動ウォーミングを頼りにし、facetの場合はディスクキャッシュを利用するのが良いです。自分の経験から共有すると、filterCacheに関してはautowarmCountを非常に小さな値に設定する必要があることがわかりました。私の場合、その数値は4でした。それでもキャッシュのウォーミングには最大で15秒かかりました。これはインデックスシャード（手動のシャーディング、SolrCloudなし）で、コアのサイズは約50GBでした。
また、もし私の理解が正しいのであれば、firstSearcherでのfacetのエントリーは、OSディスクキャッシュをクリアするなどのリブートを行った場合にのみ価値があるでしょう。しかし、firstSearcherでのfqのエントリーは、Solrの再起動時（おそらくコアのリロード時も）に依然として価値があります。つまり、空のfilterCacheを満たすことができます。
もし私の理解に誤りがあると判明した場合は、ぜひ教えていただきたいです。
ありがとうございます、
Shawn
トピックへ返信するには、ログインが必要です。