新しいコアをウォームアップするためのfirstSearcherクエリ
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/5mr9vxb14oj4q8kks3potk02q17fkszt into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは、
solrconfig.xmlでの「firstSearcher」クエリを使用して、新しいコアのキャッシュをウォームアップしようとしています。
観察される現象は、新しいコアが作成された直後に「CoreAdminOperation core create command ...」と「Opening new SolrCore at ...」が発生し、その後「searcherExecutor」が起動され、最初の検索者からのウォームアップクエリのリストが実行されることです。これは正しくありません。なぜなら、インデックスがまだリーダーからダウンロードされていないため、最初の検索者のクエリは無効になるからです。
「searcherExecutor」が空のインデックスに対して実行される間、ログに次のメッセージが表示されることも観察されました。「ZkController Core needs to recover: core_name」。次の質問に関してお助けします：
- 「firstSearcher」クエリはいつ実行されるべきですか？新しいコアが作成された直後か、インデックスがリーダーからダウンロードされた後ですか？
Solrのバージョン：8.8.2、8.10.1
ありがとうございます。
最初の検索者クエリは、新しい検索者がコアのために作成され、以前の検索者が存在しない場合に実行されます。
これは以下のタイミングで行われます：
- コアが最初に作成されたとき。
- コアが再ロードされたとき。
- Solrが再起動されたとき。
新しい検索者クエリは、既存の検索者が新しいものと置き換えられたときに実行されます。これは通常、コミット時に行われます。
ありがとうございます。
Shawn
理解しました。ただし、コアが最初に作成されるとき、データはまだ存在しません。最初の検索者クエリを空のインデックスに対して実行すると、キャッシュのウォーミングには何の効果もありません。データがリーダーから取得された後に最初の検索者を開く方法はありますか？つまり、ウォームアップクエリを実行しますか？最初の検索者を最初にコアが作成されるときに開く目的は何ですか、データがない場合ですか？
ウォーミングクエリなどの目的では、最初の検索者は起動時にインデックスが空であることを認識していません。単に最初の検索者であることを知っており、その場合には、構成された最初の検索者クエリを実行します。このようなクエリを回避するためにそのようなことを認識させることは可能ですが、それには多くの複雑さが加わります。コードが複雑になるほど、バグが発生しやすくなります。そして、このような重要なコードの複雑さの追加による利点は、リスクを上回らないと強く主張します。
これが本当に心配な場合は、インデックスが構築された後にコアを再読み込みするようにインデックスソフトウェアを設定して、再び最初の検索者クエリが実行されるようにします。最初の検索者クエリの実行に時間がかかる場合は、useColdSearcherをtrueに設定して、ウォーミングクエリが実行される前に検索者がクエリに対して準備されるようにします。solrconfig.xmlのどこにその構成があるかは覚えていません。
一般的に推奨することは、完全にクールなインデックスで初期ウォーミングを実行する一連のクエリを最初の検索者で定義し、useColdSearcherをtrueに設定し、その後は主にキャッシュの自動ウォーミングに頼ることです。キャッシュの自動ウォーミングがうまくいかない場合は、いくつかの対処法があります。
1) インデックスをより良くキャッシュできるように、より多くのメモリを追加します。
2) キャッシュの自動ウォーミングの設定を変更します。
3) newSearcherでいくつかのクエリを定義します。
newSearcherは、通常、firstSearcherよりも少ないリストです。
多くのパフォーマンスの問題は、OSがインデックスをより良くキャッシュできるようにするために、より多くのメモリを追加することで解決されます。良好なインデックスのキャッシュは、Solrを含むすべてのLuceneベースのソフトウェアから良好なパフォーマンスを得るために重要です。ここで話しているのはヒープサイズではなく、どのプログラムにも割り当てられていないメモリです。
最初の検索者クエリのリストを構築する際に考えるべきことは、OSのディスクキャッシュとSolrのキャッシュのポピュレーションプロセスを開始することであり、ユーザーが作成する可能性のあるすべてのクエリのバリエーションを実行することではありません。そのリストに数十のクエリが含まれるようなら、おそらく長すぎます。
よろしくお願いします。
Shawn
重要な考慮事項を追加したい（過去に私にさまざまな頭痛を引き起こしたものです）：
最初の検索者クエリのリストは、「*/select*」リクエストハンドラに対して'*q*'パラメータとして実行されます。
つまり、このハンドラのデフォルト、追加、不変性に注意する必要があります。
最後に確認した時点では、最初の検索者/新しい検索者にヒットするハンドラを指定することはできなかったはずですが、現在の状況が変わっている可能性がありますので、確認してみることをお勧めします。
よろしくお願いします。
Alessandro Benedetti
Apache Lucene/Solr コミッター
ディレクター, R&D ソフトウェアエンジニア, 検索コンサルタント
Shawn、包括的な説明ありがとうございます。
確かに、事を単純に保つ必要がありますが、まだ疑問があります。新しいコアが作成されるときの「firstSearcher」クエリの最初の目的が満たされていないと思います。コアをリロードするか、Solrを再起動する場合には機能しますが、新しいコアが作成されるときには明らかに意図どおりには機能していません。これに対処する必要があると思います。
その解決策として、最初の検索者が開かれる前にコアが作成され、その後にIndexFetcherが実行されるように順序を変更することが考えられます。順序の変更だけで解決することができます（おそらく少しの変更が必要ですが、ロジックに根本的な変更は必要ないと思われます）。
ちなみに、"firstSearcher"クエリを実行するためのワークアラウンド方法として、新しいコアが作成された直後にREQUESTRECOVERYアクションを発行することが挙げられます。これにより、コアがリーダーからインデックスを「すぐに」取得し、その後でfirstSearcherクエリが再実行され、データが含まれるインデックスに対して実行されます。現在、この解決策をテストしていますが、期待どおりの結果が得られています。キャッシュがウォームアップされ、新しいコアが作成されたときにクラスターのパフォーマンスに影響はありません。
問題が見当たりません。それは、構成されたとおりに動作しています。最初の検索者が開かれると、firstSearcherクエリが実行されます。コアが真新しい状態でインデックスがまだ存在しない場合、これらのクエリはほとんど時間を要しません。
ここで言及されていない要素が追加されています--レプリケーションが関与しているという事実です。
レプリケーションは少し複雑さを追加し、そのため、レプリケーションが考慮されるべきです。コーダーの帽子をかぶると...レプリケーションされたインデックスがnewSearcherではなくfirstSearcherクエリを実行するタイミングを特定するのは非常に難しいかもしれません。
そして、おそらくもう1つの問題がありますが、それは以前に言及されていませんでした--SolrCloudです。
REQUESTRECOVERYは、SolrCloudモードで実行している場合にのみ有効な操作です。そして、SolrCloudを実行している場合、CoreAdmin APIを使用してはいけません。SolrCloudでインデックスを操作する場合は、すべての操作をCollections APIで行う必要があります。CloudモードでCoreAdmin APIを使用すると、問題が発生します。SolrCloudコレクションを破損させた人々を助けようとしましたが、CoreAdminを使用して操作を行うことで、問題が発生しました。うまくいきませんでした。
追加のレプリカを追加する場合は、Collections APIを使用してそれを行い、その後、コレクションを再読み込みします。その背後で、コレクションを構成するすべてのコアを再読み込みし、すべてのレプリカでfirstSearcherクエリが実行されます。
ありがとう、
Shawn
トピックへ返信するには、ログインが必要です。