Solr 9.1 のパフォーマンス
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/ysdcrvsbxggkb32nfq701h3cjg1xg0m2 into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは、
現在、Windows上で動作しているSolr 5.4.1のクラウド設定を使用しています。
このクラウドには4,500万件のレコードが含まれており、12個のシャードに分割され、レプリケーションファクターは2です。12個のシャードは、4つのノードを実行する6つのサーバーにホストされています。3つのサーバーは1つのデータセンターに、もう3つのサーバーは別のデータセンターに配置されているため、高可用性とサイト冗長性を実現しています。
この設定は非常にうまく機能しており、毎分数百件のクエリに対応し、1日に2万件の新しいドキュメントのフィードと更新を簡単に処理できますが、古い機器で動作しています。
新しいサーバーと同じトポロジーと設定を使用して、Solr 9.1（Eclipse Adoptium OpenJDK 17.0.4）を使用して新しいクラウドを構築しましたが、ノードでの最初のいくつかのクエリが非常に悪いことがわかりました。全体的なP95時間は6〜8Kミリ秒です。最初の数クエリが新しいインデクサーをスピンアップするような感じで、メモリに定着すると（またはスピンアップすると）、クエリは<10msで返されますが、90秒間アイドル状態にすると再び遅いクエリが発生します。場合によっては、管理UIパネルもアイドル状態でクエリが遅くなることがあります。ブラウザの開発ツールを使用すると、最初のクエリのページ時間が、すでに高いクエリ/経過時間よりも長いことがわかります。
クエリの性質上、キャッシュの自動ウォーミングは行っていません。ガベージコレクションは1200MBの割り当てで問題なく動作しています。クイックかつ頻繁ではなく、通常1200MBの割り当ての70％に達する前にクリーンアップされます。
インデックス作成がアクティブでない場合でも同じ動作が見られるため、それを除外できます。以前、同じ問題が発生していたバージョン9でクラウドを構築しました。
クラウドにリクエストを常にスパムすることでクエリを高速に保つことはできますが、5.4 Solrクラウドでは常にアクティビティがあるため、アイドル期間を比較することはできません。
おそらく、これが本番環境で使用されるとアクティビティがクラウドを常にアクティブに保つでしょうが、クラウドを常にアクティブに保つために他に見るべきものはありますか？
よろしくお願いします。
関連している可能性がありますか？ こちらのJava 17バグについての情報です。キャッシュをあまり使用しないため疑わしいですが、9.1ではデフォルトでキャッシュのホットスポット最適化が無効になっています。bin/solrスクリプトを編集してこのパッチを無効にして、何かが速くなるか試してみることができますが、その代わりにセグフォルトクラッシュのリスクがあります :)
Jan
いいえ、9.1にはデフォルトでそのパッチは含まれていません。それを追加してみましたが、違いはありませんでした。
「distrib=false」でクエリを実行するテストを行ったところ、クエリ自体は問題なく実行されているのに、インスタンスへの呼び出しと応答が遅いことがわかりました。
Jettyに関係しているのでしょうか？
私が言いたいのは、9.1にはキャッシュ問題に対するワークアラウンドが含まれているということです。詳しくはこちらをご覧ください。パフォーマンスの向上を試みるために、このワークアラウンドを無効にしてみることをお勧めします。あるいは、JDK11を使用してみるのも良いでしょう。JDK11ではこのワークアラウンドがトリガーされません。
ただし、これはあくまで推測です。問題は他の原因による可能性もあり、セットアップや設定、物理メモリ、ヒープなどの詳細がもっと必要です。
同じサーバー上で4つのSolrノードを実行するという決定についても疑問があります。代わりに、各サーバーに1つのSolrプロセスを実行し、12個のシャードと2つのレプリカを保持する方法を試してみましたか？アフィニティ配置プラグインを有効にし、各ノードにデータセンターIDとホスト名をタグ付けすれば、Solrはすべての6つのサーバーにシャード/レプリカを均等に配置します。
最後に、クラスタに対する監視機能を追加して、実際に何が起こっているのかを把握しましょう。例えば、Datadogや他のクラウドプロバイダーを使用すると、すぐに始めることができます。これにより、クラスタで何が起こっているのかを発見するのに役立ちます。
PS: すべてのアンチウイルスソフトウェアを無効にしましたか？ヒープサイズをできるだけ小さくしましたか？システムがスワップしていないことを確認しましたか？
Jan
ワークアラウンドをテストしましたが、ありなしで違いはありませんでした。新しいクラウドセットアップは各インスタンスに1200MBのヒープ、各サーバーに32GBのシステムRAMを持っています。システムキャッシュに20GB以上が使われているのが見えます。アンチウイルスの除外設定を適用しており、システムが不必要にスワップしている様子はありません。
一つ気づいたことは、レプリカなしで実行すると経過クエリ時間がしばしば良くなることです。2分以上活動がない状態でのランダムアクセスでの遅い起動がまだ見られます。
クラウドは設計アーキテクトによって設計されたもので、Solr 5.4.1では完全に正常に動作していました。これは24/7で使用されているため、アイドル状態の時のテストができません。当時、各サーバーに4つのノードを配置する設計は、各マシンに割り当てられた4つのCPUを活用するためだったと思われます。このセットアップは各サーバーに16GBのシステムRAMを持ち、新しいクラウドの半分です。
機密情報を含むため、私たち自身のデータセンターにホストしており、datadoghqを利用することはできません。
1.2GBのヒープは、数百万のドキュメントを扱うには非常に小さいと感じます。各ノードが1つのシャードを処理するだけでもです。GCログが何を示しているのか興味があります。
もしSolrがシングルスレッドのアプリケーションであれば、これは理解できます。しかし、Solrは多くのスレッドを使うため、マルチCPUシステムをフルに活用するために複数のノードを1つのマシンに配置する必要はありません。複数のノードを持つことで、各ノードが他のノードの状況を把握できないため、CPUリソースを奪い合うスレッドが多すぎる問題が発生しやすくなります。
ありがとうございます。
Shawn
以下は、私の小規模なSolrインストールに接続されたjconsoleセッションのスクリーンショットです。「小規模」とは、20万以上のドキュメントと700MBのインデックスサイズを持ち、ヒープサイズが1GBのことです。512MBのヒープでも動作しますが、Javaが動作するための余裕を持たせるために1GBにしています。これは、クラウドモードのシングルSolrノードで、埋め込み型のZKを使用しています：
グラフのスパイクは、完全な再インデックスを開始したときのものです。
私は、スタンドアロンモードで1000スレッド以上を持つ忙しいSolrインストールを見たことがあります。SolrCloudは、スタンドアロンモードにはないスレッドも持っています。単一のSolrノードでも、利用可能なCPUリソースをすべて使用することに問題はありません。
ありがとうございます。
Shawn
トピックへ返信するには、ログインが必要です。