6

質問1：solrconfig.xmlでサーチャーを最適化しようとしていますが、ウォームアップする可能性のある2つの異なるサーチャーがあります。私の理解では、firstSearcherはサーバーの起動時にのみ起動します。新しいサーチャーが必要なときはいつでも、newSearcherが作成されます。それぞれに同じfqとファセットを指定したいと思うようです。それらを異ならせたい場合はいつですか？

質問2：fqまたはファセットを追加することによるサーチャーの起動時間への影響を判断する方法はありますか？fqs /ファセットを使用したサーチャーと使用しないサーチャーの起動時間をブルートフォースで測定できることは知っていますが、それはそれほど詳細ではありません。個々のfq/ファセットにコスト/メリットがあると仮定して、それを測定して、温暖化する価値があるものとそうでないものを判断できるようにしたいと思います。

質問3：filterCacheのサイズを効果的に設定するにはどうすればよいですか？ヒットする可能性が高いとわかっている特定のfqのセットがあり、そのうちの約500は、500に設定するようです。ただし、Solrは、ファセットが必要なクエリ結果にfilterCacheを使用しているようです。私のクエリの90％はファセット化されているため、キャッシュサイズの基準として予想されるクエリの数を使用する必要があるようです。それは正しいですか？

4

1 に答える 1

2

  1. あなたの理解は正しいです。ただし、newSearcherは最後のものから自動ウォームアップできるため、これが1つの違いです。もう1つは、newSearcherはコミットごとに発生するため、頻繁にコミットを実行している場合は、コールドを開始している場合よりもかなり少ない作業を実行したい場合があります。

  2. 私は素晴らしい方法を知りません。クエリはシリアルに実行され、少なくともfirstSearcherではアクセスログに表示されるため、文字通りどのくらいの時間がかかるかを確認できます。ただし、特定のクエリセットが「十分に暖かい」結果になるかどうかは、かなり試行錯誤です。

  3. FilterCacheサイズについて覚えておくべき最大のことは、単一のエントリが約（インデックス内のドキュメントの数）/8バイトであることです。したがって、サイズを500に設定し、インデックスに1億のドキュメントがある場合、それを保持するためだけに6.25Gのヒープが必要になります。一般に、ディスクキャッシュ用により多くのメモリを残すために、ヒープのサイズをできるだけ小さくすることをお勧めしますが、これは例外です。キャッシュにエビクションプレッシャーをかけるファセットクエリに関する限り、私は同じ問題を抱えており、解決策を知りません。https://issues.apache.org/jira/browse/SOLR-8171を参照してください。

于 2016-05-11T23:15:42.017 に答える