solr.autoSoftCommit.maxDocs:1
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/lygnpj97r9ngj0v8l4q9syt0pclsnoyl into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは、皆さん。
最近、SolrCloudクラスタ（バージョン8.11.2、2コア、32GB RAM）で以下の設定を見つけました。
<autoCommit>
<maxDocs>${solr.autoCommit.maxDocs:-1}</maxDocs>
<maxTime>${solr.autoCommit.maxTime:60000}</maxTime>
<openSearcher>false</openSearcher>
</autoCommit>
<autoSoftCommit>
<maxDocs>${solr.autoSoftCommit.maxDocs:1}</maxDocs>
<maxTime>${solr.autoSoftCommit.maxTime:-1}</maxTime>
</autoSoftCommit>
特に注意を引いたのは、autoSoftCommit.maxDocsが1に設定されている点です。
私の意見では、softcommit.maxDocsが1に設定されているのは（少し？）危険な設定です。
これは、更新された各ドキュメントに対して、すべてのSolrCloudノードが更新されることを意味します。
内部で何が起こっているのかはよくわかりません。これが私の質問です。
例えば、SolrCloudクラスタが数千以上のドキュメント更新のスパイクを受け取った場合、各ドキュメントごとにソフトコミットがクラスタ全体でトリガーされます。この場合、皆さんはどのように考えますか？何が起こると思いますか？
よろしくお願いします。
Vincenzo
そのように低い値は通常あまり意味がありません。特別なコレクションで、すぐにコミットをトリガーしたい場合を除いては。ただし、その場合でも、通常は maxTime:1 の方が適切な設定です。
おそらく、この設定を作成した人はデフォルト値を -1 にするつもりだったのではないでしょうか？
Jan
参考までにお伝えすると、DIH（Data Import Handler）を置き換えるスクリプトで、ドキュメントをバッチ処理で投稿し、commit=true を指定して実行しています。この際のタイミングを計測しました。
- スタンドアロンの「開発用」ノードでは、バッチサイズを約5000ドキュメントにすると最高のスループットを得られました。
- 一方、
numreplicas=2かつnumshards=1の「本番用」2ノードクラウドでは、バッチサイズは2000ドキュメントが最適でした。
1ドキュメントごとにコミットするのは、非常に時間がかかります。
バージョン8.11.2のデフォルト設定では、どちらの autoCommit 設定にも maxDocs の指定がありません。
Dima
autoCommitやautoSoftCommitのソースコードをどこで確認できるか知っていますか？ソフトコミットがトリガーされた後にSolrCloudクラスター内で何が起こるのかを理解したいと考えています。
Vincenzo D'Amore
こんにちは、Janさん。回答ありがとうございます。これはリアルタイムでコレクションを更新する必要があるケースです。ただ、複数の更新がクラスターを遅くする可能性があるのではないかと心配しています。
Vincenzo D'Amore
目安として、可能な限りコミットの頻度を抑え、1回に1つのドキュメントを送信するのではなく、追加リクエストをバッチ処理することをお勧めします。また、クライアントアプリケーションがSolrに対して明示的にCOMMITを呼び出すことも避けてください。これらすべてにはコストが伴います。
もし要件が「30秒以内のインデックス作成レイテンシー」であれば、autoCommitの設定を30秒に基づいて行い、それ以上頻繁にはしないでください。この制限を低く設定しすぎると、処理を維持するためにより多くのハードウェアが必要になるというコストが発生します。
Jan
こんにちは Jan、アドバイスありがとうございます。
私がこの設定（autoSoftCommit.maxDocs:1）を見つけたSolrCloudクラスタが最近ダウンしました。すべてのノードが影響を受け、すべてのコレクションとすべてのレプリカのステータスが「ダウン」または「リカバリー中」（ただし成功せず）になっていました。
すべてのSolrCloudノードで見つかった唯一のエラーは以下の通りです："java.util.concurrent.RejectedExecutionException: Max requests queued per destination 3000 exceeded for HttpDestination"
Vincenzo D'Amore
こんにちは
それは驚くことではありません。クラスタが各ドキュメントごとにコミットを強制するよう指示された場合、インデックスセグメントが急増し、それが原因でより多くのマージやウォーミングが発生します。その間、新しいインデックスリクエストは順番待ちをする必要があります。これが原因で、サーバー側のスレッドが枯渇し、見ている「Max requests queued per destination 3000 exceeded」の制限に達してしまいます。
したがって、autoCommitの設定を修正する必要があります。
それでも「Max requests queued per destination」エラーが発生する場合、このバグ SOLR-17240 を確認し、提供されている回避策を試してみるとよいでしょう。
Jan
こんにちは、Janさん、Matthiasさん、確認ありがとうございます。
まだ SOLR-17240 の詳細を深く読んではいませんが、一つ質問です。将来的にこのバグに取り組む予定がある方はいますか？
もし予定がない場合、これは難しい修正作業だと思いますか？あまり複雑でなければ、私がボランティアとして取り組むことも可能です。
Vincenzo D'Amore
こんにちは、Vincenzoさん、Janさん
私は多くのユースケースで「1回のドキュメント更新」を実装しています。特に、高速でドキュメント更新履歴を追跡したい場合には有効です。バッチ処理は優れていますが、ADDログの粒度を維持したい場合には適していません…とだけ言っておきます。バッチ処理で高速にインジェストできますが、私は過去にeコマースのエンゲージメントでインデクサの履歴テーブルを保持してさまざまな統計を監視していた経験から、少なくともドキュメントごとの洞察が得られる方が好ましいと思います。ただし、ドキュメントごとにコミットすることは絶対に避けるべきです！
トピックへ返信するには、ログインが必要です。