メッセージの件名には「最適化」とありますが、メッセージ本文にはそれについて言及されていません。

最適化が関与しているのでしょうか？大規模なインデックスの最適化は常に遅くなります。

Solrには「古いレコードを削除する」という機能はないと聞いていますので、それはおそらくあなたのコードに関するものです。そのコードに関しては、どのようにして有用なログを取得するかについて多くの情報が必要となるため、私たちがトラブルシューティングするのは難しいです。

もしSolrからのエラーに遭遇している場合、solr.logに少なくとも何が起こったのかについての情報があるはずです。その情報があれば問題の特定に役立つかもしれません。

ロードバランサーの変更が問題を引き起こしている場合、ロードバランサーのトラブルシューティングを理解している人に相談する必要があるかもしれません。

基本的に、私たちがあなたを助けるためには、もっと多くの情報が必要です。

よろしくお願いします、
Shawn

ありがとう、Shawn
確認してみます。solr.logファイルをチェックしましたが、エラーは見つかりませんでした。ロードバランサーを変更してからこの問題が発生しています。

SolrがAPIを実行するのにかかる時間を確認する方法はありますか？また、特定のレコードを手動でSolrインデックスにクエリする方法や、提供できるAPIのドキュメントを共有してもらえますか？

よろしくお願いします。

Solr自体が実際に遅くなったかどうかを確認するためにメトリクスをチェックできます。Solrはロードバランサーとは関係がないので、遅くなっているとは思えません。また、心配な表現がありました。「削除されたドキュメントをクリアする」というのは、最適化コマンドのように聞こえます。ユーザーとしては、それを使用せず、Solrにインデックスの管理を任せるべきです。常にフルインデックスの3倍のディスクスペースを確保しておくようにしてください。

何を尋ねているのか完全にはわかりませんが、わかる範囲でお答えします。

Solrのログ（solr.log）には、デフォルトのログレベルを変更しない限り、各クエリが記録されます。それらのログ行には、クエリの実行にかかった時間をミリ秒単位で示すqtimeパラメータが含まれています。レスポンスの構築やネットワーク経由で送信するのにかかる時間はqtimeに含まれていません。

あなたのインデックスについては何も知らないので、特定のドキュメントをクエリするための具体的な指示はできませんが、多くの場合、「id:value」のようなクエリ文字列が特定のドキュメントを返します。これは、「id」フィールドがuniqueKeyであることを前提としています。

よろしくお願いします、
Shawn

AWSで「Network Load Balancer」を試してみてもらえますか？

Deepak

こんにちは、

現時点ではNLBに変更することはできません。まず、なぜタイムアウトが発生するのか理解する必要がありますが、現時点では手がかりがありません。タイムアウトを60秒から4000秒に増やすと正常に動作します。同じコードがクラシックロードバランサーでは正常に動作しますが、ALBではこの問題が発生しています。

よろしくお願いします、
Pradeep

はは、atonではなくqtimeを意味していました。一般的に、Solrにはロードバランサーを使用すべきではありません。ページングして結果を取得する場合、各後続のクエリでインデックスをホットでメモリに保持できないためです。私の経験では、ロードバランシングの代わりに、ノードにフェイルオーバーを設定するのが最善の方法です。

Solrのログでqtimeが増加していない場合、これはSolrの問題ではないので、AWSに連絡するべきだと思います。そして、再度申し上げますが、ロードバランサーを使用しないほうがいいと思いますが、これはあくまで私の個人的な意見です。

私は常にロードバランサーを使ってきました。NetflixでのSolr 1.2から始めています。フェイルオーバー（冷たい）スペアは、キャッシュが冷たいため、キャッシュが満たされるまでパフォーマンスが低下します。私はN+1のキャパシティを設定します。つまり、N台のサーバーが予想される負荷を処理できるようにし、故障時の対応として1台追加します。すべてのスペアはホットです。

私はSolr Cloudへの更新もロードバランサーを介して行います。これは簡単に設定でき、Solrは文書をシャードリーダーに効率よく転送することができます。更新用に独立したロードバランサーを持つことで、クエリと更新の負荷を分けてモニタリングとアラートを設定することができます。

スマートなロードバランサーを使えば、同じクエリを同じホストに送り返すこともできますが、AWSのロードバランサーはあまりスマートではありません。

wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (私のブログ)

なるほど、理解しました。あなたのバランサーでスティッキーセッションなどができれば、そして私の場合はNetflixのようなスループットに対処する必要がないので、私の多くの場合では、非常にホットなサーバー1台がN台のウォームなサーバーよりも良いと感じています。

「しかし、AWSのロードバランサーはあまりスマートではありません。」- その通りですが、それに対して何か試みているようですね：
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/sticky-sessions.html

ただし、アプリサーバーをSolrサーバーにスティッキーセッションできるのでしょうか？
例えば：
ユーザー -> ロードバランサー -> アプリサーバー X -> Solrロードバランサー -> Solrサーバー X
そして、アプリサーバー X と Solrサーバー X がユーザーのセッション中に接続されたままにすることができるでしょうか？ これの設定方法について知りたいです。

スティッキーセッションは後のページに対してのみ役立ちます。それらは既にそのクエリをキャッシュしているサーバーに新しいクエリを直接向けることはありません。これは2番目のページよりも大きな利益です。

私はクエリの意味のあるパラメータ（q、bqなど）のハッシュを作成し、それに基づいてルーティングすることを考えたことがありますが、それには他の問題があります。1台のサーバーがダウンすると、すべてのキャッシュが同時にクリアされ、サーバーの過負荷を引き起こす可能性があります。これは実際の問題で、かつてInfoseekの検索エンジンをダウンさせた原因です。全てのサーバーが連鎖的にダウンしました。

この問題を修正するためにはいくつかのハッシュアプローチがありますが、テストが困難です。

本当に効果的なキャッシュが必要ならば、ロードバランサーの前にHTTPキャッシュを置きます。これはリクエストのルーティングであれこれ悩むよりも遥かに良い方法で、テストも最小限です。なぜなら、キャッシュサーバーはそのようなことをするように設計されているからです。私はいくつかのベンチマークを行いましたが、Varnishキャッシュが単一のSolrサーバーのキャッシュよりもわずかに速かったです。

wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (私のブログ)

興味深いですね。実際、私が使用した方法の1つは、次のページの結果をWebサーバーのメモリに保存するためにMemcachedを使用する方法でした。メモリが十分にあれば非常に効果的でした。