総セグメント数を減らす方法は、以前はmergeFactorによって制御されていた閾値を減らすことです。総数の最大値を明示的に設定する方法は知りませんが、各層の数が総数に影響します。ほとんどのSolrインストールには少なくとも3つのマージングティアがありますので、最大総セグメント数は少なくとも各層の設定の3倍になります。

以下の設定は、Solrのマージポリシーのデフォルトを表しています：

<mergePolicyFactory class="org.apache.solr.index.TieredMergePolicyFactory">
  <int name="maxMergeAtOnce">10</int>
  <int name="segmentsPerTier">10</int>
</mergePolicyFactory>

私が以前管理していたいくつかのSolrサーバーでは、これらの数値が35に設定されていました。総セグメント数が100を超えることはよくありましたが、これはパフォーマンスに大きな影響を与えませんでした。

もし重大なパフォーマンスの問題が発生している場合、セグメント数とは関係ない可能性のある2つの問題のどちらかです：

1) 最大ヒープサイズが十分に大きくなく、増やす必要があります。これにより、Javaがアプリケーションを実行するよりもGCを行う時間が長くなり、深刻なGCの停止が発生する可能性があります。

2) インデックスが非常に大きいため、サーバーの空きメモリ量では効果的にキャッシュできません。これを修正するには、物理メモリを追加して、オペレーティングシステムにより多くの未割り当てメモリが利用可能になるようにします。Solrは、パフォーマンスに対する有効なインデックスキャッシュに絶対的に依存しています。

補足情報として、数百万のドキュメントをインデックス化する際に問題が発生する可能性があるのは、マージングが重くなるとインデックス化スレッドが一時停止することです。上記の構成で数字を減らすと、この問題がより頻繁に発生する可能性があります。これを修正するには、mergeSchedulerの構成を調整します。

<mergeScheduler class="org.apache.lucene.index.ConcurrentMergeScheduler">
  <int name="maxMergeCount">6</int>
  <int name="maxThreadCount">1</int>
</mergeScheduler>

いくつかの注意点: maxMergeCountは少なくとも6にしてください。インデックスがスピニングハードディスクにある場合、maxThreadCountを1にしてください。インデックスがSSDにある場合、スレッド数を増やすことができますが、無闇に増やさないでください。おそらく最大で3または4、より多い場合でも2を選択する傾向があります。SSDにインデックスがある場合は経験がないため、何スレッドが過剰なのかを知りません。

ありがとうございます、
Shawn