SOLR のインデクシングに関するヒント
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/xjz78hmjjplcj0gcv5qgyojptxjdny10 into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
みなさん、
現在、Solrが書き込みパフォーマンスでボトルネックになっています（多くのCPUを使用し、書き込みがキューに溜まっています）。セットアップを大幅に変更せずに、それ以上の書き込みパフォーマンスを引き出す方法についてのヒントを探しています。
以下がセットアップです：
- Solr 8.2（重要な変更があるかもしれませんが、変更履歴を見てもパフォーマンスに大きな影響があるとは思いません）
- レプリカ設定（1つのノードがインデックス作成を担当し、他のノードは10分ごとにレプリケーション）。インデックスノードは8コア、16GのRAMを使用しています。
- 9つの異なるコアがあります。それぞれのコアはディスク上で約100MBを占め、約90,000件のドキュメントが含まれています。
- 更新はバッチサイズ1000で行われ、各コアごとに約9つのプロセスが並列で実行されています。
- セットアップはかなりシンプルで、特別な文字列処理器は使用せず、デフォルトの設定に近い状態です。コア設定でいくつかのフィールドタイプが定義されており、保存されるIDもごく一部です。
問題点：
- 現在、2つのコアと8GBのRAMを持つマシンで全ドキュメントの更新を処理するのに約3時間かかっています。
直感的な仮定：
- インデックス全体のサイズがかなり小さい（ディスク上で合計約1GB以下）で、インデックスを作成するマシンもかなり強力であるため、インデックス作成（更新）はかなり高速であるはずです（おそらくすべてのドキュメントに対して10分未満）。しかし、実際にはそれよりもはるかに長くかかっており、何か間違っている可能性があります。
探していること：
- 何がこの問題の原因となっているのかのアイデア
- 書き込みパフォーマンスのための共通のチェック項目やヒント、おすすめの参考資料
- 書き込みパフォーマンスの計測方法。たとえば、Solr側で時間がかかっている箇所をモニタリングする方法など、具体的に時間がかかっている箇所を絞り込む方法について
Solrの用語の誤用があれば申し訳ありません。
皆さんのヒントやご意見を、この場を借りてお伺いできれば幸いです。
Marius
過去の類似のお問い合わせ
- Solr 8.7 を Java 11 Open J9 で起動するときに、コマンドラインオプションが認識されない
(The bot translated the original post https://lists.apache.org/thread/p3t5jbhwzy7xgyv1rlyzcqyl5d4295b5
into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)こんにちは、
現在、Java 8 から Java 11 への移行を進めています。
Windows上でOpenJ9 Javaを使ってSolr 8.7.0を起動すると、次のメッセージが表示されます：
JVMJ9VM007W Command-line option unrecognised: -Xlog:gc*:file="C:\solr\server\logs\solr_gc.log":time,uptime:filecount=9,filesize=20M JVMJ9GC063E Unable to open file '"C' for writingその後、コンソールにはガベージコレクションの出力が続きますが、Solrは問題なく起動し、動作しているように見えます。同じリリースのJava 11 Hotspotに変更すると、警告や他の問題は見られません。
Ubuntu上のJava 11 Open J9でも同様の問題が発生します。Solrログには「Command-line option unrecognised」というメッセージが表示されますが、コンソールには表示されません。
solr_gcログは正しく作成され、内容も記録されています。これを確認したのは、OpenJDK 11.0.10+9リリースを使用した場合です。
以下は私たちの起動コマンドの例です：
C:/solr/bin/solr.cmd start -c -p 8983 -s C:/data/solr/8/clusters/is_cluster/nodes/node1 -a "-Dcom.ibm.crypto.provider.DoRSATypeChecking=false -Djetty.server=com.i2group.disco.search.solr.jetty.wrapper.XmlConfigurationWrapper -Dpkiauth.ttl=60000 -Dsolr-node-id=node1 -DzkCredentialsProvider=com.i2group.disco.search.solr.common.zookeeper.auth.internal.EncodedZkCredentialsProvider -Djdk.nativeCrypto=false" -m 2g -z "localhost:9983/is_cluster"よろしくお願いします。
Lisa
- ZooKeeperのupconfigはZK_HOST形式のURLを認識しません
(The bot translated the original post https://lists.apache.org/thread/tfpn1tlgosx67n5omzpkmrdzvsbr02bd
into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)こんにちは、
Solrのコントロールスクリプトを使用して新しいconfigsetをZooKeeperにアップロードしようとしたところ、-zパラメータがZK_HOST形式の文字列を認識しませんでした。
たとえば、
<ip-1>,<ip-2>,<ip-3>/solrを使用すると、configが/solr znodeではなく、直接<ip-1>にアップロードされます。これが意図された動作かどうかについて助けていただけないでしょうか？
注：
<ip-1>/solr,<ip-2>/solr,<ip-3>/solrはうまく機能するようです。 - CustomBreakIteratorのパフォーマンスに関する問題
(The bot translated the original post https://lists.apache.org/thread/4kryrpfp9bdl3dbyb77vnmlfdlcg0dcd
into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)こんにちは、
現在、統合ハイライト機能でカスタムBreakIteratorを動作させる作業をしており、パフォーマンスに苦労しています。
私はパッセージの見出しをきれいにハイライトするためにBreakIteratorが必要です。これにより、ハイライトの開始が文の開始であり、終了が単語の終わりであるようにしたいです。また、いくつかの奇妙なエッジケースもあります。
すでにBreakIteratorをコーディングし、カスタムUnifiedHighlighterクラスに統合しましたが、このIteratorを使用すると、すべてのリクエストのqTimeが約1000から12000以上に上昇し、このアプリケーションでは許容できません。
こちらが私の実装へのリンクです。どこが非常に非効率的なのかを見つけることができません。（これらの関数が非常に頻繁に呼び出されることはわかっています）
他のアプローチも含め、すべての提案を歓迎します。
したがって、BreakIteratorや関連する情報について詳しく学ぶための良いリソースはありますか？ここではコードの調査が非常に難しいです。
次に検討しているもう1つのアプローチは、最終的なハイライトが見つかったときにこのハイライトの「トリミング」を行うことです。これにより、呼び出されるロジックの量が減少しますが、SOLRのスコアリングシステムが正しく考慮されない可能性があると思われます。
私が言ったように、すべての提案を歓迎し、先にお礼を申し上げます。
Jan Ulrich Robens
- 検索ストリーミング式で特定のシャードからドキュメントを取得
(The bot translated the original post https://lists.apache.org/thread/vdqjcy6frv9c2kg97xh244ppj1v5jgc2
into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)「Search streaming expression」で単一の特定のシャード（または特定のレプリカ）からすべてのドキュメントをストリームできますか？ 通常の「shards」パラメータを使用しても、Search streaming exprと一緒に使用すると効果がないと思います。
--ufuk
- カスタムSolrプラグインを作成するには、コアレベルではなくコアコンテナレベルで呼び出す方法
これは、各Solrコア内のインデックス作成がシングルスレッドで行われていることを意味します。 インデックス作成の速度を向上させるには、複数のスレッドやプロセスを使用して複数のインデックスで並列にインデックスを作成する方法があります。 Solrにデータを送信するプロセス/スレッドの数を増やすときにSolrサーバーで利用可能なCPUパワーを増やすことができれば、その助けになるかもしれません。
よろしくお願いします。
Shawn
- Shawnの言うように、各コアごとにマルチスレッド化してみてください。たとえば、2、3、4スレッドなどを試してみてください。
- 異なるバッチサイズで実験してみてください。たとえば、500と2000を試してみてください。最適なバッチサイズはドキュメントに依存します。
- 1000ドキュメントごとにコミットしないでください。代わりに、要件が許す限りまれにコミットしてみてください。たとえば、commitWithin=60000 を試して、1分ごとにコミットするようにします。
ヒント：SolrのメトリクスをDataDogなどのサービスにプッシュして、リクエスト数/秒、RAM、CPU、スレッド、GCなどの統計が表示されるダッシュボードを確認して、最後の質問に回答できるかもしれません。
Jan
必要に応じて、たとえば commitWithin=60000 を試して、1分ごとにコミットするようにします。
これが重要です。全プロセスが完了した後か、タイマーでコミットする場合、NRT（Real-Time Search）検索が必要ない限り、ほとんどの場合は誰もがそれを必要としないでしょう。コミットは負荷の大きな操作であり、1000ドキュメントをコミットする場合と100,000ドキュメントをコミットする場合とでほぼ同じ時間がかかります。
トピックに関する追加情報です。
- Solrの設定を確認しましたが、かなりデフォルトの設定のようです（特にマージ、コミット戦略など）。
- コミットは10分ごとに行っています。
- SolrインスタンスにNewRelicを追加して、より多くのデータとグラフを収集しています。
最終的に私たちの目に留まったのは、Solrが過負荷のときに実行中のスレッドのスタックにあるいくつかの deleteByQuery 行です。一時的に deleteByQuery を削除すると、インデックス作成の速度が約10倍向上しました。
私たちはどのように deleteByQuery を使用していますか？
update(add=[{uid: foo-123, sku: 123, ...}, {uid: bar-124, sku: 124} ...],
deleteByQuery=["sku: 123 AND uid != foo-123", "sku: 123 AND uid != bar-124"])
UIDはインデックスのuniqueKeyです。"foo"または"bar"が変更された場合、以前のドキュメントを残したくないため、このようにしています。
理想的には、この場合、uniqueKeyを sku に変更すれば deleteByQuery は不要になりますが、deleteByQueryがどのようにしてパフォーマンスボトルネックを引き起こすのか、また、それを最適化する方法について興味深い点があるかもしれません。
Marius
こんにちは、Mariusさん、もしそう理解しているのであれば、各ドキュメントに対して deleteByQuery を行っているのですね。正しいでしょうか？
--
Vincenzo D'Amore
興味深い発見ですね。以前にも非常に遅い deleteByQuery の報告を見たことがあります。そのため、deleteByQuery は節度を持って使用し、更新ごとに複数の deleteByQuery リクエストを Solr に投げることは決して避けるべきです。
SKUのような本当にユニークなIDに切り替えるのは良いアイデアのようです。または、以前のIDを知っている場合は、delete-by-id を使用する方がはるかに高速です。deleteByQuery を使わざるを得ない場合でも、複数の deleteByQuery リクエストを1つにまとめることが効率的でしょう。つまり、(("sku: 123 AND uid != foo-123") OR ("sku: 124 AND uid != bar-124")...) のように一つのクエリにまとめることを試し、小さな個別のリクエストではなく、100件ずつまとめてバッチ処理することも検討してみてください。
Jan
私はすべての低レベルの相互作用を理解しているわけではありませんが、deleteByQuery がいくつかの深刻な問題を引き起こすことを目にしています。deleteByQuery は、実際に削除操作を行う前にLuceneが完了を待機するブロッキング状態を作り出すようです。そして、削除操作の後に送信されたすべての操作もその削除操作の完了を待機します。次のような状況を想像してみてください：
1) 進行中のインデックス作成がセグメントのマージを開始し、そのマージには15分かかります。
2) deleteByQuery が送信されます。
3) さらにインデックスの変更が送信されます。
この場合、ステップ2はマージの完了を待機し、ステップ3はステップ2の完了を待機します。自動的なセグメントのマージには15分以上かかることがよくあります。
ステップ2がIDをクエリして deleteById を使用するように変更すると、ステップ2とステップ3はマージと並行して実行されます。
私のインデックス作成プロセスが長時間停止する原因を解明するのにかなりの頭を悩ませました。
よろしくお願いします。
Shawn
SKUを主キーとして使用していない理由は何ですか？ 同じSKUの複数のバージョンを必要とする必要がありますか？
私の理解では、SKUを主キーとして使用できれば、ほとんどの deleteByQuery は不要です。
--
Vincenzo D'Amore
その件には技術的な理由があるかもしれないと思います。それを解明する必要があります。また、それはそれほど単純ではありません。たとえば、uniqueKey は実際には2つのIDの組み合わせで構成されており、それらの間の関係はグルーピングの目的で重要です。
しかし、SKUに切り替えることに賛成ですね。それは理にかなっていると思います。
トピックへ返信するには、ログインが必要です。