インデックス作成のパフォーマンスの構成と調整

インデックス作成のスループットを最大限に高めるようにDSE Searchを構成し、調整します。

DSE Searchは、メモリー不足を回避し安定したパフォーマンスを維持するため、バック・プレッシャー・メカニズムによるマルチスレッドの非同期インデックス作成機能を備えています。マルチスレッドのインデックス作成により、複数のCPUコアを持つマシンのパフォーマンスが向上します。IndexPoolMBeanを使用することで、運用上の可視性が得られ、JMXを使用した調整が可能です。

DSE Searchには、以下の2つのインデックス作成モードがあります。
  • ニア・リアルタイム(NRT)インデックス作成は、Apache Solr™とApache Lucene®のデフォルトのインデックス作成モードです。
  • ライブ・インデックス作成はリアルタイム(RT)インデックス作成とも呼ばれ、Lucene RAMバッファーに対する直接検索をサポートしており、より頻繁で安価なソフト・コミットが可能であり、新たにインデックスが作成されたデータをすばやく認識できるようになります。ただし、RTインデックス作成では、他の同等のNRT設定よりも大きいRAMバッファーとメモリー使用量が必要になります。
このページに含まれる内容:

使用しているCPUの数

調整する前に、使用している物理CPUの数を特定してください。JVMはCPUがハイパースレッディングを使用しているかどうかを認識しません。

DSE 5.1.0における調整

デフォルトのmergeScheduler設定は、自動的に設定されます。この設定は調整しないでください。Luceneマージ・スケジュールを使用し、並列処理が行われないと、0スループットの期間が発生する可能性があります。

dse.yaml

  • まず、コアごとにインデックス作成スレッド・プールのサイズを利用可能な物理CPU数に設定します。
    max_solr_concurrency_per_core: min(2, num physical non-HT CPU cores / num actively indexing Solr cores) 
    注: max_solr_concurrency_per_coreを1に設定すると、DSE Searchは従来の同期インデックス作成実装を使用します。
  • 次に、バック・プレッシャーをアクティブ化する前のキューの最大深さを設定します。1ワーカーあたり1000回の更新が目安となります。back_pressure_threshold_per_core optionは、オプションでバック・プレッシャーをアクティブ化する前のSolrコアごとのバッファー済み非同期インデックス更新の数を定義します。DataStaxでは、back_pressure_threshold_per_coreの値をmax_solr_concurrency_per_coreの1000倍にすることを推奨しています。デフォルトは2000です。
    back_pressure_threshold_per_core: 1000 * max_solr_concurrency_per_core

solrconfig.xml

コアごとの最大同時実行数をマージ・スケジューラーに適用します。
  • maxThreadCount - Luceneマージ・スレッドの最大数
  • maxMergeCount - Luceneが受信するインデックス作成ワーカーを抑制する前の未処理のマージの数。maxMergeCountが小さすぎる場合、インデックス作成スループットがゼロの期間が発生します。
<indexConfig>
    ...
    <mergeScheduler class="org.apache.lucene.index.ConcurrentMergeScheduler">
        <int name="maxThreadCount">your max_solr_concurrency_per_core</int>
        <int name="maxMergeCount">your max_solr_concurrency_per_core * 2</int>
    </mergeScheduler>
    ...
</indexConfig>
Solrデータ・ディレクトリーが回転式ディスクにマウントされている場合、以下を使用します。
<indexConfig>
    ...
    <mergeScheduler class="org.apache.lucene.index.ConcurrentMergeScheduler">
        <int name="maxThreadCount">1</int>
        <int name="maxMergeCount">6</int>
    </mergeScheduler>
    ...
</indexConfig>

DSE 5.1.1以降における調整

dse.yamlと検索インデックス構成の設定は、単一のアクティブなSolrコアを持つノードで最適になるように自動的に調整されます。この自動調整は、自動生成によるコアの作成時に特に役立ちます。

