パフォーマンスと容量の監視 (FAST Search Server 2010 for SharePoint)

  • [アーティクル]

 

適用先: FAST Search Server 2010

トピックの最終更新日: 2015-03-09

Microsoft FAST Search Server 2010 for SharePoint 展開のパフォーマンスと容量を監視する場合、分析できる領域は主に 2 つあります。

  • クロールとインデックス付けのパフォーマンス分析

  • クエリ パフォーマンスの分析

FAST Search Server 2010 for SharePoint ファームを監視する一般的な方法については、「FAST Search Server 2010 for SharePoint を監視する」を参照してください。Microsoft SharePoint Server 2010 ファームの全体を監視する方法については、「SharePoint Server 2010 の監視と保守」を参照してください。

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) を使用してコンテンツをクロールすることを前提として書かれています。

クロールとインデックス付けのパフォーマンス分析

コンテンツ プロセス チェーン

FAST Search Server 2010 for SharePoint でのアイテム処理チェーンは、個別のサーバーで実行できる以下のコンポーネントから構成されます。

  • クローラー   コンテンツを FAST Search Server 2010 for SharePoint にプッシュするコンポーネントです。

  • コンテンツ配信元   コンテンツを一括して受け取り、それをアイテム処理とインデックス作成に配信します。

  • ドキュメント プロセッサ (アイテム処理)   アイテムを、統一された内部形式に変換します。

  • インデキシング ディスパッチャー   処理された一括アイテムをインデックス列に配信します。

  • プライマリ インデクサー   検索可能インデックスを生成します。

  • バックアップ インデクサー   プライマリ インデクサーに含まれる情報のバックアップを保持します。

コンテンツは、アイテム処理チェーンの図に示した矢印 1 ～ 5 の順に流れます。最後のプライマリ インデクサーからバックアップ インデクサーへの流れは、省略可能な展開オプションです。完了した処理のコールバックは、矢印 6 ～ 9 で示す逆の方向に非同期に伝達されます。クローラーは、一括ドキュメント (1) に関して受け取ったコールバック (9) に基づいてクロール率を調整します。このチェーンで最も処理に時間がかかるコンポーネントによって全体のクロール率が決定されます。

各 FAST Search Server 2010 for SharePoint ファームに 1 つ以上のコンテンツ配信元があります。これらのコンポーネントは、すべてのコンテンツを一括で受け取り、それをアイテム処理コンポーネントに渡します。以下の条件が各コンポーネントで満たされることを確認すると、良好なパフォーマンスを得られます。

  • アイテム処理コンポーネントが効果的に使用されていること。

  • 一括して受け取ったコンテンツが速やかに処理先に配信されること。

送信する一括コンテンツが Content SSA のキューに絶えず存在するときにのみ、最大のスループットを達成できます。各アイテム処理コンポーネントは、ビジー状態のときに CPU コアを 100% 使用します。アイテム処理コンポーネントの数は、CPU コアあたり 1 つにまで調整できます。

インデクサーは、FAST Search Server 2010 for SharePoint 関連コンポーネントで最も書き込みを集中的に実行します。処理性能の高いディスクを用意する必要があります。また、多数のインデックスが作成されるときも、クエリ照合操作が同じ行を対象とする場合にパフォーマンスに影響を与える可能性があります。インデクサーは、アイテムを複数のパーティションに配信します。パーティション 0 と最大 3 つの他のパーティションは、処理中の操作を同時に実行できます。アイテムがパーティション間で再配信される間、あるパーティションが特定のチェックポイントに到達するまで他の 1 つ以上のパーティションが待機する場合があります。

ヒント

クロールとインデックス作成のパフォーマンスを分析するには、Windows Server 2008 [R2] のパフォーマンス モニターや Systems Center Operations Manager (SCOM) などのツールを使用します。また、indexerinfo コマンド (たとえば indexerinfo -a status) を使用してインデクサーの状態を取得できます。

クロール パフォーマンス カウンター

以下の表に、Content SSA にとって重要度の高いパフォーマンス カウンターについて説明します。これらのパフォーマンス カウンターは、Content SSA クロール コンポーネントをホストするサーバー上の "OSS Search FAST Content Plugin" の下に位置するものであり、FAST Search Server 2010 for SharePoint ファームの機能ではないことに注意してください。

パフォーマンス カウンター 説明

Batches ready

Content SSA がコンテンツ ソースから受け取ってコンテンツ配信元に渡せる状態にある一括コンテンツの数。ゼロの場合、FAST Search Server 2010 for SharePoint ファーム バックエンドは、Content SSA のクロール能力を超える速さでコンテンツを処理しています。

Batches submitted

