インデックス更新中にSolr要求がタイムアウトしました。おそらく複製は可能な解決策ですか？

Question

Solrインストールを実行しています（すべての標準的なjetty環境で、スキーマにいくつかのフィールドを追加しました）。

インデックスは平均サイズの約80kドキュメントです（それぞれ約100文字で20フィールド）。

問題は時々、いくつかの要求がタイムアウトすることです。彼らはサーバー側のタイムアウトはしませんが、アプリケーションがタイムアウトとみなす10秒以上かかることがあります。彼らは通常、80ミリ秒以上の時間がかかりません。

インデックスを再構築することと関連しているようです（データベースから情報を収集していますが、インデックスは常に200個のドキュメントの塊で更新しています）。インデックス作成ジョブを更新するためのドキュメントがない場合、絶えず必要に応じてスリープ状態に移行します。私は、15〜20分ごとにコミットが発生すると推測します。

私はsolr faqsを読みましたが、これは一般的な問題だと思われますが、解決策は見つけられませんでしたが、タイムアウトを増やすことができました。

ただし、10秒を超えるサイトリクエストは受け付けられません。

どうすればこの問題を解決できますか？インデックス作成にinstallatinoを使用し、それをライブで使用されている別のものに複製することを考えました。しかし、これはこの問題を解決するだろうか？

これに関するご意見はありますか？

Answer 1

あなたはほとんど正しい軌道に乗っています。これを解決する1つの方法は、更新に2番目のコアを使用し、この2番目が完全に更新され、コミットされると、最初のコアでをアクティブにします。

私は（ここsnippetだ）、このアプローチは、本「Solr 1.4 Enterprise Search Server」に詳細に記載されていると思います

Answer 2

それはそのキャッシュを再構築している場合、私は検索者が遅くなるだろうと思うことができる唯一の理由です。あなたの検索人を役に立つクエリで温かいですか？

私の考えは...

それ自身の更新は、読み取りまたは書き込みをブロックしません。コミットは書き込みをフラッシュするときに書き込みをブロックしますが、書き込みはブロックしません。 1つの更新がフラッシュされ、新しいサーチャーが初期化され、ウォームされ、古いサーチャーの代わりにスワップアウトされます。

この時点で検索がタイムアウトしている場合は、後で検索する必要があるウォームアップキャッシュ中に、最初の数少ないリクエストが大量のIOバウンドになる可能性があります。したがって、あなたの検索者が役に立つクエリで暖かされているかどうかは疑問です。議論の便宜上

は、ここで最もデフォルトっぽいsolrconfig.xmlファイルに存在するサンプルnewSearcher温暖化クエリです：

<listener event="newSearcher" class="solr.QuerySenderListener"> 
    <arr name="queries"> 
    <lst> 
     <str name="q">solr</str> 
     <str name="start">0</str> 
     <str name="rows">10</str> 
    </lst> 
    <lst> 
     <str name="q">rocks</str> 
     <str name="start">0</str> 
     <str name="rows">10</str> 
    </lst> 
    </arr> 
</listener> 

おそらく、あなたはまだこれを使っていますか？ :)

レプリケーションは、この種のシナリオに入るのに最適な方法です。しかし、あなたがすでに使い慣れている同様の仕組みを持っているかもしれません。

Answer 3

時折しか表示されず、ドキュメントの数が増え続ける場合は、マージ限界になる可能性が高くなります。古いセグメントが新しいセグメントに変わると、マージは恐ろしく高価になり、あなたのキャッシュはすべてブートにダンプされます。

マスター/スレーブ設定、SWAP（上で見たように）などをバンプ上で円滑にしたいのは間違いありません。