シャーディング戦略のアドバイス
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/rzjqtq74y9nvct865mwlnzbc2zfrk4mp into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは、
私はいくつかのSolrノードに分散されたシャードコレクションを持っています。各Solrノードは1つのシャードをホストし、もう1つのシャードのレプリカを1つ持っています。シャードは非常に大きく（1億件のドキュメント）、クエリは複数のfilterQueryを使用しています。この件数のドキュメントでは、filterCacheが大量のヒープメモリを使用する可能性があります。
シャードを2つまたは4つに分割して、それぞれのシャードを5000万ドキュメントまたは2500万ドキュメントにするのは良いアイデアでしょうか？4つに分割する場合、1つのSolrノードは2つのレプリカではなく8つのレプリカをホストしますが、それぞれのレプリカのfilterCacheは小さくなります。
検索性能が向上することは期待していませんが、ウォーミングの速度が向上し、特にソフトコミット時のオープンサーチャーによるヒープメモリの負荷が軽減されることを期待しています。たとえば、1分ごとに一度大きなfilterCacheをウォーミングアップする代わりに、4つの小さなfilterCacheが同時ではなくウォーミングアップされるでしょう（うまくいけば）。
したがって、同じSolrノードでシャードを分割しますか？
よろしくお願いします、
Dominique
用語の微調整：各ノードは異なるシャードの2つのレプリカをホストしています。
「1つのシャードと1つのレプリカ」という表現ではなく、「シャードNの2つのレプリカ」です。
1つのレプリカがリーダーになりますが、それは可変の一時的な区別です。
NRTまたはTLOGレプリカはどちらもリーダーになれます。
filterCacheに必要な総ヒープメモリ量はこれによって減少しません。また、他のコアごとのメモリ構造も、より多くの総ヒープメモリが必要です。
もしCPUのキャパシティが非常に大きく、クエリ率が比較的低い場合、Solrインスタンスあたりのシャード数を増やすことでクエリパフォーマンスが向上する可能性があります。しかし、クエリ率が高いか、CPUコア数が少ない場合は、少ないシャードの方が良いでしょう。
システムの容量が十分であれば、複数の小さなキャッシュが同時にウォーミングアップされることで、わずかに早くなるかもしれません。ただし、8つの小さなインデックスを実行すると、2つの大きなインデックスよりもヒープ要件が減少すると考えているようですが、それは事実ではありません。実際にはヒープ要件が増加し、Luceneが各インデックスをビルドする効率により、ディスクのスペース要件も増加します。これらがどれだけ増加するかについての具体的な情報はありません。
Solrのインデックスパフォーマンスを向上させる最良の方法は、複数のスレッド/プロセスを使用することです。一般的なSolrパフォーマンスを向上させる最良の方法は、ディスクキャッシュ用の多くの余分なメモリを確保することです。これは、各サーバーのインデックスが小さくなり、ディスクキャッシュによりよく適合するため、サーバー数とシャード数を大幅に増やすことを意味する場合があります。
少なくとも1台のマシンあたり複数のSolrインスタンスを実行することについては触れていないようで良かったです。これは本当に大規模なインストールの場合にのみ意味をなします。あなたのシステムは小規模ではありませんが、1つのシャードのレプリカだけを数えると、数十億のドキュメントとテラバイトのインデックスデータを持っている人たちからの情報を聞いています。現時点では、Solrはヒープを32GB以下に保つことでメモリ効率が向上します。したがって、本当に大規模なシステムの場合、各31GBヒープを持つ2つのSolrインスタンスは、64GBヒープを持つ1つのインスタンスよりもSolrに利用可能なメモリが多くなります。
ありがとうございます。
Shawn
こんにちは Shawn,
説明とアドバイスをありがとうございます。
シャードとレプリカに関して使用した誤った用語に同意します。
ヒープメモリ使用量とスレッド数の一時的なスパイクを理解して修正しようとしています。
問題が発生すると、ヒープダンプにはフィルターキャッシュを構築する多くのスレッドが表示されます。各スレッドが多くのヒープメモリを消費しています。
その結果、ヒープが完全には満杯でなくても、連続したフルGCが発生します。
SolrのログファイルにはCdcr関連のメッセージも見られ、同じレプリカで数秒間隔で同時に検索者が開かれているのが分かります。
これらの検索者が、autosoftcommit maxtimeが60000で、autocommit maxtimeが300000で、opensearcherがfalseに設定されている同じ秒に開かれている理由が分かりません。
solr.log.18:394492:2022-11-23 14:45:37.134 INFO (zkCallback-5-thread-128)
[ ] o.a.s.h.CdcrLeaderStateManager Received new leader state @ SSSS:shard1
solr.log.18:418525:2022-11-23 14:45:48.533 INFO (Thread-2218) [c:SSSS s:shard1 r:core_node90 x:SSSS_shard1_replica_t89] o.a.s.s.SolrIndexSearcher
Opening [Searcher@39764e3a[SSSS_shard1_replica_t89] main]
solr.log.18:418626:2022-11-23 14:45:49.535 INFO (Thread-2218) [c:SSSS s:shard1 r:core_node90 x:SSSS_shard1_replica_t89] o.a.s.s.SolrIndexSearcher
Opening [Searcher@3dd70403[SSSS_shard1_replica_t89] main]
solr.log.18:418667:2022-11-23 14:45:50.090 INFO
(recoveryExecutor-4-thread-13-processing-n:no2fyy27.noe.edf.fr:8984_solr
x:SSSS_shard1_replica_t89 c:SSSS s:shard1 r:core_node90) [c:SSSS s:shard1 r:core_node90 x:SSSS_shard1_replica_t89] o.a.s.s.SolrIndexSearcher Opening
[Searcher@4a51a759[SSSS_shard1_replica_t89] main]
solr.log.18:418682:2022-11-23 14:45:50.153 INFO
(recoveryExecutor-4-thread-13-processing-n:no2fyy27.noe.edf.fr:8984_solr
x:SSSS_shard1_replica_t89 c:SSSS s:shard1 r:core_node90) [c:SSSS s:shard1 r:core_node90 x:SSSS_shard1_replica_t89] o.a.s.h.CdcrRequestHandler Solr
core is being closed - shutting down CDCR handler @ SSSS:shard1
または
solr.log.18:454048:2022-11-23 14:59:21.351 INFO (Thread-2668) [c:SSSS s:shard1 r:core_node90 x:SSSS_shard1_replica_t89] o.a.s.s.SolrIndexSearcher
Opening [Searcher@273ebecf[SSSS_shard1_replica_t89] main]
solr.log.18:454403:2022-11-23 14:59:21.993 INFO (Thread-2668) [c:SSSS s:shard1 r:core_node90 x:SSSS_shard1_replica_t89] o.a.s.s.SolrIndexSearcher
Opening [Searcher@711992c5[SSSS_shard1_replica_t89] main]
solr.log.18:454484:2022-11-23 14:59:22.588 INFO
(recoveryExecutor-4-thread-17-processing-n:no2fyy27.noe.edf.fr:8984_solr
x:SSSS_shard1_replica_t89 c:SSSS s:shard1 r:core_node90) [c:SSSS s:shard1 r:core_node90 x:SSSS_shard1_replica_t89] o.a.s.s.SolrIndexSearcher Opening
[Searcher@5258502d[SSSS_shard1_replica_t89] main]
solr.log.18:454502:2022-11-23 14:59:22.609 INFO
(recoveryExecutor-4-thread-17-processing-n:no2fyy27.noe.edf.fr:8984_solr
x:SSSS_shard1_replica_t89 c:SSSS s:shard1 r:core_node90) [c:SSSS s:shard1 r:core_node90 x:SSSS_shard1_replica_t89] o.a.s.h.CdcrRequestHandler Solr
core is being closed - shutting down CDCR handler @ SSSS:shard1
最後に、1サーバーあたり2つのSolrインスタンスがあります。
アーキテクチャは以下の通りです：
- 7台のサーバー（96GB RAM / 12 CPU）
- 14個のSolrインスタンス（24GB Heap）
巨大なコレクションがシャーディングされており、14シャード×2レプリカ全てTLOGです。
ドキュメントの総数：15億（1シャードあたり1億ドキュメント）
よろしくお願いします。
Dominique
CDCRのことについては全く分かりません。使用したことがありません。Solrから削除されたと信じています…少なくとも非推奨になったことは知っていますが、それがどのバージョンで行われたかはわかりません。以下のTLOGレプリカに関するメモがここにも適用される可能性があると思います。
これはTLOGレプリカです。つまり、シャードのリーダーレプリカでない限り、非常に異なる動作をします。PULLレプリカと同様に振る舞いますが、インデックスのレプリケーションに加えてトランザクションログもレプリケーションします。
TLOGフォロワーまたはPULLレプリカは、リーダーとは非常に異なる方法でコミットを行います。これらのコミットは、リーダーから新しいインデックスセグメントがコピーされることに関連しています。リーダーでは、コミットが発生する前に多くの新しいセグメントがインデックス化によって作成されることがあります。
リアルタイムサーチャーの作成に関するメモが見られる場合、それはコミットによって開かれる種類のサーチャーとは非常に異なります。これは/getハンドラによって使用され、まだコミットされていないレコードにアクセスするためのものです。リアルタイムサーチャーはウォーミングを行わないため、非常に迅速に開かれます。
よろしくお願いします。
Shawn
トピックへ返信するには、ログインが必要です。