Content SSA が FAST Search Server 2010 for SharePoint に送信し、コールバックがまだ保留中である一括コンテンツの数。ゼロの場合、処理するために FAST Search Server 2010 for SharePoint ファーム バックエンドに送信されたコンテンツはありません。

Batches open

処理のどこかの段階にある一括コンテンツの総数。

Items Total

サービスが最後に再起動されてから Content SSA によってクロールされたアイテムの総数。

Available Mbytes

コンピューターで使用可能なメモリの量。既定で、システム メモリの使用率が 80% に達すると、Content SSA は一括コンテンツの集約の受け入れを停止します。

Processor time

コンピューターの全体的な CPU 使用状況。CPU の負荷が高いと、Content SSA のスループットが制限されます。

Bytes Total/sec

コンピューターの全体的なネットワークの使用状況。ネットワークの負荷が高いと、Content SSA がクロールして FAST Search Server 2010 for SharePoint ファームにプッシュするデータの速度が上がらないボトルネックとなることがあります。

コンテンツ配信元とアイテム処理のパフォーマンス カウンター

以下の表に、コンテンツ配信元とアイテム処理に関係があるパフォーマンス カウンターの一覧を示します。システムの全体像を把握するには、すべてのコンテンツ配信元を対象にこれらのパフォーマンス カウンターの情報を集計する必要があります。

パフォーマンス カウンター 説明

Document processors

各コンテンツ配信元に登録されているアイテム処理コンポーネントの数。複数のコンテンツ配信元がある場合、アイテム処理コンポーネントはそれらのコンテンツ配信元に均等に分散されます。

Document processors busy

一括コンテンツを現在処理しているアイテム処理コンポーネントの数。この値は、最大の負荷がかかった状態にあるアイテム処理コンポーネントの数に近い必要があります。

Average dispatch time

コンテンツ配信元が一括コンテンツをアイテム処理コンポーネントに送信するために費やした時間。望ましい値は 10 ミリ秒未満です。これよりも大きな値は、ネットワークが混雑していることを示します。

Average processing time

アイテム処理コンポーネントが一括コンテンツの処理に費やした時間。この値はコンテンツの種類やサイズによって異なりますが、一般に 60 秒未満です。

Available Mbytes

コンピューターで使用可能なメモリの量。各アイテム処理コンポーネントは、最大 2GB のメモリを必要とします。メモリ不足は、処理のスループットに影響します。

Processor time

コンピューター全体の CPU 使用状況。アイテム処理コンポーネントは、CPU を集中的に消費します。通常、CPU の使用状況はクロール中は高い数値になりますが、アイテム処理中は優先順位が低くなり、必要に応じて他のコンポーネントに CPU リソースが譲り渡されます。

Bytes Total/sec

コンピューター全体のネットワーク使用状況。ネットワークの負荷が高いと、FAST Search Server 2010 for SharePoint サーバーによるデータ処理率にとってボトルネックになることがあります。

インデキシング ディスパッチャーとインデクサーのパフォーマンス カウンター

次の表に、インデキシング ディスパッチャーとインデクサーの最も重要なパフォーマンス カウンターを示します。

パフォーマンス カウンター 説明

Current queue size

インデクサーは、負荷の高い処理コンテンツをキューに配置します。これは特に部分更新の際によく起こる状況です。API キューが断続的にゼロになることはあっても完全にゼロになることがない場合は、インデクサーがボトルネックです。クローラーは、インデクサーのいずれか 1 つのキューが 256MB に達すると一時停止します。これは、ストレージ サブシステムの処理能力が十分でない場合に発生します。また、パーティション間で大きなコンテンツが再配布される際にも発生します。この状況下では、一時的に多数のコンテンツのインデックス付けがブロックされます。

FiXML fill rate

FiXML ファイル (インデクサー内の内部アイテム ストレージ) は、定期的に、既定で毎日午前 3 時から 5 時までの間に圧縮されます。この数値が低い (70% 未満) 場合、操作が十分に行われない結果につながります。

Active documents

パーティション 0 と 1 は、どちらも 100 万アイテム未満である必要があり、インデックス作成の待機時間を短く保つにはこの数字をさらに下回っていることが望まれます。アイテムのスループットが高いと、インデックス作成の待機時間は長くなります。これは、パーティション 0 と 1 が大きくなるので、全体のスループット向上に有利に働くためです。クエリ照合コンポーネントは、負荷が軽い期間にアイテムをより高い番号のパーティションに再編成します。

% Idle Time

ディスクのアイドル時間が少ない場合、ストレージ サブシステムが飽和している可能性があります。

% Free space

インデクサーは、クエリ照合コンポーネントで現在使用されているインデックス生成と、処理中の新しいインデックス生成の両方を実行するために空き領域を必要とします。負荷がフルにかかったシステムでは、アイテム数が同じでも、インデクサーのステータスによってディスクの使用状況は 40% からほぼ 100% までの範囲の値を示します。