自動的に調整されますが、以下の点を考慮してください。
  • たとえばDSE Graphなどで複数のSolrコアが動作している場合、これらのコアに割り当てられるリソースを削減するのは適切な処置です。ただし、すべてのパラメーターを再構成するのではなく、max_solr_concurrency_per_coreのみを変更してください。その他の調整オプションはすべて、明示的に指定されている場合を除き、再起動時に適切に変更されます。
  • 自動調整で使用されるコアごとのスレッドの数は最大で2であり、proc/cpuinfoによってそれ以上のスレッド数がログに報告されてもこの値は変わりません。例を次に示します。
    /proc/cpuinfo is reporting 8 threads per CPU core, but DSE will assume a value of 2 for auto-tuning...
  • SolrコアのLuceneインデックス・ファイルが回転式ハード・ディスクに存在する場合、solrconfigのmaxThreadCountのデフォルトは1、maxMergeCountのデフォルトは6です。
  • オプションが指定されていない場合に限り、自動調整が行われます。デフォルトが自動調整されても、それらの設定はあくまでもデフォルトであり、dse.yaml(全体)とsolrconfig.xml(コアごと)で手動で指定されたオプションがオーバーライドされることは絶対にありません。

NRTのインデックス再作成の調整

NRTに限り、手動でインデックスを再作成した際にNRTスループットを最大限に高めるにはsolrconfig.xmlファイルの設定を調整します。
  • RAMバッファーのサイズを増やします。デフォルトでは512 MBですが、たとえば1000に設定します。
    <indexConfig>
      <useCompoundFile>false</useCompoundFile>
      <ramBufferSizeMB>1000</ramBufferSizeMB>
      <mergeFactor>10</mergeFactor>
    . . .
    RAMバッファーは、NRTのコミットされていないドキュメントを保持します。RAMバッファーが大きいほど、フラッシュが低減されます。フラッシュが発生すると、セグメントも大きくなります。フラッシュが少ないとI/O負荷を抑えることができるため、書き込みワークロードが大きいシナリオでは理想的です。
  • ソフト・コミット時間を延長します。デフォルトでは1000 msに設定されていますが、より大きい値にします。たとえば、時間を10秒に延長します。
    <autoSoftCommit>
      <maxTime>10000</maxTime>
    </autoSoftCommit>
autoSoftCommit属性を変更することのマイナス面は、新たに更新された行が検索結果に表示されるようになるまでの時間が通常(1000 ms)より長くなることです。

RTのインデックス作成の調整

ライブ・インデックス作成はメモリー使用量が増えますが、ドキュメントが検索可能になるまでの時間が短縮されます。クラスターごとに1つの検索インデックスでのみライブ・インデックス作成を有効にしてください。
  1. ライブ・インデックス作成(RTとも呼ばれる)を有効にするには、solrconfig.xmlファイルの<indexConfig>属性に<rt>true</rt>を追加します。
    <rt>true</rt>
  2. ライブ・インデックス作成を構成するには、solrconfig.xmlファイルを編集し、以下の設定を変更します。
    • autoSoftCommit/maxTimeを1000 ms(1秒)に設定します。

      ライブ・インデックス作成のautoSoftCommit.maxTimeはソフト・コミットではなく、この値が更新間隔を制御します。ライブ・インデックス作成(RT)の場合、この更新間隔の上限は1000 msです。これより大きい値はすべてオーバーライドされ、最大時間は1000 msに制限されます。

    • ライブ・インデックス作成をRAMバッファーで行うと、ニア・リアルタイム・インデックス作成よりも多くのメモリーを使用します。RAMバッファー・サイズを設定します。RTの場合の開始点としては、2048 MBが目安となります。
      <ramBufferSizeMB>2048</ramBufferSizeMB>
    • ライブ・インデックス作成を高速化するには、RAMバッファーの送信部分がオフヒープに割り当てられるように構成します。
      <rtOffheapPostings>true</rtOffheapPostings>
      送信をオフヒープに割り当てることで、ガーベージ・コレクション(GC)時間が向上し、ライブ・インデックス作成のメモリー使用量の変動に伴うメモリー不足エラーを回避できます。
      <indexConfig>
          ...
          <rt>true</rt>
          <ramBufferSizeMB>2048</ramBufferSizeMB>
          <rtOffheapPostings>true</rtOffheapPostings>
         ...
      </indexConfig>
      ...
      <updateHandler class="solr.DirectUpdateHandler2">
      ...
          <autoSoftCommit>
              <maxTime>1000</maxTime>
          </autoSoftCommit>
      ...
      </updateHandler>
  3. ヒープ・サイズを14 GB以上に増やします。
  4. ヒープ・サイズを大きくしてライブ・インデックス作成を行うには、DataStax Enterpriseを再起動します。
dse.yamlファイルの場所は、インストールのタイプによって異なります。

パッケージ・インストールInstaller-Servicesインストール

/etc/dse/dse.yaml

tarボール・インストールInstaller-No Servicesインストール

installation_location/resources/dse/conf/dse.yaml