パフォーマンスと容量のチューニング (FAST Search Server 2010 for SharePoint)

[アーティクル]
03/04/2017

適用先: FAST Search Server 2010

トピックの最終更新日: 2011-02-04

ここでは、パフォーマンスと容量の高い目標を達成できるように Microsoft FAST Search Server 2010 for SharePoint ファームをチューニングするさまざまな方法について説明します。

クローラーの容量のチューニング
インデックスの容量のチューニング

警告

これらの方法を使用するのは、それぞれのチューニング方法の所定の条件を満たす場合に限ることをお勧めします。また、チューニングの前に、パフォーマンスと容量に関するその他の問題が展開内に残っていないことを確認します。詳細については、「パフォーマンスと容量の監視 (FAST Search Server 2010 for SharePoint)」を参照してください。

注意

この記事は、SharePoint Server 2010 クローラー、インデックスコネクタフレームワーク、および FAST Search Server 2010 for SharePoint Content Search Service アプリケーション (Content SSA) を使用してコンテンツをクロールすることを前提として書かれています。

クローラーの容量のチューニング

クローラーの容量のチューニングは、以下を満たす構成の場合にのみ行います。

バックアップインデクサー行がなく、Content SSA のクロールコンポーネントあたり 100 以上のアイテム処理コンポーネントインスタンスが展開されている場合
バックアップインデクサー行があり、Content SSA のクロールコンポーネントあたり 50 以上のアイテム処理コンポーネントインスタンスが展開されている場合
Content SSA のクロールコンポーネントあたり 3 以上のインデックス列がある場合

大規模な構成の場合、ネットワークのボトルネックを回避するために、Content SSA 内のクロールコンポーネント数を拡張する必要があります。この拡張を行えば、通常、構成をさらにチューニングする必要はなくなります。しかし、バックアップインデクサー行を使用する構成の場合は、Content SSA が渡すバッチは、アイテム処理コンポーネントの数を上回る傾向があります。この "余り" のバッチは、処理されていながらどちらのインデクサー行にも書き込まれていないコンテンツです。既定では Content SSA は、渡すバッチの数が 100 を超えないようにクロールをスロットルします。大規模な構成の場合は、このスロットル値を調整して、より多くのバッチを同時に処理できるようにすることを検討する必要があります。

スロットル制限は、MaxSubmittedBatches プロパティおよび MaxSubmittedPUDocs プロパティで調整できます。既定値は、MaxSubmittedBatches は 100、MaxSubmittedPUDocs は 1000 です。スロットル制限は Content SSA 内の各クロールコンポーネントに適用されます。2 つのクロールコンポーネントを使用する場合、渡されるバッチの総数の最大値は、構成値の 2 倍となります。新しいスロットル制限を計算するには、次の数式を使用します。

クロール処理式のチューニング

たとえば、a=1、b=48、c=3、s=2 というシナリオの場合、MaxSubmittedBatches は 54、MaxSubmittedPUDocs は 5400 となります。この場合、MaxSubmittedBatches の変更はありません。ACL の変更が多いためにクロールとインデックス処理のパフォーマンスが向上しない場合、MaxSubmittedPUDocs (ACL の変更を含むアイテムの送信の最大値) を大きくすることができます。

MaxSubmittedBatches プロパティと MaxSubmittedPUDocs プロパティは、Content SSA をホストするファームの Microsoft SharePoint Server 2010 管理シェルで構成できます。次のコマンドでは、既定値に設定しています。

$ssa = Get-SPEnterpriseSearchServiceApplication -Identity <nameOfContent SSA> 
$ssa.ExtendedConnectorProperties["MaxSubmittedBatches"] = 100 
$ssa.ExtendedConnectorProperties["MaxSubmittedPUDocs"] = 1000 
$ssa.Update()

ここで、<nameOfContentSSA> は Content SSA の名前です。

注意

スロットル制限を大きくすると、アイテム処理コンポーネントとインデックス処理コンポーネントの負荷も増加します。これによってファームリソースの消費が増えると、クエリのパフォーマンスに影響が生じます。ただし、専用の検索行を使用していない場合は、これはあまり問題とはなりません。MaxSubmittedPUDocs を大きくすると、プライマリインデクサーとバックアップインデクサーの I/O 負荷が増加します。

インデックスの容量のチューニング

インデックスの容量のチューニングは、以下を満たす構成の場合にのみ行います。

更新の頻度が低いコンテンツが多くある場合
クエリのスループットの要件が低い場合 (1 秒あたり最大 5 ～ 10 クエリ、サーバーの CPU パフォーマンスにより変動)
インデックス処理の待機時間を短くする必要がない場合 (アイテムの更新から検索可能になるまでの間隔が長い)

FAST Search Server 2010 for SharePoint の既定の構成は、インデックス列あたり 1500 万アイテムを処理するように最適化されており、ハードリミットは 3000 万アイテムです。コンテンツの更新頻度が低く、クエリのボリュームが中程度というシナリオの場合には、ハードウェアコストを抑えるために、1 列あたりのインデックスアイテム数を増やすとよい場合があります。FAST Search Server 2010 for SharePoint のインデクサーの構成により、1 列あたり最大 4000 万アイテムを処理するように設定できます。これが、容量を拡張した構成です。コンテンツ容量を拡張した構成では、各サーバー内のインデックスパーティションが増加します。これによって、最大 QPS が減る代わりに、クエリの待機時間を短く維持できます。

容量を拡張すると、次のようなトレードオフがあります。クエリのスループット (QPS) が低下します。クエリ待機時間には (スループットの制約の範囲内で) それほど影響はありません。クエリのスループットの低下は、複数の検索行を使用することで補えますが、その場合、サーバー数の減少幅が少なくなります。インデックス処理に必要なリソースが増え、ディスクアクセスも増加します。列ごとのアイテム数が増えるため、サーバーあたりに必要な記憶容量も増加します。ファーム全体の総記憶容量はほぼ同じです。アイテム処理コンポーネントを分散できるサーバーが減少します。クロール速度は使用可能な CPU コア数によって主に決まるため、初期のクロール速度が低下します。各インデックス列の処理量が増えることから、増分クロールでもスループットが低下します。初期の運用前のバルククロールを一時的に高速化するには、最終的な検索行にアイテム処理コンポーネントを追加するか、または余分なサーバーを一時的にクラスターに割り当てることができます。サーバーあたりに必要なハードウェアリソースが増加します。1 スレッドあたりの CPU コア数が 16 未満のサーバーでは、拡張設定は使用しないことをお勧めします (24 以上を推奨)。48 GB RAM と高性能な記憶域サブシステムの使用をお勧めします。

注意

ファームが対応する必要がある変更率を推定するときには、コンテンツの変更はすべてシステムの負荷につながるという点に留意する必要があります。これには ACL の変更も含まれます。ドキュメントライブラリまたはサイトに対してアクセス許可の変更があったときには、多数のアイテムに対して ACL の変更が同時に発生する場合があります。この結果、ピーク時の更新率は高くなります。

重要

インデクサーを構成するには、インデクサーに関する複数の重要なパラメーターを含む構成ファイルを変更する必要があります。この構成ファイルは、将来のソフトウェア更新で変更される場合があります。ソフトウェア更新の後で、構成の変更を再度適用する必要があります。

操作の詳細については、「インデクサーのコンテンツ容量を拡張する (FAST Search Server 2010 for SharePoint)」を参照してください。

パフォーマンスと容量のチューニング (FAST Search Server 2010 for SharePoint)

クローラーの容量のチューニング

インデックスの容量のチューニング

See Also

Concepts

その他のリソース