Query performance analysis

SharePoint Server 2010 管理レポートは、クエリ パフォーマンスに関する便利な統計情報をクエリの開始から終了までに観点を置いて提供します。これらのレポートは、トレンドを一定の期間トレースするには効果的であり、パフォーマンスが最適ではない場合にどこを調べるのが適切なのかを明確に示します。

クエリの待機時間は、3 つに分かれます。Web サーバーのレンダリング、Query SSA 処理、およびバックエンド処理です。一般に、Web サーバー ページのレンダリングによる待機時間と Query SSA の待機時間は、SharePoint Server 2010 (Query SSA) を実行するサーバーで発生します。これらの待機時間は、SharePoint Server 2010 を稼働する SQL サーバーのパフォーマンスにも左右されます。以下のバックエンドの待機時間は、FAST Search Server 2010 for SharePoint サーバー側で発生します。

  • クエリ処理

  • クエリ照合

クエリは、Query SSA から FAST Search Server 2010 for SharePoint クエリ処理コンポーネント (展開ファイル内の "query") に送信されます。レポート内の “QRproxy”、“QRserver”、および “Fdispatch” がクエリ処理に相当します。Query SSA とクエリ処理コンポーネントは、ボトルネックになる可能性があります。両者で値が異なる場合、それは通信の遅延またはクエリ処理によるものです。

クエリ ディスパッチャー (レポート内の "Fdispatch") は、クエリを複数あるインデックス列に配信します。また、クエリ ディスパッチャーは各クエリ照合サーバーにも配置され、クエリを複数あるインデックス パーティションに配信します。どちらのクエリ ディスパッチャーも、クエリ結果に含まれるデータの量が多い場合にボトルネックとなります。これは、ネットワークの飽和を招きます。クエリ処理コンポーネントとクエリ照合コンポーネントとの通信には固有のネットワーク スイッチを使用することを推奨します。

クエリ照合コンポーネント (レポートの "Fsearch") は、インデックスに対する実際の照合を実行し、クエリの関連性を計算し、徹底的にコンテンツを絞り込みます。クエリごとに、インデクサーによって生成されたインデックスから必須の情報を読み取ります。再利用される可能性がある情報は、メモリ キャッシュに格納されます。高いレベルのクエリ照合パフォーマンスを得るには、強力な CPU と、読み取り単位の小さい (一般に 16 ～ 64 KB) ランダム ディスク アクセスが必要です。

クエリ処理パフォーマンス カウンター

次の表に、Query SSA とクエリ処理コンポーネントから報告されるバックエンドの待機時間に関連する有益なパフォーマンス カウンターを示します。

パフォーマンス カウンター 説明

# Queries/sec

1 秒あたりの現在のクエリ数

# Requests/sec

1 秒あたりの現在の要求の数。クエリの処理による負荷のほかに、QRserver の動作を確認するための内部要求が 1 秒ごとに受信されます。

Average queries per minute

クエリの平均負荷

Average latency last - ms

平均クエリの待機時間

Peak queries per sec

ピーク クエリの負荷

クエリ照合パフォーマンス カウンター

次の表に、クエリ照合コンポーネントを実行するサーバーの分析に役立つパフォーマンス カウンターを示します。

パフォーマンス カウンター 説明

% Idle Time

ディスクのアイドル時間が少ない場合、ストレージ サブシステムが飽和している可能性があります。

Avg. Disk sec/Read

1 回のクエリを完了するには、ディスクを数回読み取る必要があります。望ましい平均読み取り待機時間は 10 ミリ秒未満です。

Avg. Disk Read Queue Length

飽和したディスク サブシステムでは、読み取りキューが使用されます。キューはクエリの待機時間に影響します。キューの長さの平均値は、クエリ コンポーネントを実行するサーバーで 1 であることが望まれます。通常、単一行の展開でインデックス作成の処理に入ると数値はこれよりも大きな値になり、検索パフォーマンスに悪影響を与えます。

Processor time

CPU 使用率は、高いレベルのクエリ スループットを得る際にボトルネックとなる可能性があります。クエリ照合処理に多くのプロセッサ時間 (ほぼ 100%) が消費されている場合、クエリのスループットは頭打ちになります。

See Also

Concepts

パフォーマンスと容量の管理 (FAST Search Server 2010 for SharePoint)
パフォーマンスと容量の計画 (FAST Search Server 2010 for SharePoint)
パフォーマンスと容量のテスト (FAST Search Server 2010 for SharePoint)
パフォーマンスと容量のチューニング (FAST Search Server 2010 for SharePoint)