5

次の自動コミット オプションを使用して、Solr 3.6 でマスター/スレーブ セットアップを実行しています。

最大ドキュメント: 500000

最大時間: 600000

インデックスには約 500 万のドキュメントがあり、約 550 GB を占めています。Amazon EC2 XLarge インスタンス (4 つの仮想コアと 15GB) でマスターとスレーブの両方を実行しています。特に高い書き込みスループットはありません。1 分あたり約 100 個の新しいドキュメントです。

6GB が割り当てられたコンテナーとして Jetty を使用しています。

問題は、コミットが開始されると、すべての更新リクエストがタイムアウトし始めることです (このボックスに対してクエリを実行していません)。コミット自体には約 20 ～ 25 分かかるようです。その間、新しいドキュメントを Solr に追加することはできません。

次の質問の回答の 1 つは、2 つのコアを使用し、完全に更新されたらそれらを交換することを提案しています。ただし、これは少しやりすぎのようです。

インデックスの更新中に Solr リクエストがタイムアウトします。おそらくレプリケーションは可能な解決策でしょうか?

Solr がリクエストをブロックしているように見える理由について、他に確認すべきことはありますか? 見落としていた構成に「dontBlockUpdateRequestsWhenCommitting」フラグがあることを楽観的に望んでいます...

どうもありがとう、

4

2 に答える 2

1

報奨金の理由と質問で言及されている問題によると、Solr の解決策は次のとおりです。

Solr には、Solr のバージョンで始まる SolrCloud と呼ばれる機能があり4.xます。以前のマスター/スレーブ アーキテクチャの代わりに、リーダーとレプリカがあります。リーダーはドキュメントのインデックス作成を担当し、レプリカはクエリに回答します。システムは Zookeeper によって管理されます。リーダーがダウンすると、そのレプリカの 1 つが新しいリーダーとして選択されます。

全体として、各シャードに 1 つのリーダーが存在し、シャードのドキュメントのインデックス作成を担当するため、SolrCloud で問題のないインデックス作成プロセスを自動的に分割したい場合です。システムにクエリを送信すると、いくつかの Solr ノードが存在します (もちろん、シャード カウントよりも多くの Solr ノードがある場合)。これは、インデックス作成を担当していませんが、クエリに応答する準備ができています。レプリカを追加すると、より高速なクエリ結果が得られます (ただし、インデックス作成などの際により多くのインバウンド ネットワーク トラフィックが発生します)。

于 2013-05-21T21:04:14.967 に答える
-1

同様の問題に直面している人にとって、私の問題の原因は、ドキュメントにフィールドが多すぎて、自動フィールド *_t を使用したことでした。フィールドの数はかなり急速に増加し、それが特定の数に達すると、 Hogs solr と commit には永遠に時間がかかります。

第二に、プロファイリングを行うためにいくらかの努力をしましたが、ほとんどの時間は string.intern() 関数呼び出しによって消費されます。ドキュメント内のフィールドの数が問題になるようです。その数が増えると、string.intern () が遅くなるようです。

solr4 ソースはもはや string.intern() を使用していないようです。しかし、フィールドの数が多いと、パフォーマンスが非常に簡単に低下します。

于 2013-05-22T10:02:58.357 に答える