更新のための最適なスロットリング／プッシュバック戦略は何ですか？
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/zwv3gv6ovk7n3dg6crc5nz4sb4m7q2wl into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは、
Solrに更新を送信する際、Solr側のCPUを利用するためには、しばしばマルチスレッドで実行する必要があります。
しかし、クライアント（純粋なHTTP POSTまたはSolrJであるかどうかにかかわらず）は、Solrがインデックス速度に満足しているかどうかをどのように知ることができますか？
私は、Solrがその負荷レベル、インデックス待ちキューの充填率、またはその他の希望するメトリクスをチェックし、HTTP 503やカスタムSolr HTTPコード「533 スローダウン」で呼び出し元に応答するフィードバックメカニズムを考えています。クライアントは、一時停止して再試行する必要があることを知るでしょう。クライアントはその後、指数関数的なバックオフ戦略を実装して、自分のインデックス速度を調整できます。そのようなシステムの利点の1つは、Solrがクエリトラフィックが多い期間、バックグラウンドマージアクティビティ、リカバリ、レプリケーション、ウォーミングが遅すぎる場合（最大ウォーミングサーチャーなど）など、インデックス速度を遅くするよう指示できることです。
Elasticには類似したものがあると知っていますが、私が知らないAPIにすでに何かあるでしょうか？
Jan
マスター/スレーブシステムでは、マスターへの送信速度をできるだけ速くしても問題ありません。
クラウドシステムでは、クエリに影響を与えない範囲でインデックス化の負荷を維持したいと考えています。
私はこれを、インデックス化スレッドの数をCPUの数に合わせることで行っています。
大まかに言うと、2つのスレッドは1つのCPUを忙しくさせ、つまり、1つのスレッドがバッチを終了するのを待っている間に、次のバッチを送信するスレッドがあります。
8 CPUのマシンでは、100%を使用するために16スレッドを使用します。または、25%を使用するために4つのスレッドを使用します（2 CPU）。
シャードシステムでは、インデックス化はリーダーに分散されます。たとえば、8つのシャードを持つシステムでは、64のスレッドは各リーダーの2つのCPUをビジーに保ちます。このスレッドの数は、分単位で約50万の更新を実行するため、さらなる調整は必要ありません。 72 CPUを備えたホストでは、2つのビジーCPUが十分です。
また、クラウドに敏感な機能を使用していません。私たちは単にロードバランサーに更新バッチを投げます。1つのローダーはシンプルなPythonプログラムで、それにすべてのJSONを送信します。これは64スレッドで480k/minを行っています。
最後に、インデックスには別のロードバランサーを使用しています。これにより、クエリトラフィックと更新トラフィックの応答時間のアラートレベルを異なる値に設定できます。また、更新とは別にクエリトラフィックの異常なバーストを見ることができます。
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (私のブログ)
はい、それが私が現在顧客に推奨していることです。すなわち、インデックススレッドをCPUに手動でマッチングすることです。これが「手動」の方法です。
私の質問はむしろ、クライアントが後退システムを追加するかどうか、または追加したいかどうか、というものでした。クライアントはバックオフされるまで全速力で進むことができ、その結果、Solrがうまく処理できるものに完全に調整されます。
この間、クライアントがクエリ負荷が同時に発生しているシステムに対してあまりにも高速にインデックス化されていたため、深刻な遅延やGCの一時停止が発生しました。
Jan
サーキットブレーカーは検索のみをキャンセルします。更新には影響しません。
数週間前にそのコードを確認し、承認待ちのパッチがあります。
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (私のブログ)
そのアイデアは本当に気に入っています。私も過去に、負荷がかかりすぎて（いくつかの）更新が失敗することがありました。その結果、長い（かなりの）GC停止時間が発生しました。インデックスを一時停止して、Solrに追いつくチャンスを与えるオプションがあれば非常に役立つと思います。通常、これらの問題を管理するためにリトライ句を持っていますが、一般的に汎用エラーをキャッチしているため、特定のエラーコードをキャッチして、一定の間隔で再試行してみるというアイデアは一定の価値があると思います。
ありがとうございます。
Dwane
トピックへ返信するには、ログインが必要です。