SolrコレクションのDirectoryFactoryの変更
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/oxmfzyrnwn1n6bn6wyvwo8zzz2q529tf into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは、皆さん
使用環境: Solr 8.11.2 with RHEL9
現在、「solr.NRTCachingDirectoryFactory」をコレクションに使用していますが、コレクションのサイズが大きくなってきました。とはいえ、マシン（AWS）にRAMを追加したくありません。データボリュームのIOPSとスループットは増やせます。
「solr.NIOFSDirectoryFactory」を使用することを考えていますが、それが既存のコレクションにどのような影響を与えるのか知りたいです。単にインデックスファイルを読み取る方法の一つかもしれませんが、確かに既存のインデックス化されたデータに影響がないかを確認したいです。
この点についての情報をいただけると助かります。
よろしくお願いします。
Jayesh Shende
ディレクトリファクトリーを明示的に設定するのは、一般的には良い考えではありません。非常に特殊な状況でのみ行うべきです。おそらく、あなたの状況はそれに該当しません。
その設定を削除し、Solr/Luceneに環境に最適なクラスを選ばせてください。おそらく、NRTCachingDirectoryFactoryが選ばれるでしょう。新しいSolrバージョンでより良いオプションが利用可能になった場合、値が明示的に設定されていなければ、自動的にそのオプションが選ばれる可能性が高いです。
ソースコードを見る限りでは、NOIFSがmmapを使用するかどうかは確信が持てませんが、おそらく使用していないと思われます。ほとんどのケースでは、mmapを使用するディレクトリ実装が望ましく、NRTCaching実装がそれを行っています。
ディレクトリファクトリーを変更しても、既存のインデックスに問題が発生する可能性は非常に低いです。しかし、なぜそれを変更したいのかが気になります。どのような問題に直面し、なぜ非デフォルトクラスを選ぶべきだと考えたのですか？
十分なメモリがインストールされていれば、ディスク速度はパフォーマンスにほとんど影響しません。ディスクパフォーマンスが重要になるのは、効果的なディスクキャッシュを行うための余分なメモリが不足している状況だけです。メモリはディスクよりも高速であり、たとえディスクが非常に高速なSSDであってもです。
mmapを使用するディレクトリ実装が最速のオプションです。
よろしくお願いします、
Shawn
こんにちは、Shawn
迅速な対応ありがとうございます。
サーバーボックスは複数のSolrノードによって共有されており、各ノードは100GB以上のディスクを使用しています（1つのSolr上に異なるコレクションの2～4つのレプリカがあります）。
NRTCachingDirectoryFactoryはできるだけ多くのセグメントをメモリにキャッシュしようとしますが、クエリは異なるコレクションに対して行われ、繰り返しの少ないクエリ用語が使用されているため、これらのキャッシュされたセグメントが実際にはあまり役立っていないように思います。また、各Solrノードが稼働している状態で、JVMに割り当てられているRAM以外のメモリは、インデックスの10%さえキャッシュできるほど十分ではありません。
また、既存のSolrでパフォーマンスを改善しようとしており、JavaではNIOがIOよりも優れていることを知っているため、ディスクのIOPSとスループットを増やすことができれば、どのような影響があるかを確認したいと考えています。
何かを変更する前に、directoryFactoryの明示的な設定を削除して、OSに最適なものをどのように選択するかを確認してみます。これがコレクションの基礎となるインデックスデータに影響を与えることはないはずです。
ありがとうございます。
Jayesh Shende
私も似たような状況にあり、インデックスがノードのRAMに対して非常に大きすぎました。デフォルトのディレクトリリーダー（NRTCaching）が、リクエストごとにインデックスの異なる部分をメモリにキャッシュしようとしていたため、ディスクの読み取りが常に100%になり、クエリのタイムアウトやノードのダウンが発生していましたが、クエリはほとんど同じコレクションに対して行われることはありませんでした。私たちのディスクは1秒間に1GBの読み取りができましたが、単純なクエリでも数件のドキュメントを返すのに40秒間の連続した読み取りが必要でした。時折、Solrは以前のリクエストのディスク読み取りを完了するまで完全に応答しなくなりました。
私はNIOFSリーダーに切り替え、ディスクの問題が解決しました。ただし、小さなインデックスがRAMに収まる場合のような超高速なSolrを期待しないでください。
-ufuk
Solrはインデックスファイルからデータを積極的にキャッシュすることはありません。それはオペレーティングシステムに任せられています。
特定のデータがアクセスされなければ、それはキャッシュされることはありません。これは、Solrが生成および維持するオンヒープキャッシュにも当てはまります。アクセスされないデータはキャッシュされません。
リソースが適切にサイズ調整されている場合、MMAPはどのオペレーティングシステムでも最も効率的なファイルデータへのアクセス手段です。
Solrのパフォーマンスを向上させる最良の方法は、メモリを追加することです。ただし、クラウドベースのセットアップでは、それが非常に高価になる場合があります。
他の回答から、メモリ不足の環境ではディレクトリ実装を変更することでパフォーマンスが向上する可能性があることがわかりました。しかし、次の予測をお伝えします。メモリが十分でない状態で運用を続けると、最終的にはメモリを追加しないと解決できないパフォーマンスの壁にぶつかることになります。
よろしくお願いします。
Shawn
トピックへ返信するには、ログインが必要です。