SharePoint Server 2010 Search のパフォーマンスと容量の要件を見積もる
適用先: SharePoint Server 2010
トピックの最終更新日: 2016-11-30
サマリー: この記事では、小規模、中規模、および大規模の SharePoint Server 2010 ファームを含め、Microsoft SharePoint Server 2010 検索のさまざまな展開における容量計画について説明します。
この記事では、SharePoint Server 2010 検索のグループ作業環境展開における容量計画について説明します。この記事には、3 つのサンプル検索ファーム構成の以下の情報が含まれます。
テスト環境の仕様 (ハードウェア、ファーム トポロジ、構成など)
データの生成に使用されるワークロード (ユーザーの数とクラスとファーム使用特性を含む)
テスト用ファームのデータセット (データベースのコンテンツとサイズを含む)
テストされる環境に固有の正常性とパフォーマンスのデータ
この記事には一般的なテスト データが含まれるほかに、似た環境を展開するために必要なハードウェア、トポロジ、および構成を決定する方法に関する推奨事項と、適切な容量とパフォーマンスの特性に合わせた環境の最適化方法に関する推奨事項も含まれます。
SharePoint Server 2010 検索には、以前のバージョンよりも豊富な機能セットおよび柔軟なトポロジ モデルが含まれます。このアーキテクチャを使用してより強力な機能と機能性をユーザーに提供する前に、ファームの容量とパフォーマンスへの影響を慎重に考慮する必要があります。
このドキュメントを読むことで次の方法を理解できます。
環境におけるパフォーマンスと容量の目標を定義する。
ユーザーの数と種類をサポートするために必要なハードウェア、および展開する機能を計画する。
最適な信頼性と効率を得るための物理トポロジと論理トポロジを設計する。
パフォーマンスと容量の目標を達成するために環境のテスト、検証、およびサイズ調整を行う。
環境の主なインジケーターを監視する。
この記事を読むには、以下の点について十分に理解している必要があります。
可用性
冗長性
データベース固有のコンテンツ
計画の概要
この記事のシナリオでは、ファームの適切な容量の計画を開始するのに役立つ可能性のある前提条件と共に、小規模、中規模、および大規模のテスト ファームについて説明します。これらのファーム サイズは、以下の前提条件に基づく概算値です。
クロールされるリポジトリは、主に、SharePoint Server コンテンツである。
大多数のユーザー クエリはインデックスの同一の 33 パーセント内で見つかる可能性がある。つまり、ほとんどのユーザーは同じ用語に対してクエリを実行する。
既定のメタデータ設定が使用されており、プロパティ データベースが急激に増大することはない。
中規模および大規模ファームでは、専用のクロール ターゲット (フロントエンド Web サーバー) が存在する。これを使用して、これらの検索ファームのクロール コンポーネントにコンテンツを提供できる。
これらのファームで取得される測定値は、ネットワークおよび環境の条件によって異なる可能性がある。また、この測定値には、最大で 10 パーセントの誤差がある。
シナリオの選択
適切なシナリオを選択するには、以下の点について検討します。
コーパスのサイズ 検索可能にするコンテンツの分量を判断します。アイテムの総数には、ドキュメント、Web ページ、リスト アイテム、ユーザーを含め、すべてのオブジェクトを含める必要があります。
可用性 可用性の要件を判断します。ユーザーが必要とするのは、特定のサーバーで障害が発生しても稼働を続けられる検索ソリューションでしょうか。
コンテンツの新しさ 検索結果の鮮度について判断します。ユーザーがコンテンツを変更してから、検索結果に更新後のコンテンツが表示されるようになるまで、どの程度の時間を置く必要があるでしょうか。コンテンツの変更はどの程度の頻度で生じるでしょうか。
スループット コンテンツを同時に検索するユーザー数を判断します。これには、クエリ ボックスに入力するユーザー、背後で実行されるクエリ (データを自動的に検索する Web パーツなど)、または検索システムからのセキュリティによるトリミングが必要な URL を含むアクティビティ フィードを要求する Microsoft Outlook 2010 Social Connector が含まれます。
これらの検討結果から、以下のシナリオのいずれかを選択します。
小規模ファーム 1 つの SharePoint Server ファーム上でいくつかのリソースを共有する 1 つの Search Service アプリケーションを含みます。一般的に、検索の対象とするコンテンツの量に制限のある (1,000 万アイテム未満) 小規模展開に適しています。求められる新しさの目標によっては、業務時間中に増分クロールが実行される場合があります。
中規模ファーム 専用ファームに 1 つ以上の Search Service アプリケーションを含みます。専用ファームは、他のファームに検索サービスを提供します。検索の対象とするコンテンツの量は中程度 (最大で 4,000 万アイテム) です。新しさの目標を満たすために、業務時間中に増分クロールが実行される可能性があります。
大規模ファーム 専用ファームに 1 つ以上の Search Service アプリケーションを含みます。専用ファームは、他のファームに検索サービスを提供します。検索の対象とするコンテンツの量は大程度 (最大で 1 億アイテム) です。新しさの目標を満たすために、業務時間中に増分クロールが実行される可能性があります。
検索ライフ サイクル
これらの 3 つのシナリオを使用してファームの初期ステージで容量を見積もることができます。ファームは、コンテンツがクロールされるにつれて、検索ライフ サイクルの以下のステージを移動します。
インデックスの取得 これは、データ生成の最初のステージです。このステージの期間は、コンテンツ ソースのサイズによって決まります。このステージには以下の特徴があります。
コンテンツのフル クロール (同時実行される可能性がある)。
クロール システムの厳密な監視。これにより、クロールするホストがクロールのボトルネックにならないようにします。
頻繁なマスター結合。マスター結合は、クエリ コンポーネントごとに、特定の量のインデックスが変更された場合に起動されます。
インデックスのメンテナンス これは、ファームの最も一般的なステージです。このステージには以下の特徴があります。
すべてのコンテンツの増分クロールがあります。
SharePoint Server コンテンツ クロールの場合、クロール中に発生する大多数の変更はセキュリティの変更です。
マスター結合は頻繁に発生しません。マスター結合は、クエリ コンポーネントごとに、特定の量のインデックスが変更された場合に起動されます。
インデックスのクリーンアップ このステージは、コンテンツの変更によって、ファームがインデックスのメンテナンス ステージから移動する場合に実行されます。たとえば、コンテンツ データベースまたはサイトが Search Service アプリケーション間を移動する場合です。このステージは、以下のどちらかが発生した場合に起動されます。
コンテンツを提供するホストが、検索クローラーによって長期間見つけられない。
コンテンツ ソースまたは開始アドレスが Search Service アプリケーションから削除された。
シナリオ
このセクションでは、小規模、中規模、および大規模ファームのシナリオで使用された構成について説明します。また、各環境のワークロード、データセット、パフォーマンス データ、およびテスト データも含まれます。
小規模ファーム
ファームが小規模なため、いくつかのサーバーで複数のロールを実行する必要があります。クロール コンポーネントとクエリ コンポーネントを同じサーバーに配置することを回避するために、クエリ コンポーネントをフロントエンド Web サーバーに結合することをお勧めします。この構成では、次のように 3 つのアプリケーション サーバーと 1 つのデータベース サーバーを使用します。
エンタープライズ検索では冗長性のあるクエリ サーバーが一般的に推奨されているため、クエリ コンポーネント用に 2 つのアプリケーション サーバーが使用されました。構成は以下のとおりです。
1 つのアプリケーション サーバーでは、検索センターもホストされます。小規模ファームがサービス ファームとして使用されており、親のサービス ファームから Search Service アプリケーションを使用する子のコンテンツ ファームに検索センターが作成されている場合、この構成は省略できます。
1,000 万アイテム未満の場合の推奨クエリ構成は、1 つのインデックス パーティションを含めることです。その後、インデックス パーティションからの 1 つのプライマリ クエリ コンポーネントを各サーバーに含めます。このアクティブ/アクティブのクエリ コンポーネント セットアップでは、1 つのクエリ コンポーネントでエラーが発生しても、残りのクエリ コンポーネントによってクエリを処理する機能を維持できます。1 つのクエリ コンポーネントが失敗すると、検索は、次に使用可能なクエリ コンポーネントにクエリを送信 (ラウンドロビン) します。
クロールと管理で使用する 1 つのアプリケーション サーバー。つまり、サーバーの全体管理 (検索管理コンポーネント) とクロール コンポーネントがこのサーバーに作成されます。
ファームをサポートする 1 つのデータベース サーバー。データベース サーバーには、クロール データベース、プロパティ データベース、および管理データベースに対して専用の IOPS (Input/Output Operations Per Second: 1 秒ごとの入出力操作) 数が設定される必要があります (たとえば、異なるストレージ アレイを使用する)。
仕様
このセクションでは、テスト環境のハードウェア、ソフトウェア、トポロジ、および構成の詳細について説明します。
トポロジ
.gif "検索の小規模ファーム トポロジ")
ハードウェア
注意
テスト ファームでは、プレリリース版の SharePoint Server 2010 が実行されており、チームは潜在的な問題を回避する必要があったため、サーバーには、通常必要とされるよりも大容量のハードウェアが使用されていました。
Web サーバー
| Web サーバー | フロントエンド Web サーバー/クエリ (1) |
|---|---|
プロセッサ |
1px4c@3 GHz |
RAM |
16 GB |
オペレーティング システム |
Windows Server 2008 R2 64 ビット版 |
記憶域 |
2x450GB 15K SAS、RAID1、OS 2x450GB 15K SAS、RAID1、データ 1 2x450GB 15K SAS、RAID1、データ 2 |
ネットワーク インターフェイス カード (NIC) の数 |
2 |
NIC の速度 |
1 ギガビット |
認証 |
NTLM |
ロード バランサーの種類 |
なし |
ソフトウェアのバージョン |
SharePoint Server 2010 (プレリリース版) |
ローカルで実行されているサービス |
すべてのサービス (Search Query and Site Settings Service を含む) |
アプリケーション サーバー
| サーバー | クエリ (1) | クロール/管理 (1) |
|---|---|---|
プロセッサ |
1px4c@3 GHz |
1px4c@3 GHz |
RAM |
16 GB |
16 GB |
オペレーティング システム |
Windows Server 2008 R2 64 ビット版 |
Windows Server 2008 R2 64 ビット版 |
記憶域 |
2x450GB 15K SAS、RAID1、OS 2x450GB 15K SAS、RAID1、データ 1 2x450GB 15K SAS、RAID1、データ 2 |
2x450GB 15K SAS、RAID1、OS 2x450GB 15K SAS、RAID1、TEMP 2x450GB 15K SAS、RAID0、データ |
NIC の数 |
1 |
1 |
NIC の速度 |
1 ギガビット |
1 ギガビット |
認証 |
NTLM |
NTLM |
ロード バランサーの種類 |
なし |
なし |
ソフトウェアのバージョン |
SharePoint Server 2010 (プレリリース版) |
SharePoint Server 2010 (プレリリース版) |
ローカルで実行されているサービス |
SharePoint Server Search、Search Query and Site Settings Service |
SharePoint Server Search |
データベース サーバー
| データベース | 共有 (1) |
|---|---|
プロセッサ |
2px4c@3 GHz |
RAM |
16 GB |
オペレーティング システム |
Windows Server 2008 R2 64 ビット版 |
記憶域 |
2x450GB 15K SAS、RAID1、OS 2x450GB 15K SAS、RAID0、データ 2x450GB 15K SAS、RAID0、LOGS 注意 ドライブ数の減少により、異なる IO チャネル上でデータベースを分離するベスト プラクティスは適用できませんでした。 |
NIC の数 |
2 |
NIC の速度 |
1 ギガビット |
認証 |
NTLM |
ソフトウェアのバージョン |
Microsoft SQL Server 2008 Enterprise |
ワークロード
このセクションでは、ユーザー数、ファームの使用特性を含め、データの生成で使用されたワークロードについて説明します。
| ワークロード特性 | 値 |
|---|---|
ワークロードに関する高レベルの説明 |
Search ファーム |
1 分ごとの平均クエリ |
6 |
平均の同時ユーザー数 |
1 |
1 日ごとのクエリの合計数 |
8,640 |
データセット
このセクションでは、テスト用ファームのデータセット (データベースのコンテンツとサイズ、検索インデックス、外部データ ソースなど) について説明します。
| オブジェクト | 値 |
|---|---|
検索インデックスのサイズ (アイテムの数) |
900 万 |
クロール データベースのサイズ |
52 GB |
クロール データベースのログ ファイルのサイズ |
11 GB |
プロパティ データベースのサイズ |
68 GB |
プロパティ データベースのログ ファイルのサイズ |
1 GB |
検索管理データベースのサイズ |
2 GB |
アクティブなインデックス パーティションのサイズ |
38.4 GB (合計 76.8 GB。インデックスがミラー化されているため) |
検索データベースの合計数 |
3 |
その他のデータベース |
SharePoint_Config、SharePoint_AdminContent、State_Service、Bdc_Service_db、WSS_UsageApplication、WSS_Content |
正常性とパフォーマンスのデータ
このセクションでは、テスト環境に固有の正常性とパフォーマンスのデータを示します。
クエリ パフォーマンスのデータ
以下の測定値は、インデックス内にある 900 万アイテムを使用して取得されました。各列には特定のテスト中に取得された測定値が示されており、結果は以下の表の下部に示されています。各測定値の説明は以下のとおりです。
クエリの待機時間 これらの測定値は、クエリの待機時間テスト中に取得されました。このテストでは、テスト ツールが 1 つのユーザーとしてクエリの標準セットを送信し、結果の待機時間が測定されました。テスト中にクロールは実行されていませんでした。
クエリのスループット これらの測定値は、クエリのスループット テスト中に取得されました。このテストでは、テスト ツールが、同時ユーザー数を増加 (最大で 80) しながらクエリの標準セットをファームに対して送信し、結果の待機時間とスループットが測定されました。テスト中にクロールは実行されていませんでした。
| スコアカード測定基準 | クエリの待機時間 | クエリのスループット | |
|---|---|---|---|
CPU 測定基準 |
平均 SQL Server CPU |
3.4% |
12% |
平均フロントエンド Web サーバー CPU |
8% |
51% |
|
平均クエリ サーバー CPU |
13.3% |
95% |
|
信頼性 |
失敗率 |
0 |
0 |
フロントエンド Web サーバーのクラッシュ |
0 |
0 |
|
アプリケーション サーバーのクラッシュ |
0 |
0 |
|
SQL Server |
キャッシュ ヒット率 (SQL Server) |
99.97% |
100% |
SQL Server のロック: 平均待機時間 (ミリ秒) |
0.071 |
0.038 |
|
SQL Server のロック: ロック待機時間 (ミリ秒) |
0.035 |
0.019 |
|
SQL Server のロック: デッドロック/秒 |
0 |
0 |
|
SQL Server のラッチ: 平均待機時間 (ミリ秒) |
31 |
0.017 |
|
SQL Server のコンパイル/秒 |
14.9 |
10.2 |
|
SQL Server の統計情報: SQL Server 再コンパイル/秒 |
0.087 |
0.05 |
|
平均ディスク キュー長 (SQL Server) |
0.011 |
0.01 |
|
ディスク キュー長: 書き込み (SQL Server) |
0.01 |
0.008 |
|
|
ディスクの読み取り/秒 (SQL Server) |
0.894 |
0.05 |
ディスクの書き込み/秒 (SQL Server) |
45 |
106 |
|
アプリケーション サーバー |
平均ディスク キュー長 (クエリ サーバー) |
0.013 |
0.001 |
ディスク キュー長: 書き込み (クエリ サーバー) |
0 |
0.001 |
|
ディスクの読み取り/秒 (クエリ サーバー) |
11.75 |
0.06 |
|
ディスクの書き込み/秒 (クエリ サーバー) |
4 |
5.714 |
|
平均メモリ使用量 (クエリ サーバー) |
8.73% |
9% |
|
最大メモリ使用量 (クエリ サーバー) |
8.75% |
9% |
|
フロントエンド Web サーバー |
キューに入れられた ASP.NET 要求 (すべてのフロントエンド Web サーバーの平均) |
0 |
0 |
平均メモリ使用量 (フロントエンド Web サーバー) |
9.67% |
95% |
|
最大メモリ使用量 (フロントエンド Web サーバー) |
9.74% |
100% |
|
テスト結果 |
成功数 |
1,757 |
13,608 |
エラー数 |
0 |
0 |
|
クエリ UI の待機時間 (75 パーセンタイル) |
0.331 秒 |
3.68 秒 |
|
クエリ UI の待機時間 (95 パーセンタイル) |
0.424 秒 |
3.93 秒 |
|
クエリのスループット |
3.29 要求/秒 |
22.4 要求/秒 |
クロールのパフォーマンス データ
以下の測定値は、特定のコンテンツ ソースの最初の順次的なフル クロール中に取得されました。コンテンツ ソースのサイズは数百万アイテム単位で与えられています。各列には特定のクロール中に取得された測定値が示されており、結果は表の下部に示されています。
| スコアカード測定基準 | SharePoint コンテンツ (4M) | ファイル共有 (1M) | HTTP (SharePoint 以外) (1M) | |
|---|---|---|---|---|
CPU 測定基準 |
平均 SQL Server CPU |
5.4% |
11.7% |
23% |
平均インデクサー CPU |
41.6% |
69% |
71% |
|
信頼性 |
失敗率 |
0 |
0 |
0 |
フロントエンド Web サーバーのクラッシュ |
0 |
0 |
0 |
|
アプリケーション サーバーのクラッシュ |
0 |
0 |
0 |
|
SQL Server |
キャッシュ ヒット率 (SQL Server) |
該当なし |
該当なし |
該当なし |
SQL Server のロック: 平均待機時間 (ミリ秒) |
436 |
51.76 |
84.73 |
|
SQL Server のロック: ロック待機時間 (ミリ秒) |
該当なし |
該当なし |
該当なし |
|
SQL Server のロック: デッドロック/秒 |
該当なし |
該当なし |
該当なし |
|
SQL Server のラッチ: 平均待機時間 (ミリ秒) |
1.05 |
1.64 |
3.53 |
|
SQL Server のコンパイル/秒 |
該当なし |
該当なし |
該当なし |
|
SQL Server の統計情報: SQL Server 再コンパイル/秒 |
該当なし |
該当なし |
該当なし |
|
平均ディスク キュー長 (SQL Server) |
27.124 |
6.85 |
45 |
|
ディスク キュー長: 書き込み (SQL Server) |
17.6 |
6.7 |
21.57 |
|
アプリケーション サーバー |
平均ディスク キュー長 (クロール サーバー) |
0.008 |
0.032 |
0.02 |
ディスク キュー長: 書き込み (クロール サーバー) |
0.006 |
0.025 |
0.012 |
|
平均メモリ使用量 (クロール サーバー) |
14.16% |
10.4% |
11.5% |
|
最大メモリ使用量 (クロール サーバー) |
19.2% |
11.13% |
12.78% |
|
フロントエンド Web サーバー |
キューに入れられた ASP.NET 要求 (すべてのフロントエンド Web サーバーの平均) |
0 |
0 |
0 |
平均メモリ使用量 (フロントエンド Web サーバー) |
該当なし |
該当なし |
該当なし |
|
最大メモリ使用量 (フロントエンド Web サーバー) |
該当なし |
該当なし |
該当なし |
|
テスト結果 |
成功数 |
3,934,881 |
1,247,838 |
996,982 |
エラー数 |
9,645 |
302 |
2 |
|
ポータルのクロール速度 (アイテム/秒) |
46.32 |
120.436 |
138.316 |
|
アンカーのクロール速度 (アイテム/秒) |
5,197 |
3,466.219 |
2,192.982 |
|
合計クロール速度 (アイテム/秒) |
45.91 |
116.392 |
130.086 |
テスト データ
このセクションでは、ファームがどのように実行されたかを示すテスト データについて説明します。ファームのパフォーマンスを向上する方法については、この記事の後半にある「最適化」を参照してください。
クエリの待機時間
次のグラフは、ユーザー ロードの増加に伴う、このファームのクエリ待機時間のパーセンタイルを示しています (クエリ スループット テスト中に収集された情報)。95 パーセントのクエリ パーセンタイルは、測定されたクエリ待機時間の 95 パーセントがその値よりも低いことを意味します。
.gif "ユーザー負荷がクエリ待機時間のパーセンタイルに与える影響")
インデックスが小さいと、多くの同時ユーザー (20) がこのファームでクエリを実行しても、このファームは 1 秒未満のクエリ待機時間を維持できることがこのグラフからわかります。
クエリのスループット
次のグラフは、ユーザー ロードの増加に伴う、このファームのクエリのスループットを示しています (クエリ スループット テスト中に収集された情報)。
.gif "ユーザー負荷がクエリ スループットに与える影響")
前の 2 つのグラフを考慮すると、約 20 の同時ユーザーを超えるユーザー ロードが加えられた場合、このファームではクエリ スループットは向上せずに、待機時間が増加することがわかります。
クロール レート
次のグラフは、検索ライフ サイクルのインデックス取得ステージにおけるこのファームのクロール レートを示しています。この値はフル クロールを表しており、単位は 1 秒あたりにクロールされたアイテム数です。
.gif "コンテンツの種類別のフル クロール率")
SharePoint サイトのコンテンツ ソースのフル クロールを効果的に実行するのに伴って発生した追加のオーバーヘッドによって、このファームの全体的なクロール レートが低下しています。
全体的な要点
このファームは、クエリ サーバーの RAM がいっぱいに近い状態でした。フロントエンド Web サーバーのプロセス (このプロセスも RAM を使用する) はクエリ サーバーの 1 つにも含まれていたため、そのサーバーで実行されるクエリの遅延時間に影響します。
このファームのパフォーマンスを向上するための次の手順は、次の処理を行うことです。
フロントエンド Web サーバーのプロセスを独自のフロント エンド Web サーバーに移動します (つまり、冗長性を確保するために別のフロントエンド Web サーバーを追加します)。
RAM を両方のクエリ サーバーに追加します。アクティブ クエリ コンポーネントのインデックス パーティションの 33 パーセントにオペレーティング システムとその他のプロセス用の 3 GB を加えた十分な RAM をクエリ サーバーに搭載することをお勧めします。
ストレージ アレイを追加して、データベース サーバーでデータベースを分離できるようにします。
中規模ファーム
中規模ファーム構成では、次のように 1 つの Web サーバー、6 つのアプリケーション サーバー、2 つのデータベース サーバーを使用します。
このテスト構成では、1 つの Web サーバーを使用して検索センターがホストされました。Search Service アプリケーション プロキシ (子ファームにインストールされている) を使用して検索が子ファームから常に実行される場合、この Web サーバーは省略できます。そうでない場合、別の Web サーバーをこのファームに追加して冗長性を確保できます。
クロールと管理に 2 つのアプリケーション サーバーを使用します。これは、以下の状態を意味します。
サーバーの全体管理と検索管理コンポーネントは、1 つのアプリケーション サーバーに作成されます。
各サーバーに 2 つのクロール コンポーネントがあります。各クロール コンポーネントは、異なるクロール データベースに接続され、冗長性が確保されます。
残りの 4 つのアプリケーション サーバーはクエリで使用します。4,000 万アイテムまでの場合の標準構成は、4 つのインデックス パーティションを含めることです。冗長性のあるクエリ機能を達成するには、1 つのインデックス パーティションからの 1 つのアクティブ クエリ コンポーネントと、別のインデックス パーティションからのフェールオーバー クエリ コンポーネントを各サーバーに含めるようにクエリ コンポーネントを配置します。ただし、このファーム例では、4,000 万を超えるアイテムを含める計画を作成する場合に何を行うかが示されています。インデックスのパーティション再分割を最小限に抑えるように、4 つのアプリケーション サーバー上の 8 つのインデックス パーティション (各インデックス パーティションに独自のアクティブ クエリ コンポーネントとフェールオーバー クエリ コンポーネントが含まれる) から開始します。同じアプリケーション サーバーで 4 つのコンポーネントを動作できるように各サーバーで以下のガイドラインが満たされていることを前提とします。
十分な RAM と IOPS を使用できる。
処理をサポートするために、次のように各サーバーに 6 個を超える CPU コアがある。
2 つのアクティブ クエリ コンポーネントに対して 4 つの CPU コア。
2 つのフェールオーバー クエリ コンポーネントに対して 2 つの CPU コア。
2 つのデータベース サーバーでファームをサポートします。1 つのデータベース サーバーを 2 つのクロール データベースで使用します。もう 1 つのサーバーは、その他の SharePoint データベースで使用するのに加えて、プロパティ データベースと検索管理データベースでも使用します。データベース サーバーには、クロール データベース、プロパティ データベース、および検索管理データベースごとに専用の IOPS 数が設定される必要があります (たとえば、異なるストレージ アレイを使用する)。
仕様
このセクションでは、テスト環境のハードウェア、ソフトウェア、トポロジ、および構成の詳細について説明します。
トポロジ
.gif "検索の中規模ファーム トポロジ")
ハードウェア
注意
テスト ファームでは、プレリリース版の SharePoint Server 2010 が実行されており、チームは潜在的な問題を回避する必要があったため、サーバーには、通常必要とされるよりも大容量のハードウェアが使用されていました。
Web サーバー
| Web サーバー | フロントエンド Web サーバー (1) |
|---|---|
プロセッサ |
2px4c@2.33 GHz |
RAM |
8 GB |
オペレーティング システム |
Windows Server 2008 R2 64 ビット版 |
記憶域 |
2x148GB 15K SAS、RAID1、OS |
NIC の数 |
2 |
NIC の速度 |
1 ギガビット |
認証 |
NTLM |
ロード バランサーの種類 |
なし |
ソフトウェアのバージョン |
Microsoft SharePoint Server (プレリリース版) |
ローカルで実行されているサービス |
すべてのサービス |
アプリケーション サーバー
ファームには 6 つのアプリケーション サーバーがあります。4 つのサーバーを使用してクエリを処理し、2 つのサーバーを使用してクロールを行います。
| サーバー (カウント) | クエリ (4) | クロール (1)、クロール/管理 (1) |
|---|---|---|
プロセッサ |
2px4c@2.33 GHz |
2px4c@2.33 GHz |
RAM |
32 GB |
8 GB |
オペレーティング システム |
Windows Server 2008 R2 64 ビット版 |
Windows Server 2008 R2 64 ビット版 |
記憶域 |
2x148 GB 15K SAS、RAID1、OS 4x300GB 15K SAS、RAID10、データ |
2x148 GB 15K SAS、RAID1、OS/データ |
NIC の数 |
2 |
2 |
NIC の速度 |
1 ギガビット |
1 ギガビット |
認証 |
NTLM |
NTLM |
ロード バランサーの種類 |
なし |
なし |
ソフトウェアのバージョン |
SharePoint Server 2010 (プレリリース版) |
SharePoint Server 2010 (プレリリース版) |
ローカルで実行されているサービス |
SharePoint Server Search、Search Query and Site Settings Service |
SharePoint Server Search |
データベース サーバー
2 つのデータベース サーバーがあります。1 番目のサーバーには、検索管理データベース、プロパティ データベース、およびその他の SharePoint Server データベースが含まれます。2 番目のサーバーには、2 つのクロール データベースが含まれます。作成されたストレージ ボリュームによって、テストで使用可能であった既存のハードウェアが最適化されました。
| データベース サーバー | 検索管理データベース、プロパティ データベース、SharePoint データベース | クロール データベース |
|---|---|---|
プロセッサ |
2px4c@3.2 GHz |
4px2c@2.19 GHz |
RAM |
32 GB |
16 GB |
オペレーティング システム |
Windows Server 2008 R2 64 ビット版 |
Windows Server 2008 R2 64 ビット版 |
記憶域 |
2x148GB 15K SAS、RAID1、OS 2x148GB 15K SAS、RAID1、TEMP ログ 2x450GB 15K SAS、RAID1、TEMP DB 6x450GB 15K SAS、RAID10、プロパティ DB 2x450GB 15K SAS、RAID1、検索管理、SharePoint DB 2x450GB 15K SAS、RAID1、Logs |
2x148GB 15K SAS、RAID1、OS 2x148GB 15K SAS、RAID1、TEMP ログ 2x300GB 15K SAS、RAID1、TEMP DB 6x146GB 15K SAS、RAID10、クロール DB1 6x146GB 15K SAS、RAID10、クロール DB2 2x300GB 15K SAS、RAID1、Crawl DB ログ 1 2x300GB 15K SAS、RAID1、Crawl DB ログ 2 |
NIC の数 |
2 |
2 |
NIC の速度 |
1 ギガビット |
1 ギガビット |
認証 |
NTLM |
NTLM |
ソフトウェアのバージョン |
SQL Server 2008 Enterprise |
SQL Server 2008 Enterprise |
ワークロード
このセクションでは、ユーザー数、ファームの使用特性を含め、データの生成で使用されたワークロードについて説明します。
| ワークロード特性 | 値 |
|---|---|
ワークロードに関する高レベルの説明 |
Search ファーム |
1 分ごとの平均クエリ |
12 |
平均の同時ユーザー数 |
1 |
1 日ごとのクエリの合計数 |
17,280 |
タイマー ジョブ |
検索の正常性追跡 - トレース イベント、クロール ログのレポート、正常性解析ジョブ、検索と処理 |
データセット
このセクションでは、テスト用ファームのデータセット (データベースのコンテンツとサイズ、検索インデックス、外部データ ソースなど) について説明します。
| オブジェクト | 値 |
|---|---|
検索インデックスのサイズ (アイテムの数) |
4,600 万 |
クロール データベースのサイズ |
356 GB |
クロール データベースのログ ファイルのサイズ |
85 GB |
プロパティ データベースのサイズ |
304 GB |
プロパティ データベースのログ ファイルのサイズ |
9 GB |
検索管理データベースのサイズ |
5 GB |
アクティブなインデックス パーティションのサイズ |
316 GB (アクティブなコンポーネントごとに 79 GB)。 |
データベースの合計数 |
4 |
その他のデータベース |
SharePoint_Config、SharePoint_AdminContent、State_Service、Bdc_Service_db、WSS_UsageApplication、WSS_Content |
正常性とパフォーマンスのデータ
このセクションでは、テスト環境に固有の正常性とパフォーマンスのデータを示します。
クエリ パフォーマンスのデータ
以下の測定値は、検索インデックス内にある 4,600 万アイテムを使用して取得されました。各列には特定のテスト中に取得された測定値が示されており、結果は表の下部に示されています。各測定値の説明は以下のとおりです。
クエリの待機時間 これらの測定値は、クエリの待機時間テスト中に取得されました。このテストでは、テスト ツールが 1 つのユーザーとしてクエリの標準セットを送信し、結果の待機時間が測定されました。テスト中にクロールは実行されていませんでした。
クエリのスループット これらの測定値は、クエリのスループット テスト中に取得されました。このテストでは、テスト ツールが、同時ユーザー数を増加 (最大で 80) しながらクエリの標準セットをファームに対して送信し、結果の待機時間とスループットが測定されました。テスト中にクロールは実行されていませんでした。
| スコアカード測定基準 | クエリの待機時間 | クエリのスループット | |
|---|---|---|---|
CPU 測定基準 |
平均 SQL Server CPU (プロパティ データベース サーバー) |
5% |
98% |
平均フロントエンド Web サーバー CPU |
3% |
33% |
|
平均クエリ サーバー CPU |
3% |
47% |
|
信頼性 |
失敗率 |
0.07% |
0% |
フロントエンド Web サーバーのクラッシュ |
0 |
0 |
|
アプリケーション サーバーのクラッシュ |
0 |
0 |
|
SQL Server (プロパティ データベース サーバー) |
キャッシュ ヒット率 (SQL Server) |
100% |
99.9% |
SQL Server のロック: 平均待機時間 (ミリ秒) |
0.000 |
0.159 |
|
SQL Server のロック: ロック待機時間 (ミリ秒) |
0.000 |
0.080 |
|
SQL Server のロック: デッドロック/秒 |
0 |
0 |
|
SQL Server のラッチ: 平均待機時間 (ミリ秒) |
0.041 |
1.626 |
|
SQL Server のコンパイル/秒 |
9.776 |
93.361 |
|
SQL Server の統計情報: SQL Server 再コンパイル/秒 |
0.059 |
0.071 |
|
読み取り/書き込みの比率 (データベースあたりの IO) |
0.01 |
0.81 |
|
平均ディスク キュー長 (SQL Server) |
0.001 |
0.037 |
|
ディスク キュー長: 書き込み (SQL Server) |
0.000 |
0.003 |
|
|
ディスクの読み取り/秒 (SQL Server) |
0.057 |
14.139 |
ディスクの書き込み/秒 (SQL Server) |
4.554 |
17.515 |
|
アプリケーション サーバー |
平均ディスク キュー長 (クエリ サーバー) |
0.000 |
0.001 |
ディスク キュー長: 書き込み (クエリ サーバー) |
0.000 |
0.001 |
|
ディスクの読み取り/秒 (クエリ サーバー) |
0.043 |
0.266 |
|
ディスクの書き込み/秒 (クエリ サーバー) |
4.132 |
5.564 |
|
平均メモリ使用量 (クエリ サーバー) |
9% |
10% |
|
最大メモリ使用量 (クエリ サーバー) |
9% |
10% |
|
フロントエンド Web サーバー |
キューに入れられた ASP.NET 要求 (すべてのフロントエンド Web サーバーの平均) |
0 |
0 |
平均メモリ使用量 (フロントエンド Web サーバー) |
47% |
48% |
|
最大メモリ使用量 (フロントエンド Web サーバー) |
47% |
49% |
|
テスト結果 |
成功数 |
1,398 |
14,406 |
エラー数 |
1 |
0 |
|
クエリ UI の待機時間 (75 パーセンタイル) |
0.47 秒 |
2.57 秒 |
|
クエリ UI の待機時間 (95 パーセンタイル) |
0.65 秒 |
3.85 秒 |
|
クエリのスループット |
2.38 要求/秒 |
27.05 要求/秒 |
クロールのパフォーマンス データ
以下の測定値は、特定のコンテンツ ソースの最初のフル クロール中に取得されました。コンテンツ ソースのサイズは数百万アイテム単位で与えられています。各列には特定のクロール中に取得された測定値が示されており、結果は以下の表の下部に示されています。
| スコアカード測定基準 | SharePoint コンテンツ (350 万) | ファイル共有 (100 万) | HTTP (SharePoint 以外) (100 万) | |
|---|---|---|---|---|
CPU 測定基準 |
平均 SQL Server CPU (クロール データベース サーバー、プロパティ データベース サーバー) |
11%、19% |
22%、7% |
23%、5% |
最大 SQL Server CPU (クロール データベース サーバー、プロパティ データベース サーバー) |
96%、100% |
86%、45% |
79%、28% |
|
平均インデクサー CPU |
41.6% |
69% |
71% |
|
信頼性 |
失敗率 |
0.2% |
0.02% |
0% |
フロントエンド Web サーバーのクラッシュ |
0 |
0 |
0 |
|
アプリケーション サーバーのクラッシュ |
0 |
0 |
0 |
|
SQL Server (クロール データベース サーバー、プロパティ データベース サーバー) |
キャッシュ ヒット率 (SQL Server) |
99.5%、99.8% |
未収集 |
99.9%、99.3% |
SQL Server のロック: 平均待機時間 [ミリ秒] |
1,881.749、1,106.314 |
1,617.980、2.882 |
983.137、0.904 |
|
SQL Server のロック: 最大待機時間 [ミリ秒] |
69,919.500、1,081,703 |
55,412.000、304.500 |
24,000.500、47 |
|
SQL Server のロック: 平均ロック待機時間 [ミリ秒] |
339.658、10,147.012 |
未収集 |
739.232、0.136 |
|
SQL Server のロック: 最大ロック待機時間 [ミリ秒] |
598,106.544、234,708,784 |
未収集 |
52,711.592、23.511 |
|
SQL Server のロック: デッドロック/秒 |
0.001、0 |
未収集 |
0.008、0 |
|
SQL Server のラッチ: 平均待機時間 [ミリ秒] |
2.288、13.684 |
3.042、13.516 |
2.469、20.093 |
|
SQL Server のラッチ: 最大待機時間 [ミリ秒] |
2,636、1,809 |
928、858.5 |
242.929、938.706 |
|
SQL Server のコンパイル/秒: 平均 |
20.384、5.449 |
未収集 |
76.157、6.510 |
|
SQL Server のコンパイル/秒: 最大 |
332.975、88.992 |
未収集 |
295.076、42.999 |
|
SQL Server の統計情報: SQL Server の再コンパイル/秒: 平均 |
0.560、0.081 |
未収集 |
0.229、0.125 |
|
SQL Server の統計情報: SQL Server の再コンパイル/秒: 最大 |
22.999、88.492 |
未収集 |
17.999、15.5 |
|
読み取り/書き込みの比率 (データベースあたりの IO): 最大 |
2.15、1.25 |
未収集 |
1.45、0.364 |
|
平均ディスク キュー長 (SQL Server) |
66.765、27.314 |
129.032、20.665 |
182.110、11.816 |
|
最大ディスク キュー長 (SQL Server) |
4,201.185、5,497.980 |
3,050.015、762.542 |
1,833.765、775.7 |
|
ディスク キュー長: 書き込み (SQL Server): 平均 |
58.023、13.532 |
114.197、19.9 |
175.621、10.417 |
|
ディスク キュー長: 書き込み (SQL Server): 最大 |
1,005.691、881.892 |
1,551.437、761.891 |
1,018.642、768.289 |
|
|
ディスクの読み取り/秒 (SQL Server): 平均 |
245.945、94.131 |
未収集 |
137.435、154.103 |
ディスクの読み取り/秒 (SQL Server): 最大 |
6,420.412、6,450.870 |
未収集 |
3,863.283、1,494.805 |
|
ディスクの書き込み/秒 (SQL Server): 平均 |
458.144、286.884 |
未収集 |
984.668、278.175 |
|
ディスクの書き込み/秒 (SQL Server): 最大 |
2,990.779、5,164.949 |
未収集 |
2,666.285、4,105.897 |
|
アプリケーション サーバー |
平均ディスク キュー長 (クロール サーバー) |
0.052 |
0.043 |
0.030 |
ディスク キュー長: 書き込み (クロール サーバー) |
0.029 |
0.031 |
0.026 |
|
ディスクの読み取り/秒 (クロール サーバー) |
5.405 |
未収集 |
0.798 |
|
ディスクの書き込み/秒 (クロール サーバー) |
48.052 |
未収集 |
102.235 |
|
平均メモリ使用量 (クロール サーバー) |
68% |
45% |
52% |
|
最大メモリ使用量 (クロール サーバー) |
76% |
47% |
59% |
|
フロントエンド Web サーバー |
キューに入れられた ASP.NET 要求 (すべてのフロントエンド Web サーバーの平均) |
0 |
0 |
0 |
平均メモリ使用量 (フロントエンド Web サーバー) |
該当なし |
該当なし |
該当なし |
|
最大メモリ使用量 (フロントエンド Web サーバー) |
該当なし |
該当なし |
該当なし |
|
テスト結果 |
成功数 |
3,631,080 |
1,247,838 |
200,000 |
エラー数 |
7,930 |
304 |
0 |
|
ポータルのクロール速度 (アイテム/秒) |
82 |
148 |
81 |
|
アンカーのクロール速度 (アイテム/秒) |
1,573 |
1,580 |
1,149 |
|
合計クロール速度 (アイテム/秒) |
79 |
136 |
76 |
テスト データ
このセクションでは、ファームがロードの下でどのように実行されたかを示すテスト データについて説明します。
クエリの待機時間
次のグラフは、ユーザー ロードの増加に伴う、このファームのクエリ待機時間のパーセンタイルを示しています (クエリ スループット テスト中に収集された情報)。95 パーセントのクエリ パーセンタイルは、測定されたクエリ待機時間の 95 パーセントがその値よりも低いことを意味します。
.gif "ユーザー負荷がクエリ待機時間のパーセンタイルに与える影響")
インデックスが小さいと、多くの同時ユーザー (22) がこのファームでクエリを実行しても、このファームは 95 パーセンタイルで 1 秒未満のクエリ待機時間を維持できることがこのグラフからわかります。
クエリのスループット
次のグラフは、ユーザー ロードの増加に伴う、このファームのクエリのスループットを示しています (クエリ スループット テスト中に収集された情報)。
.gif "ユーザー負荷がクエリ スループットに与える影響")
この 2 つのグラフと以前のグラフを考慮すると、インデックス内のアイテム数が 3,300 万の場合、ファームは、約 30 の同時ユーザーと 75 パーセンタイルで 1 秒未満の遅延時間を維持できることがわかります。追加の同時ユーザーのロードに対応することはできますが、クエリの待機時間は増加して 1 秒を超えます。
ただし、インデックス内のアイテム数が 4,600 万の場合、追加の同時ユーザーのロードに対応する余裕はなく、クエリの待機時間は増加します。
クロール レート
次のグラフは、検索ライフ サイクルのインデックス取得ステージにおけるこのファームのクロール レートを示しています。この値はフル クロールを表しており、単位は 1 秒あたりにクロールされたアイテム数です。
.gif "コンテンツの種類別のフル クロール率")
SharePoint サイトのコンテンツ ソースを効果的にクロールするのに伴って発生した追加のオーバーヘッドによって、このファームの全体的なクロール レートが低下しています。
全体的な要点
このファームは、クエリ サーバーの RAM がいっぱいに近い状態でした。
このファームのパフォーマンスを向上するための次の手順は、次の処理を行うことです。
RAM を両方のクエリ サーバーに追加します。アクティブ クエリ コンポーネントのインデックス パーティションの 33 パーセントにオペレーティング システムとその他のプロセス用の 3 GB を加えた十分な RAM をクエリ サーバーに搭載することをお勧めします。
プロパティ データベースをホストするデータベース サーバーに RAM を追加します。この構成では、主なテーブルのサイズは約 92 GB (インデックスを含む) であったため、30 GB の RAM 要件が推奨されます。ただし、データベース サーバーには、プロパティ データベース、検索管理データベース、およびその他の SharePoint Server データベースを処理するための 32 GB の RAM のみが含まれていました。
ストレージ アレイを追加して、データベース サーバーでデータベースを分離できるようにします。
スケール アウトしてスループットを向上するか、クエリの待機時間を短縮するか、またはその両方を行います。
2 つのクロール データベースと 4 つのクロール コンポーネントが含まれるこのファームのクロール速度は高いものですが、インデックスの特定の部分をより新しいものにすることはファームにとって重要な目標となる可能性があります。特定の部分とは、非常に頻繁にクロールする必要のある特定のコンテンツです。必要なコンテンツ ソース内のホスト専用の別のクロール データベースを (ホストの割り当てルールと共に) 追加し、2 つの追加のクロール コンポーネントをそのデータベースに関連付けることで、インデックスの新しさの目標がサポートされます。
大規模ファーム
予期される構成では、次のように 1 つの Web サーバー、13 個のアプリケーション サーバー、3 つのデータベース サーバーを使用します。
1 つの Web サーバーは検索センターをホストするために使用します。Search Service アプリケーション プロキシ (コンテンツ ファームにインストールされている) を使用して検索がコンテンツ ファームから常に実行される場合、この Web サーバーは省略できます。
クロールと管理に 3 つのアプリケーション サーバーを使用します。これは、以下の状態を意味します。
サーバーの全体管理と検索管理コンポーネントは、1 つのアプリケーション サーバーに作成されます。
各サーバーに 2 つのクロール コンポーネントがあります。各クロール コンポーネントは、個別のクロール データベースに接続されます。
残りの 10 個のアプリケーション サーバーはクエリで使用します。推奨構成は、10 個のインデックス パーティションを含めることです。次に、別のインデックス パーティションからのフェールオーバー クエリ コンポーネントに加えて、1 つのインデックス パーティションからの 1 つのプライマリ クエリ コンポーネントを各サーバーに含めます。
4 つのデータベース サーバーでファームをサポートします。1 つのサーバーをプロパティ データベースと検索管理データベースで使用します。2 番目のサーバーをプロパティ データベースで使用します。3 番目のサーバーを 2 つのクロール データベースで使用します。4 番目のサーバーを 1 つのクロール データベースとその他の SharePoint データベースで使用します。データベース サーバーには、クロール データベース、プロパティ データベース、および検索管理データベースごとに専用の IOPS 数が設定される必要があります (たとえば、異なるストレージ アレイを使用する)。
仕様
このセクションでは、テスト環境のハードウェア、ソフトウェア、トポロジ、および構成の詳細について説明します。
トポロジ
このセクションでは、テスト環境のトポロジについて説明します。
.gif "検索の大規模ファーム トポロジ")
ハードウェア
このセクションでは、テストで使用されたハードウェアについて説明します。
注意
テスト ファームでは、プレリリース版の SharePoint Server 2010 が実行されており、チームは潜在的な問題を回避する必要があったため、サーバーには、通常必要とされるよりも大容量のハードウェアが使用されていました。
Web サーバー
| Web サーバー | フロントエンド Web サーバー (1) |
|---|---|
プロセッサ |
2px4c@2.33 GHz |
RAM |
8 GB |
オペレーティング システム |
Windows Server 2008 R2 64 ビット版 |
記憶域 |
2x148GB 15K SAS、RAID1、OS |
NIC の数 |
2 |
NIC の速度 |
1 ギガビット |
認証 |
NTLM |
ロード バランサーの種類 |
なし |
ソフトウェアのバージョン |
SharePoint Server 2010 (プレリリース版) |
ローカルで実行されているサービス |
すべてのサービス |
アプリケーション サーバー
ファームには 13 個のアプリケーション サーバーがあります。10 個のサーバーを使用してクエリを処理し、3 個のサーバーを使用してクロールを行います。
| サーバー (カウント) | クエリ (10) | クロール (2)、クロール/管理 (1) |
|---|---|---|
プロセッサ |
2px4c@2.5 GHz |
2px4c@2.5 GHz |
RAM |
32 GB |
32 GB |
オペレーティング システム |
Windows Server 2008 R2 64 ビット版 |
Windows Server 2008 R2 64 ビット版 |
記憶域 |
2x148GB 15K SAS、RAID1、OS 4x300GB 15K SAS、RAID10、データ |
2x148GB 15K SAS、RAID1、OS/データ |
NIC の数 |
2 |
2 |
NIC の速度 |
1 ギガビット |
1 ギガビット |
認証 |
NTLM |
NTLM |
ロード バランサーの種類 |
なし |
なし |
ソフトウェアのバージョン |
SharePoint Server 2010 (プレリリース版) |
SharePoint Server 2010 (プレリリース版) |
ローカルで実行されているサービス |
SharePoint Server Search、Search Query and Site Settings Service |
SharePoint Server Search |
データベース サーバー
4 つのデータベース サーバーがあります。1 番目のサーバーには、検索管理データベースとプロパティ データベースが含まれます。2 番目のサーバーには、プロパティ データベースが含まれます。3 番目には、2 つのクロール データベースが含まれます。4 番目には、クロール データベースと SharePoint データベースが含まれます。作成されたストレージ ボリュームによって、テストで使用可能な既存のハードウェアが最適化されました。
| データベース サーバー | 検索管理データベース、プロパティ データベース、SharePoint データベース | クロール データベース |
|---|---|---|
プロセッサ |
2px4c@3.2 GHz |
4px2c@2.19 GHz |
RAM |
32 GB |
16 GB |
オペレーティング システム |
Windows Server 2008 R2 64 ビット版 |
Windows Server 2008 R2 64 ビット版 |
記憶域 |
2x148GB 15K SAS、RAID1、OS 2x148GB 15K SAS、RAID1、TEMP ログ 2x450GB 15K SAS、RAID1、TEMP DB 6x450GB 15K SAS、RAID10、プロパティ DB 2x450GB 15K SAS、RAID1、検索管理、SharePoint DB 2x450GB 15K SAS、RAID1、Logs |
2x148GB 15K SAS、RAID1、OS 2x148GB 15K SAS、RAID1、TEMP ログ 2x300GB 15K SAS、RAID1、TEMP DB 6x146GB 15K SAS、RAID10、クロール DB1 6x146GB 15K SAS、RAID10、クロール DB2 2x300GB 15K SAS、RAID1、Crawl DB ログ 1 2x300GB 15K SAS、RAID1、Crawl DB ログ 2 |
NIC の数 |
2 |
2 |
NIC の速度 |
1 ギガビット |
1 ギガビット |
認証 |
NTLM |
NTLM |
ソフトウェアのバージョン |
SQL Server 2008 Enterprise |
SQL Server 2008 Enterprise |
クエリ パフォーマンスのデータ
以下の測定値は、インデックス内にある 1 億 300 万アイテムを使用して取得されました。各列には特定のテスト中に取得された測定値が示されており、結果は表の下部に示されています。取得された各測定値の説明は以下のとおりです。
クエリの待機時間 これらの測定値は、クエリの待機時間テスト中に取得されました。このテストでは、テスト ツールが 1 つのユーザーとしてクエリの標準セットを送信し、結果の待機時間が測定されました。テスト中にクロールは実行されていませんでした。
クエリのスループット これらの測定値は、クエリのスループット テスト中に取得されました。このテストでは、テスト ツールが、同時ユーザー数を増加 (最大で 120) しながらクエリの標準セットをファームに対して送信し、結果の待機時間とスループットが測定されました。テスト中にクロールは実行されていませんでした。
| スコアカード測定基準 | クエリのスループット | |
|---|---|---|
CPU 測定基準 |
平均 SQL Server CPU (プロパティ データベース サーバー) |
34% |
平均フロントエンド Web サーバー CPU |
45% |
|
平均クエリ サーバー CPU |
20% |
|
信頼性 |
失敗率 |
0% |
フロントエンド Web サーバーのクラッシュ |
0 |
|
アプリケーション サーバーのクラッシュ |
0 |
|
SQL Server (プロパティ データベース サーバー) |
キャッシュ ヒット率 (SQL Server) |
100% |
SQL Server のロック: 平均待機時間 (ミリ秒) |
0 |
|
SQL Server のロック: ロック待機時間 (ミリ秒) |
0 |
|
SQL Server のロック: デッドロック/秒 |
0 |
|
SQL Server のラッチ: 平均待機時間 (ミリ秒) |
1.401 |
|
SQL Server のコンパイル/秒 |
73.349 |
|
SQL Server の統計情報: SQL Server 再コンパイル/秒 |
0.006 |
|
読み取り/書き込みの比率 (データベースあたりの IO) |
0.81 |
|
平均ディスク キュー長 (SQL Server) |
0.037 |
|
ディスク キュー長: 書き込み (SQL Server) |
0.003 |
|
|
ディスクの読み取り/秒 (SQL Server) |
9.88 |
ディスクの書き込み/秒 (SQL Server) |
354.1 |
|
アプリケーション サーバー |
平均ディスク キュー長 (クエリ サーバー) |
0.002 |
ディスク キュー長: 書き込み (クエリ サーバー) |
0.002 |
|
ディスクの読み取り/秒 (クエリ サーバー) |
0.035 |
|
ディスクの書き込み/秒 (クエリ サーバー) |
6.575 |
|
平均メモリ使用量 (クエリ サーバー) |
6.548% |
|
最大メモリ使用量 (クエリ サーバー) |
6.601% |
|
フロントエンド Web サーバー |
キューに入れられた ASP.NET 要求 (すべてのフロントエンド Web サーバーの平均) |
0 |
平均メモリ使用量 (フロントエンド Web サーバー) |
18.081% |
|
最大メモリ使用量 (フロントエンド Web サーバー) |
19.983% |
|
テスト結果 |
成功数 |
10,925 |
エラー数 |
0 |
|
クエリ UI の待機時間 (75 パーセンタイル) |
3.431 秒 |
|
クエリ UI の待機時間 (95 パーセンタイル) |
3.512 秒 |
|
クエリのスループット |
36.42 要求/秒 |
クロールのパフォーマンス データ
以下の測定値は、特定のコンテンツ ソースの最初の順次的なフル クロール中に取得されました。コンテンツのサイズは数百万アイテム単位で与えられています。各列には特定のクロール中に取得された測定値が示されており、結果は以下の表の下部に示されています。
| スコアカード測定基準 | SharePoint コンテンツ (350 万) | ファイル共有 (100 万) | |
|---|---|---|---|
CPU 測定基準 |
平均 SQL Server CPU (クロール データベース サーバー、プロパティ データベース サーバー) |
15.74%、該当なし |
24%、6.6% |
最大 SQL Server CPU (クロール データベース サーバー、プロパティ データベース サーバー) |
100%、該当なし |
100%、45% |
|
平均インデクサー CPU |
44% |
49% |
|
信頼性 |
失敗率 |
0.0% |
0.00% |
フロントエンド Web サーバーのクラッシュ |
0 |
0 |
|
アプリケーション サーバーのクラッシュ |
0 |
0 |
|
SQL Server (クロール データベース サーバー、プロパティ データベース サーバー) |
キャッシュ ヒット率 (SQL Server) |
99.8%、該当なし |
99.797%、99.49% |
SQL Server のロック: 平均待機時間 [ミリ秒] |
734.916、該当なし |
1,165、5.866 |
|
SQL Server のロック: 最大待機時間 [ミリ秒] |
15,335、該当なし |
28,683、210.5 |
|
SQL Server のロック: 平均ロック待機時間 [ミリ秒] |
108.98、該当なし |
847.72、5.325 |
|
SQL Server のロック: 最大ロック待機時間 [ミリ秒] |
17,236.96、該当なし |
124,353、12,920 |
|
SQL Server のロック: デッドロック/秒 |
0、該当なし |
.012、0 |
|
SQL Server のラッチ: 平均待機時間 [ミリ秒] |
1.4、該当なし |
2.233、40.6 |
|
SQL Server のラッチ: 最大待機時間 [ミリ秒] |
1,606、該当なし |
917.8、1,895 |
|
SQL Server のコンパイル/秒: 平均 |
24.28、該当なし |
72.7、11.39 |
|
SQL Server のコンパイル/秒: 最大 |
416、該当なし |
460、76.62 |
|
SQL Server の統計情報: SQL Server の再コンパイル/秒: 平均 |
0.560、該当なし |
0.295, .099 |
|
SQL Server の統計情報: SQL Server の再コンパイル/秒: 最大 |
0.24、該当なし |
17.50、17.393 |
|
読み取り/書き込みの比率 (データベースあたりの IO): 最大 |
20.3、該当なし |
1.18/.214 |
|
平均ディスク キュー長 (SQL Server) |
90.113、該当なし |
138.64、27.478 |
|
最大ディスク キュー長 (SQL Server) |
3,179、該当なし |
2,783.543、847.574 |
|
ディスク キュー長: 書き込み (SQL Server): 平均 |
86.93、該当なし |
130,853、26.086 |
|
ディスク キュー長: 書き込み (SQL Server): 最大 |
1,882、該当なし |
2,781.197、884.801 |
|
|
ディスクの読み取り/秒 (SQL Server): 平均 |
99、該当なし |
147.462、159.159 |
ディスクの読み取り/秒 (SQL Server): 最大 |
3,772、該当なし |
2,403.336、896.462 |
|
ディスクの書き込み/秒 (SQL Server): 平均 |
373、該当なし |
475.886、539.497 |
|
ディスクの書き込み/秒 (SQL Server): 最大 |
18,522、該当なし |
2,031.888、4,174.271 |
|
アプリケーション サーバー |
平均ディスク キュー長 (クロール サーバー) |
0.075 |
.063 |
ディスク キュー長: 書き込み (クロール サーバー) |
0.046 |
0.053 |
|
ディスクの読み取り/秒 (クロール サーバー) |
1.958 |
1.693 |
|
ディスクの書き込み/秒 (クロール サーバー) |
62.33 |
101.093 |
|
平均メモリ使用量 (クロール サーバー) |
59% |
56.38% |
|
最大メモリ使用量 (クロール サーバー) |
70% |
58.93% |
|
フロントエンド Web サーバー |
キューに入れられた ASP.NET 要求 (すべてのフロントエンド Web サーバーの平均) |
該当なし |
該当なし |
平均メモリ使用量 (フロントエンド Web サーバー) |
該当なし |
該当なし |
|
最大メモリ使用量 (フロントエンド Web サーバー) |
該当なし |
該当なし |
|
テスト結果 |
成功数 |
1,909,739 |
1,247,838 |
エラー数 |
9,361 |
331 |
|
ポータルのクロール速度 (アイテム/秒) |
70.3 |
131.44 |
|
アンカーのクロール速度 (アイテム/秒) |
764 |
525.84 |
|
合計クロール速度 (アイテム/秒) |
64 |
105 |
推奨事項とトラブルシューティング
以下のセクションでは、以上のシナリオに似た環境を展開するために必要なハードウェア、トポロジ、および構成を決定する方法に関する推奨事項と、適切な容量とパフォーマンスの特性に合わせた環境の最適化方法に関する推奨事項について説明します。
推奨事項
このセクションでは、適切な容量とパフォーマンスの特性に合わせて環境を最適化するために実行する必要のある特定の処理について説明します。
ハードウェアに関する推奨事項
システムの全体的な最小要件と推奨要件の詳細については、「ハードウェア要件およびソフトウェア要件 (SharePoint Server 2010)」を参照してください。検索で使用されたサーバーの要件は、全体的なシステム要件よりも優先されます。RAM、プロセッサ、および IOPS に関する以下の推奨ガイドラインを使用してパフォーマンスの目標を満たします。
検索のサイジング
このセクションでは、コンポーネントごとに、サイジングの要件とガイドラインを含め、検索システムについて説明します。
SharePoint Server 2010 はさまざまな方法で展開および構成できます。そのため、特定のサーバー数でサポートできるユーザーまたはアイテムの数を簡単に見積もる方法はありません。したがって、SharePoint Server 2010 を運用環境に展開する前に必ず独自の環境でテストを実施してください。
検索クエリ システム
このセクションでは、特定の Search Service アプリケーション用の検索クエリ システムのコンポーネントについて説明します。各コンポーネントのサイジング要件については、次の図の後にある「スケーリングの詳細」表で説明します。
.gif "検索クエリ システム")
オブジェクトの説明
前記の図に示された検索クエリ システムの各オブジェクトの定義を以下に示します。
検索プロキシ この Search Service アプリケーションからの検索を使用するすべてのファームにインストールされる Search Service アプリケーション プロキシです。これは、Search Service アプリケーション プロキシに関連付けられる Web アプリケーションのコンテキストで実行されます。
Search Query and Site Settings Service これはクエリ プロセッサとも呼ばれます。Search Service アプリケーションのプロキシ接続からクエリを受信すると、クエリ プロセッサは以下の処理を実行します。
各インデックス パーティションの 1 つのアクティブ クエリ コンポーネント (またはプロパティ データベース、あるいは両方。クエリによる) にクエリを送信します。
おすすめコンテンツを取得し、重複を削除して、結果セットを取得します。
検索管理データベース内のセキュリティ記述子に基づいて、セキュリティによる結果のトリミングを行います。
プロパティ データベースから最終結果セットのメタデータを取得します。
クエリ結果をプロキシに返します。
インデックス パーティション これはクエリ コンポーネントの論理グループであり、フルテキスト インデックスのサブセットを表します。すべてのインデックス パーティションが集約されてフルテキスト インデックスが構成されます。ただし、インデックスの実際のサブセットはクエリ コンポーネントに含まれます。インデックス パーティションは、1 つのプロパティ データベースに関連付けられます。
検索クエリ コンポーネント クエリ コンポーネントには、フルテキスト インデックスの全部または一部が含まれます。クエリ プロセッサによってクエリが実行されると、クエリ コンポーネントはそのインデックスから最適な結果を決定してそのアイテムを返します。クエリ コンポーネントは以下のどちらかの状態で作成できます。
アクティブ。クエリ コンポーネントは既定でクエリに応答します。同じインデックス パーティションに対して複数のアクティブ クエリ コンポーネントを追加すると、スループットが向上します。
フェールオーバー。同じインデックス パーティションに対するすべてのアクティブ コンポーネントが失敗した場合にのみ、クエリに応答します。
検索管理データベース Search Service アプリケーションと同時に作成されます。検索管理データベースには、管理で使用するアプリケーション設定に加えて、おすすめコンテンツなどのクエリで使用する Search Service アプリケーション規模のデータ、およびセキュリティ記述子が含まれます。
プロパティ データベース プロパティ データベースには、インデックス内のアイテムのメタデータ (タイトル、作成者、関連フィールド) が含まれます。プロパティ データベースは、最終結果の表示に必要なメタデータの取得に加えて、プロパティ ベースのクエリでも使用されます。複数のインデックス パーティションが存在する場合、異なるプロパティ データベースにインデックス パーティションをマップできます。
スケーリングの詳細
| オブジェクト | スケールに関する考慮事項 | RAM | IOPS (読み取り/書き込み) |
|---|---|---|---|
検索プロキシ |
検索プロキシは、自身に関連付けられているフロントエンド Web サーバーと共にスケーリングされます。 |
該当なし |
該当なし |
Search Query and Site Settings Service |
このサービス (サーバーの全体管理の [サーバーのサービス] ページでインストールする) は、クエリ コンポーネントが含まれる各サーバーで開始する必要があります。このサービスを独立したサーバー (または可用性を向上するためのペア) に移動することで、クエリ コンポーネントが含まれるサーバー上の RAM の使用を回避できます。また、カスタム セキュリティ トリマーを使用する場合、CPU と RAM リソースに影響する可能性があります。 |
これは、インデックスのセキュリティ記述子をキャッシュするために RAM (プロセス キャッシュ) を使用します。 |
該当なし |
インデックス パーティション |
インデックス パーティションの数が増加すると、インデックス パーティション内のアイテム数が減少します。また、これにより、インデックス パーティションに割り当てられたクエリ コンポーネントをホストするクエリ サーバーで必要とされる RAM とディスク領域が減少します。 |
該当なし |
該当なし |
クエリ コンポーネント |
サーバー上の各アクティブ クエリ コンポーネントは、クエリを処理するときにメモリを使用します。各アクティブ クエリ コンポーネントは、Search Service アプリケーションのトポロジの一部として作成または変更されます。アクティブ コンポーネントとフェールオーバー コンポーネントは、クロールが実行されているときに IO を使用します。RAM と IO 要件が満たされている場合、サーバーをクエリ コンポーネント専用とすることができます (例: 2 つのアクティブと 2 つのフェールオーバーを同じサーバー上に配置する)。 可能な場合は、1 つのサーバーの 1 つのアクティブ コンポーネントごとに 2 つ以上の CPU コアを専用に使用し、1 つのサーバーの 1 つのフェールオーバー コンポーネントごとに 1 つ以上の CPU を専用に使用します。 |
アプリケーション サーバー上の各アクティブ クエリ コンポーネントについて、そのインデックスの 33% が RAM (オペレーティング システム キャッシュ) に含まれる必要があります。 |
特定のサーバー上のクエリ コンポーネントのペア (アクティブ/フェールオーバー) ごとに 2K が必要です。 クエリ コンポーネントは、以下の処理のために IO を必要とします。 クエリのためにインデックスを RAM に読み込む 各クロール コンポーネントから受け取ったインデックス フラグメントを書き込む マスター結合時など、インデックス フラグメントをそのインデックスに結合する |
検索管理データベース |
クエリごとに、おすすめコンテンツとセキュリティ記述子が検索管理データベースから読み込まれます。キャッシュでこれを処理するための十分な RAM がデータベース サーバーにあることを確認してください。可能な場合は、クロール データベースが含まれるサーバーにこれを配置することを避けてください。クロール データベースは、そのデータベース サーバーのキャッシュをリセットする傾向があるためです。 |
重要なテーブル (MSSSecurityDescriptors) を RAM に保持するために、十分な RAM がデータベース サーバーにあることを確認してください。 |
700 |
プロパティ データベース |
クエリごとに、ドキュメント結果のプロパティ データベースからメタデータが取得されます。したがって、RAM をデータベース サーバーに追加してパフォーマンスを向上できます。複数のインデックス パーティションが存在する場合、プロパティ データベースをパーティション分割し、異なるデータベース サーバーに移動して、RAM と IO の要件を減少できます。 |
重要なテーブル (MSSDocSDIDs + MSSDocProps + MSSDocresults) の 33% をキャッシュに保持するのに十分な RAM がデータベース サーバーにあることを確認してください。 |
2 K 30% 読み取り、70% 書き込み |
検索クロール システム
このセクションでは、検索クロール システムのコンポーネントについて説明します。各コンポーネントのサイジング要件については、図の後の表で説明します。
.gif "検索クロール システム")
オブジェクトの説明
このセクションでは、前記の図に示された検索クロール システムの各オブジェクトを定義します。
管理コンポーネント 管理コンポーネントは、クロール システムで管理タスクが実行されるときに使用されるのに加えて、クロールが開始されるときにも使用されます。
クロール コンポーネント クロール コンポーネントは、クロールを処理し、結果のインデックス フラグメント ファイルをクエリ コンポーネントに伝達して、コンテンツ ソースの場所とクロール スケジュールに関する情報を、関連付けられたクロール データベースに追加します。
検索管理データベース 検索管理データベース (Search Service アプリケーションと同時に作成される) には、管理で使用されるアプリケーション設定に加えて、クロール中に検出されたセキュリティ記述子が格納されます。
クロール データベース クロール データベースには、コンテンツ ソースの場所、クロール スケジュール、クロール操作に固有のその他の情報に関連するデータが含まれます。ホストの割り当てルールを作成することで、クロール データベースを特定のホスト専用とすることができます。クロール データベースにはデータのみが格納されます。特定のクロール データベースに関連付けられたクロール コンポーネントがクロールを行います。
検索クエリ システム
スケーリングの詳細
| オブジェクト | スケールに関する考慮事項 | RAM | IOPS (オプション、% 読み取り/書き込み) |
|---|---|---|---|
管理コンポーネント |
この単一の管理コンポーネントはスケーラブルではありません。既定では、これは、クロール コンポーネント (および、小規模ファームの場合は、サーバーの全体管理) をホストするサーバーに配置されます。 |
最小 |
最小 |
クロール コンポーネント |
クロール コンポーネントは、CPU 帯域幅を積極的に使用します。特定のクロール コンポーネントは、4 つの CPU コアを最適に使用できます。RAM はそれほど重要ではありません。大規模ファームでは、サーバーをホストのクロール コンポーネント専用とすることで、その他のコンポーネントへのクローラーの影響を最小限に抑えることができます (特に、冗長性を確保する必要がある場合は、異なるクロール データベースに関連付けられたクロール コンポーネントを使用します)。 |
中程度。東アジアのドキュメントをクロールする場合、ワード ブレーカーのために RAM 要件が増加します。 |
300 ～ 400 |
検索管理データベース |
上記の「検索クエリ システム」を参照してください。可能な場合は、クロール データベースが含まれるサーバーにこれを配置することを避けてください。クロール データベースは、そのデータベース サーバーのキャッシュをリセットする傾向があるためです。 |
上記の「検索クエリ システム」を参照してください。 |
700 |
クロール データベース |
クロール データベースは IO 帯域幅を積極的に使用します。RAM はそれほど重要ではありません。クロール データベースでは、クロール アクティビティのために 3.5K の IOPS が必要です。クロール データベースは、使用可能な帯域幅に基づいて 6K の IOPS を使用します。 |
中程度 |
3.5 ～ 7K 73% 読み取り、27% 書き込み |
ストレージ サイジングを計算する
以下の要因を計算して、ストレージ要件の見積もりに役立てます。サイジングの要因は、SharePoint コンテンツ (コンテンツ データベースのサイズは 13.3 テラバイト) を主に含むインデックスを持つ展開前の内部システムに基づきます。全般に、SharePoint 検索では、コンテンツ データベースのディスク領域の約 20 パーセントが必要とされました。前述のとおり、SharePoint Server 2010 を運用環境に展開する前に、独自の環境でテストを必ず実行してください。
注意事項:
これらの数値を得るために使用されたコーパスは、主に、(英語の) SharePoint コンテンツでした。したがって、使用するコンテンツが異なる場合 (例: 大部分がファイル共有または SharePoint 以外の HTTP サイトで構成される場合)、さらなるバリエーションを許容する必要があります。
コンテンツが主に SharePoint コンテンツの場合であっても、以下のような状況では係数を変更できます。
大規模なドキュメント リポジトリがある場合、係数は大幅に増加します。
コンテンツが主に画像の場合、係数を減少できる場合があります。
異なる言語のコンテンツは係数に影響する可能性があります。
1. コンテンツ データベースのサイジング要因を計算します (ContentDBSum)
クロールされる SharePoint コンテンツ データベースの合計を求めます。これは、次のストレージ計算で相関関係として使用される ContentDBSum 値です。
2. インデックス関連のサイズを計算します (TotalIndexSize と QueryComponentIndexSize)
合計インデックス (クエリ コンポーネント上にあり、フルテキスト クエリで使用されます) のサイズを求めます。
ContentDBSum に 0.035 を掛けます。これは、結合やパーティション再分割のために領域のパーティション分割や予約を行う前の TotalIndexSize です。
次に、使用するシナリオに基づいて、用意するインデックス パーティションの数を求めます。一般的なガイドラインとして、1 つのインデックス パーティションに 500 万～ 1,000 万アイテムを含めます。インデックス パーティションの数が決まると、クエリ コンポーネント ストレージのサイズを計算できます。
TotalIndexSize を (インデックス パーティションの数) で割ります。これは、QueryComponentIndexSize です。これを使用して以下のサイズを計算します。
RAM の場合、QueryComponentIndexSize に 0.33 を掛けます。これは、このクエリ コンポーネントがアクティブの場合に必要とされる RAM の最小値です。
コンポーネントがフェールオーバー コンポーネントの場合、そのコンポーネントがアクティブになるまで RAM は必要ありません。
特定のサーバーの場合、複数のアクティブ クエリ コンポーネントを同じサーバー上に配置することで、各アクティブ クエリ コンポーネントの RAM を合計してサーバーの RAM のニーズに達するようにすることが必要になります。
ディスク ストレージの場合、以下の方法で QueryComponentIndexSize を使用し、ディスクの要件を見積もります。方法は、インデックスのパーティション再分割を行う (つまり、パーティション境界ごとのインデックスが 1,000 万より増大することが予想される) かどうかによって決まります
QueryComponentIndexSize に 3 を掛けて、1 つのクエリ コンポーネントのディスク ストレージを計算し、インデックス結合のための場所を確保します。
QueryComponentIndexSize に 4 を掛けて、1 つのクエリ コンポーネントのディスク ストレージを計算し、インデックスのパーティション再分割のための場所を確保します。
特定のサーバーの場合、複数のクエリ コンポーネントを同じサーバー上に配置することで、クエリ コンポーネントごとにストレージを準備することが必要になります。ただし、この記事の前半の「検索クエリ システム」セクションの「スケーリングの詳細」セクションで示された IOPS 要件を前提とします。
3. プロパティ データベースのサイズを計算します
以下の方法で、プロパティ データベースのサイズを求めます。
ContentDBSum に 0.015 を掛けます。これは、パーティション分割前の TotalPropertyDBSize です。
ContentDBSum に 0.0031 を掛けます。これは、パーティション分割前の TotalPropertyDBLogSize です。これは、SQL Server データベースの単純な復旧モデルを使用することを前提とします。
ContentDBSum に 0.00034 を掛けます。これは、プロパティ データベースの TempDBSize です。プロパティ データベース内の主なテーブルの 33 パーセントを RAM 内に含めることが推奨されているため、一時データベースを使用しても大きい負荷になりません。
次に、使用するシナリオに基づいて、用意するプロパティ データベースの数を求めます。一般的なガイドラインとして、プロパティ データベースに最大で 5,000 万アイテムを含めます。ただし、クエリのパフォーマンスの問題がないこと、および管理プロパティの数が制限されていること (標準構成) を前提とします。
TotalPropertyDBSize を (プロパティ データベースの数) で割ります。これは、PropertyDatabaseSize です。
TotalPropertyDBLogSize を (プロパティ データベースの数) で割ります。これは、PropertyDatabaseLogSize です。
RAM の場合、PropertyDatabaseSize に 0.33 を掛けます。これは、このプロパティ データベースの RAM の推奨最小値です。
特定のデータベース サーバーの場合、複数のプロパティ データベースを同じサーバー上に配置することで、プロパティ データベースごとにストレージと RAM を準備することが必要になります。ただし、この記事の前半の「検索クエリ システム」セクションの「スケーリングの詳細」セクションで示された IOPS と RAM の要件を前提とします。
4. クロール データベースのサイズを計算します
次に、以下の方法で、クロール データベースで必要なサイズを求めます。
ContentDBSum に 0.046 を掛けます。これは、パーティション分割前の TotalCrawlDBSize です。
ContentDBSum に 0.011 を掛けます。これは、パーティション分割前の TotalCrawlDBLogSize です。これは、SQL Server データベースの単純な復旧モデルを使用することを前提とします。
ContentDBSum に 0.0011 を掛けます。これは、クロール データベースの TempDBSize です。検索クロール システムは一時データベースのパフォーマンスに影響します。したがって、クロール データベースまたはこの使用により影響を受けるデータベースをホストするサーバーに他のデータベースを配置しないことをお勧めします。
次に、使用するシナリオに基づいて、用意するクロール データベースの数を求めます。一般的なガイドラインとして、クロール データベースに最大で 2,500 万アイテムを含めます。ただし、クロールのパフォーマンスの問題がないことを前提とします。
TotalCrawlDBSize を (クロール データベースの数) で割ります。これは、CrawlDatabaseSize です。
TotalCrawlDBLogSize を (クロール データベースの数) で割ります。これは、CrawlDatabaseLogSize です。
特定のデータベース サーバーの場合、複数のクロール データベースを同じサーバー上に配置することで、クロール データベースごとにストレージを準備することが必要になります。ただし、この記事の前半の「検索クロール システム」セクションの「スケーリングの詳細」セクションで示された IOPS 要件を前提とします。RAM の場合、クロール データベース専用のデータベース サーバーに 16GB 以上搭載することをお勧めします。
5. 検索管理データベースのサイズを計算します
以下の方法で、検索管理データベース (Windows 認証を前提とする) のサイズを求めます。
インデックス内のアイテム数 (100 万単位) に 0.3 を掛けます。これは、SearchAdminDBSize です。
RAM の場合、SearchAdminDBSize に 0.33 を掛けます。これは、この検索管理データベースの RAM の推奨最小値です。
特定のデータベース サーバーの場合、複数のデータベースを同じサーバー上に配置することで、データベースごとにストレージと RAM を準備することが必要になります。ただし、この記事の前半の「検索クエリ システム」セクションの「スケーリングの詳細」セクションで示された IOPS と RAM の要件を前提とします。
オプション: バックアップ サイズを計算します
1 つの Search Service アプリケーションをバックアップするために必要なディスク領域を求めるには、以下の計算を実行します。
- TotalCrawlDBSize + TotalPropertyDBSize + TotalIndexSize + SearchAdminDBSize = 基本バックアップ サイズ。
この基本バックアップサイズが開始点になります。これは、以下の影響も受けます。
最後のマスター結合以降に実行されたすべてのクロールの TotalIndexSize に含まれる追加のインデックス サイズ。
アイテム、クエリ、およびセキュリティ記述子の追加による経時的な拡大。
また、次回のバックアップのための領域を予約するのに加えて、異なる時点の複数のバックアップを保持することが必要になる可能性があります。
サイジング
前述のサイジング要因を使用し、以下の手順に従って、主に SharePoint コンテンツに対するクエリを処理する 1 億アイテムのファームのサイジングを行います。大規模ファームのシナリオを使用する場合、以下の前提条件があります。
1 億アイテムに対応する論理インデックス パーティションが必要です。
クエリを処理するには、10 個のアクティブ クエリ コンポーネント (インデックス パーティションごとに 1 個) が必要です。
クエリの冗長性は重要です。したがって、10 個のフェールオーバー クエリ コンポーネント (インデックス パーティションごとに 1 個) を用意します (これは、アクティブ コンポーネントとは異なるサーバーに配置します)。
ストレージと RAM のニーズを求めるには、以下の手順を実行します。
複数のコンテンツ データベースが含まれる SharePoint コンテンツ ファームで、クロールするコンテンツ データベースを合わせると 20 テラバイトになります。
上述のインデックス係数を使用して、20 テラバイトに 0.035 (インデックス係数) を掛けると 716.8 GB になります。これは、TotalIndexSize です。パーティションが 1 つのみの場合、これが停止時のインデックスのサイズになります。
TotalIndexSize をパーティションの数で割ります。716.8 GB / 71.68 GB。これは、1 つのインデックス パーティションの 1 つのクエリ コンポーネントで必要なインデックス サイズ (QueryComponentIndexSize) です。アクティブ クエリ コンポーネントとフェールオーバー クエリ コンポーネントのどちらもこのサイズは同じです。
パーティションの再分割を予定している場合は TotalIndexSize に 4 を掛けて、そうでない場合はマスター結合をサポートするように 3 を掛けます。71.68 GB * 4 = 286.72 GB。1 つのクエリ コンポーネントをサポートするには、クエリ サーバーのディスクで 286.72 GB を使用できるようにする必要があります。2 つのクエリ コンポーネントを同じアプリケーション サーバーに配置する場合 (大規模ファームのシナリオで推奨されているアクティブ/フェールオーバーのトポロジの場合)、ディスク ドライブ レイアウトを以下のように用意します。
オペレーティング システムのドライブ (標準サイズ)。
追加のストレージ システム 1: Query Component1_Share (300 GB 以上のサイズ)、インデックス パーティション 1 からのアクティブ クエリ コンポーネントで使用します。
追加のストレージ システム 2: Query Component2_Share (300 GB 以上のサイズ)、インデックス パーティション 2 からのフェールオーバー (ミラー) クエリ コンポーネントで使用します。
注意
1 つのアクティブ クエリ コンポーネントが含まれるこのアプリケーション サーバーで、クエリのほとんどをキャッシュするには、オペレーティング システムに最小で 71.68 GB * 0.33 = 23.65 GB + 3 GB の RAM が必要になります (弊社では 33 GB を使用)。
ソフトウェアの制限
次の表に、許容可能な検索機能をサポートするために課されるソフトウェアの境界を示します。
| オブジェクト | 制限 | 備考 |
|---|---|---|
SharePoint Search Service アプリケーション |
ファームごとの推奨最大数は 20 個。合計サービス アプリケーションの絶対最大数は 256 個。 |
検索のコンポーネントとデータベースを別個のサーバーに割り当てることができるので、同じファームに複数の Search Service アプリケーションを展開できます。 |
インデックス付けされたドキュメント |
アイテム全体の推奨最大数は、インデックス パーティションごとに 1,000 万個、Search Service アプリケーションごとに 1 億個。 |
SharePoint 検索ではインデックス パーティションがサポートされます。各インデックス パーティションには、検索インデックス全体のサブセットが含まれます。1 つのパーティションのアイテムの推奨最大数は 1,000 万個です。ユーザー、リスト アイテム、ドキュメント、Web ページを含む、アイテム全体の推奨最大数は 1 億個です。 |
インデックス パーティション |
Search Service アプリケーションごとの推奨最大数は 20 個。 |
このインデックス パーティションは、Search Service アプリケーションのインデックスの論理サブセットです。推奨制限値は 20 個です。インデックス パーティションの数が増加すると、インデックス パーティション内のアイテム数が減少し、インデックス パーティションに割り当てられたクエリ コンポーネントをホストするクエリ サーバーで必要とされる RAM とディスク領域が減少します。ただし、これが関連性に影響する可能性があります。インデックス パーティション内のアイテム数が減少するためです。インデックス パーティションのハード リミットは 128 個です。 |
プロパティ データベース |
Search Service アプリケーションごとの推奨制限値は 10 個。 |
プロパティ データベースには、関連付けられている各インデックス パーティション内のアイテムのメタデータが保存されます。1 つのインデックス パーティションは、1 つのプロパティ ストアのみと関連付けることができます。Search Service アプリケーションごとの推奨制限値は 10 個です。ハード リミットは 255 個です (インデックス パーティションと同じ)。 |
クロール データベース |
アプリケーションごとのクロール データベース数の制限値は 32 個。 |
クロール データベースには、クロールされたすべてのアイテムに関するクロール データ (時刻、状態を含む) が保存されます。推奨制限値は、クロール データベースごとに 2,500 万アイテム、または Search Service アプリケーションごとに合計で 4 個のデータベースです。 |
クロール コンポーネント |
アプリケーションごとの推奨制限値は合計で 16 個のクロール コンポーネント、クロール データベースごとの推奨制限値は 2 個、(サーバーに少なくとも 8 個のプロセッサ (コア) があることを前提とした場合) サーバーごとの推奨制限値は 2 個。 |
伝達 I/O の低下を最小限にするには、サーバーごとのクロール コンポーネントの合計数を 128 個 (クエリ コンポーネントの合計数) 未満にする必要があります。推奨制限値を超えると、クロールのパフォーマンスが向上しなくなる可能性があります。実際には、クロール サーバー、データベース、およびコンテンツ ホスト上の使用可能なリソースに基づいてクロールのパフォーマンスが低下することがあります。 |
クエリ コンポーネント |
推奨制限値は、アプリケーションごとに 128 個、サーバーごとに 64 個 (クロール コンポーネントの合計数)。 |
クエリ コンポーネントの合計数は、クロール コンポーネントがファイルをコピーする能力によって制限されます。サーバーごとのクエリ コンポーネントの最大数は、クロール コンポーネントから伝達されたファイルをクエリ コンポーネントが吸収する能力によって制限されます。 |
同時クロール |
Search Service アプリケーションごとのクロール数の推奨制限値は 20 個。 |
これは、同時に実行されるクロールの数です。クロールは非常に高コストの検索タスクであり、他のアプリケーションのロードに加えて、データベースのロードにも影響する可能性があります。同時クロール数が 20 個を超えると、全体的なクロール レートが低下する可能性があります。 |
コンテンツ ソース |
Search Service アプリケーションごとのコンテンツ ソース数の推奨制限値は 50 個。 |
Search Service アプリケーションごとの推奨制限値を超えて、500 個のハード リミットまで増やすことができます。ただし、使用する開始アドレスの数を少なくし、同時クロール数の制限に従う必要があります。 |
開始アドレス |
コンテンツ ソースごとの開始アドレス数の推奨制限値は 100 個。 |
コンテンツ ソースごとの推奨制限値を超えて、500 個のハード リミットまで増やすことができます。ただし、使用するコンテンツ ソースの数を少なくする必要があります。開始アドレスが多数ある場合は、それらを HTML ページにリンクとして配置し、そのリンクに従ってページを HTTP クローラーでクロールする方法をお勧めします。 |
クロール ルール |
Search Service アプリケーションごとの推奨制限値は 100 個。 |
推奨値を超えることはできますが、検索管理でのクロール ルールの表示が正常に実行されなくなります。 |
クロール ログ |
アプリケーションごとの推奨制限値は 1 億個。 |
これは、クロール ログ内のログ エントリの個数です。インデックス付けされたドキュメントの制限に従います。 |
アイテムごとに認識されるメタデータ プロパティ |
ハード リミットは 1 万個。 |
これは、アイテムがクロールされるときに認識される可能性のある (さらにマップされたりクエリで使用されたりする可能性のある) メタデータ プロパティの数です。 |
クロールされたプロパティ |
Search Service アプリケーションごとに 50 万個。 |
これは、クロール中に発見されたプロパティの数です。 |
管理プロパティ |
Search Service アプリケーションごとに 10 万個。 |
これは検索システムによってクエリで使用されるプロパティです。クロールされたプロパティは管理プロパティにマップされます。管理プロパティごとに最大マップ数を 100 個にすることをお勧めします。この制限値を超えると、クロール速度とクエリ パフォーマンスが低下することがあります。 |
範囲 |
サイトごとの推奨制限値は 200 個。 |
これはサイトごとの推奨制限値です。この制限を超えると、範囲が表示グループに追加されている場合にエンド ユーザーのブラウザーの待機時間に影響することに加えて、クロールの効率が低下することがあります。また、範囲数が推奨制限値を超えて増加するにつれて、検索管理での範囲の表示が正常に実行されなくなります。 |
表示グループ |
サイトごとに 25 個。 |
これは、ユーザー インターフェイスで範囲をグループ別に表示するために使用します。この制限を超えると、検索管理における範囲機能が正常に実行されなくなり始めます。 |
範囲ルール |
範囲ルール数の推奨制限値は、範囲ごとに 100 個、Search Service アプリケーションごとに合計で 600 個。 |
この制限を超えると、鮮度が低下し、範囲指定されたクエリからの潜在的な結果に遅延が発生します。 |
キーワード |
サイト コレクションごとの推奨制限値は 200 個。 |
この推奨制限値を超えて、サイト コレクションごとにキーワード数を最大制限値の 5,000 個 (ASP.NET による制約) まで増やし、キーワードごとにおすすめコンテンツを 5 個まで増やすことができます。サイト管理ユーザー インターフェイスでのキーワードの表示が正常に実行されなくなります。ASP.NET による制限値は、Web.config ファイルおよび Client.config ファイル (MaxItemsInObjectGraph) を編集することによって変更できます。 |
優先するページ |
推奨制限は、最優先するページを 1 つにすること、および目的の関連性を達成しながら 2 番目と 3 番目に優先するページの数を可能な限り少なくすること。 |
ハード リミットは、各 Search Service アプリケーションの関連性順位ごとに 200 個ですが、ページを追加しても目的の関連性が達成されないことがあります。キー サイトを 1 番目の関連性順位に追加します。以降のキー サイトを 2 番目または 3 番目の関連性順位として 1 つずつ追加し、追加するたびに関連性を評価して目的の関連性の効果が達成されることを確認します。 |
通知 |
Search Service アプリケーションごとの推奨制限値は 100 万個。 |
これはテスト済みの制限です。 |
結果の削除 |
1 回の操作で 100 個の URL。 |
これは、1 回の操作でシステムから削除する必要のある URL の推奨最大数です。 |
最適化
以下のセクションでは、ファームのパフォーマンスを向上する方法について説明します。
多くの要因がパフォーマンスに影響する可能性があります。この要因には、ユーザー数、ユーザー操作の種類、複雑さ、および頻度、操作内のポストバックの数、データ接続のパフォーマンスがあります。これらの各要因はファームのスループットに大きい影響を与える可能性があります。展開を計画する場合は、これらの各要因について慎重に検討する必要があります。
検索システムの容量とパフォーマンスはそのトポロジに大きく依存します。既存のサーバー コンピューターの容量を増加してスケール アップするか、サーバーをトポロジに追加してスケール アウトできます。
検索クエリ システムの最適化
一般に、検索クエリの最適化は以下のどちらかのシナリオに従って実行されます。
ユーザーがクエリの待機時間について不満を持っており、クエリの待機時間を短縮する必要がある。
予定よりも大幅に多くの検索要求が発生し、パフォーマンスが低下し始めたため、クエリのスループットを向上する必要がある。
クエリ サブシステムのスケール アウトまたはスケール アップを行うには、常に、より多くのクエリ コンポーネントの作成が必要になります。既存のクエリ サーバーに過剰な容量 (RAM、IO、CPU) がある場合、より多くのクエリ コンポーネントをそのサーバーに作成し、RAM、CPU、または IO を増加して (ボトルネックに当たった場合)、スケール アップすることを選択できます。そうでない場合は、より多くのクエリ コンポーネントを新しいサーバーに作成して (または既存のコンポーネントを新しいサーバーに移動して)、スケール アウトすることを選択できます。
次のセクションでは、クエリ リソースを検索クエリ システムに追加するためのさまざまな方法について説明します。
クエリの待機時間を短縮する方法
クエリ コンポーネントを追加して待機時間を短縮する
次のグラフは、アクティブ クエリ コンポーネントの追加が各サーバーに与える影響を示しています (ただし、インデックス サイズの変更はありません)。
.gif "ユーザー負荷がクエリ待機時間 (75 パーセンタイル) に与える影響")
システムのユーザー ロード (同時ユーザー クエリ数で測定) の増加に応じて、より多くのアクティブ クエリ コンポーネントを追加し、1 秒未満のクエリ待機時間を維持します。
クエリ プロセッサ (Query and Site Settings Service) を追加して待機時間を短縮する
次のグラフは、アクティブなクエリ プロセッサ サービスの追加が各サーバーに与える影響を示しています (ただし、クエリ システムのその他の部分の変更はありません)。
.gif "ユーザー負荷がクエリ待機時間 (75 パーセンタイル) に与える影響")
システムのユーザー ロード (同時ユーザー クエリ数で測定) の増加に応じて、各サーバーで Query and Site Settings Service の他のアクティブ インスタンスを開始し、1 秒未満のクエリ待機時間を維持します。
スケール アウトしてクエリのスループットを向上する
クエリ コンポーネントを追加してクエリのスループットを向上する
次のグラフは、アクティブ クエリ コンポーネントの追加が各サーバーに与える影響を示しています (ただし、インデックス サイズの変更はありません)。
.gif "クエリ コンポーネント数がさまざまなクエリのクエリ スループットにユーザー負荷が与える影響")
システムのユーザー ロード (同時ユーザー クエリ数で測定) の増加に応じて、より多くのアクティブ クエリ コンポーネントを追加し、クエリのスループットを向上します。
クエリ プロセッサ (Query and Site Settings Service) を追加してクエリのスループットを向上する
次のグラフは、アクティブなクエリ プロセッサ サービスの追加が各サーバーに与える影響を示しています (ただし、クエリ システムのその他の部分の変更はありません)。
.gif "ユーザー負荷が追加クエリ サービスのクエリ スループットに与える影響")
要点: システムのユーザー ロード (同時ユーザー クエリ数で測定) の増加に応じて、各サーバーで Query and Site Settings Service の他のアクティブ インスタンスを開始し、スループットを向上します。
検索クロール システムの最適化
一般に、検索クロールの最適化を実行するのは、存在するはずの結果が検索されないといった不満や、結果は検索されるが最新でないといった不満をユーザーが持っている場合です。
新しさの目標内で、コンテンツ ソースの開始アドレスのクロールを試みる場合、クロールのパフォーマンスに関する以下の問題に直面する可能性があります。
検索クロール サブシステム内の IOPS のボトルネックが原因でクロール レートが低い。
検索クロール サブシステム内の CPU スレッドの不足が原因でクロール レートが低い。
遅いリポジトリ応答が原因でクロール レートが低い。
これらの各問題はクロール レートが低いことを前提とします。「検索管理レポートを使用する (SharePoint Server 2010)」を参照して (ソフトウェア ライフ サイクルの各段階を前提とする場合)、システムの標準クロール レートの基準を徐々に確立します。この基準が後退した場合は、以下のサブセクションに示されたさまざまな方法を使用して、クロールのパフォーマンスの問題を解決してください。
クロールの IOPS のボトルネック
クロール データベースまたはプロパティ データベースがボトルネックになっていることが判明した場合、適切な解決策を使用してクロール システムをスケール アップあるいはスケール アウトし、ボトルネックに対処する必要があります。次の表は、IOPS の追加 (別のクロール データベース) によってクロール レートがどのように向上するかを示しています (コンポーネントの追加を続けてボトルネックが再発するまで)。
要点: クロール データベースを常にチェックしてクロール データベースがボトルネックになっていないことを確認します。クロール データベースの IOPS がすでにボトルネックになっている場合、クロール コンポーネントを追加したり、スレッド数を増加したりしても、解決にはなりません。
| トポロジ (クロール コンポーネント/ クロール データベース) | CPU 使用率 | RAM: バッファー キャッシュのヒット率 % | 読み取り待機時間 | 書き込み待機時間 | クロール速度 (ドキュメント/秒) |
|---|---|---|---|---|---|
2/1 データベース |
19.5 |
99.6 |
142 ミリ秒 |
73 ミリ秒 |
50 |
4/2 データベース |
8.502 |
99.55 |
45 ミリ秒 |
75 ミリ秒 |
～ 75 |
6/2 データベース |
22 |
99.92 |
55 ミリ秒 |
1050 ミリ秒 |
～ 75 |
クロール CPU スレッドのボトルネック
多数のホストがあり、クロールの他のボトルネックがない場合、適切な解決策を使用してクロール システムをスケール アップまたはスケール アウトする必要があります。クローラーは、Search Service アプリケーションごとに最大で 256 スレッドまで対応できます。最大数のスレッドによる完全なメリットを実現するには、クアッド コア プロセッサを搭載することをお勧めします。リポジトリが十分な速度でデータを処理していることが最終的に判明した場合 (この記事の後半の「リポジトリでのクロールのボトルネック」を参照)、クローラーのスレッド数を増加してリポジトリからのデータ要求を高速にすることで、クロールのスループットを向上できます。これを達成するには、以下の 3 つの方法を使用できます。
次の Windows PowerShell コマンドレットを使用して、インデクサーのパフォーマンス レベルを Partially Reduced または Maximum に変更します。
Get-SPEnterpriseSearchService | Set-SPEnterpriseSearchService –PerformanceLevel “Maximum”
使用するプロセッサのコアが 4 個未満の場合、Maximum の値を使用します。
クローラー影響ルールを使用して、ホストごとのスレッド数を増加します。ただし、サポートされるスレッド数は最大で 256 であること、および多くのスレッドを少ないホストに割り当てると他のリポジトリからのデータの取得が遅くなる場合があることを考慮する必要があります。
多くのホストがある場合の最適なソリューションは、独立したインデクサーに別のクロール コンポーネントを追加し、インデックスをより高速に作成するホストをクロールすることです。
検索サブシステムが IOPS のボトルネックになっておらず、リポジトリがコンテンツを高速に処理している場合、クロールのスループットをシームレスに向上するための最適な方法は、別のインデクサーを追加することです。
リポジトリでのクロールのボトルネック
多数の入れ子になったサイト コレクションまたはリモート ファイル共有を使用する SharePoint Web アプリケーションをクロールする場合、検索クローラーがリポジトリのボトルネックになる場合があります。リポジトリのボトルネックは、以下の 2 つの条件が当てはまる場合に識別できます。
クロール サーバーに、低い CPU 使用率 (20 パーセント未満) がある。
ネットワーク上で多くのスレッド (最悪の場合はほぼすべてのスレッド) が待機している。
ボトルネックは、OSS Search Gatherer/Threads Accessing Network パフォーマンス カウンターを調べることで識別されます。
この状況が表していることは、スレッドはブロックされたままリポジトリからのデータを待機していることです。複数のコンテンツ ソースが含まれる環境では、他のすべてのクロールを一時停止した後に、疑いのあるホストを開始アドレスの 1 つとして持っているコンテンツ ソースを使用してクロールを実行することで、応答の遅いホストを特定することをお勧めします。
問題のあるホストが特定されると、遅い応答時間の原因を調査する必要があります。特に、SharePoint コンテンツの場合は、記事「SharePoint Server 2010 での容量管理と規模設定」を参照してください。
クロールのスループットは、クロールされるデータ リポジトリのパフォーマンス チューニングを行うことで大幅に向上できます。
パフォーマンスとスケールの問題のトラブルシューティング
パフォーマンスのトラブルシューティングを行う前に、ファームのロードを把握しておくことが重要です。次のセクションでは、6,000 万アイテムが含まれる稼働中のファームのデータを使用して、検索ライフ サイクルの各段階のさまざまなシステム測定基準を示します。
検索ライフ サイクル中のパフォーマンスの例
| 測定基準 | インデックスの取得 | インデックスのメンテナンス | インデックスのクリーンアップ |
|---|---|---|---|
SQL Server CPU 使用率 (%) プロパティ データベース/クロール データベース |
14.8/19.13 |
35/55 |
11/63 |
SQL Server ページの予測保持期間 プロパティ データベース/クロール データベース |
60,548/5,913 |
83,366/5,373 |
33,927/2,806 |
SQL Server 平均ディスク書き込み時間 (秒/書き込み) プロパティ データベース/クロール データベース |
9 ミリ秒/48 ミリ秒 最大: 466 ミリ秒/1,277 ミリ秒 |
12 ミリ秒/28 ミリ秒 |
20 ミリ秒/49 ミリ秒 最大: 253 ミリ秒/1156 ミリ秒 |
SQL Server 平均ディスク読み取り時間 (秒/読み取り) プロパティ データベース/クロール データベース |
8 ミリ秒/43 ミリ秒 最大: 1,362 ミリ秒/2,688 ミリ秒 |
11 ミリ秒/24 ミリ秒 |
24 ミリ秒/29 ミリ秒 最大: 2,039 ミリ秒/2,142 ミリ秒 |
クローラー CPU 使用率 (%) インデックス サーバー 1 (2 クロール コンポーネント)/インデックス サーバー 2 (2 クロール コンポーネント) |
18/11 |
25.76/21.62 |
8.34/7.49 99% の最大ピーク |
ディスク書き込み速度 (書き込み/秒) インデックス サーバー 1 (2 クロール コンポーネント)/インデックス サーバー 2 (2 クロール コンポーネント) |
64.32/42.35 |
93.31/92.45 |
99.81/110.98 |
ディスク読み取り速度 (読み取り/秒) インデックス サーバー 1 (2 クロール コンポーネント)/インデックス サーバー 2 (2 クロール コンポーネント) |
0.23/0.20 |
4.92/2.03 |
1.38/1.97 |
平均ディスク書き込み時間 (秒/書き込み) インデックス サーバー 1 (2 クロール コンポーネント)/インデックス サーバー 2 (2 クロール コンポーネント) |
11 ミリ秒/11 ミリ秒 |
1 ミリ秒/2 ミリ秒 |
5 ミリ秒/4 ミリ秒 最大: 1,962 ミリ秒/3,235 ミリ秒 |
平均ディスク読み取り時間 (秒/読み取り) インデックス サーバー 1 (2 クロール コンポーネント)/インデックス サーバー 2 (2 クロール コンポーネント) |
1 ミリ秒/2 ミリ秒 |
12 ミリ秒/11 ミリ秒 |
10 ミリ秒/16 ミリ秒 最大: 2,366 ミリ秒/5,206 ミリ秒 |
クエリのパフォーマンスの問題のトラブルシューティング
SharePoint 検索には、インストルメント化されたクエリ パイプラインおよび関連付けられた管理レポートがあります。これらは、サーバー ベースのクエリのパフォーマンスの問題のトラブルシューティングに役立つ可能性があります。詳細については、「検索管理レポートを使用する (SharePoint Server 2010)」を参照してください。このセクションでは、レポートを示した後に、そのレポートを使用してサーバーの問題をトラブルシューティングする方法について説明します。また、このセクションには、クライアント ベース (ブラウザー) のパフォーマンスの問題の対処に使用できるツールとガイダンスも含まれます。
サーバー ベースのクエリの問題
サーバー ベースのクエリ パフォーマンスの問題は、以下の 2 つのレベルに区別できます。
検索のフロントエンドのパフォーマンスの問題
検索のバックエンドのパフォーマンスの問題
以下の 2 つのサブセクションで、これらの各問題のトラブルシューティング詳細について説明します。ただし、これらの説明は、高レベルのガイドラインです。
フロントエンドのパフォーマンスの問題
フロントエンドのパフォーマンスをトラブルシューティングするための 1 番目の手順は、[全体的なクエリの待機時間] 検索管理レポートを確認することです。レポートの例を次に示します。
.gif "検索クエリの待機時間に関するサンプル レポート")
このレポートでは、以下のデータ系列よってフロント エンドのパフォーマンスが表されます。
サーバー レンダリング: この値は、特定の 1 分間において、フロントエンド Web サーバー内のさまざまな検索 Web パーツで 1 クエリにかかった平均時間を表します。
オブジェクト モデル: この値は、特定の 1 分間において、フロントエンド Web サーバーと検索バックエンド間の通信にかかった時間の平均を表します。
サーバー レンダリングの問題のトラブルシューティング
サーバー レンダリングの問題は、検索結果ページを処理するフロントエンド Web サーバーで発生するあらゆる動作の影響を受ける可能性があります。一般に、さまざまな Web パーツの取得にかかる時間を把握して、余分の待機時間が追加される場所を見つける必要があります。詳細な待機時間レポートを表示するには、検索結果ページで [開発者ダッシュボード (英語)] を有効にします。サーバー レンダリングの余分な待機時間を明らかに示す一般的な問題を以下に示します。
以下のようなプラットフォームの問題。
Active Directory 参照が遅い。
SQL Server 時間が遅い。
SharePoint Server 2010 の人に関するクエリまたは FAST Search Server 2010 for SharePoint のすべてのクエリにおいてユーザー プロファイル アプリケーションへの要求が遅い。
ユーザー設定を取得するための要求が遅い。
Security Token Service からユーザーのトークンを取得するための呼び出しが遅い
チェックインされて発行されていない、変更された検索結果ページ (results.aspx、peopleresults.aspx など) のような、分離コードの問題。
オブジェクト モデルの問題のトラブルシューティング
オブジェクト モデルの問題は以下の影響を受ける可能性があります。
以下のような Windows Communication Foundation (WCF) 層の問題。
展開内の WCF 呼び出しでのタイムアウトおよび ThreadAbortException。
フロントエンド Web サーバーとアプリケーション サーバー間の遅い通信。これは、IPsec の問題または遅いネットワーク接続が原因で発生する可能性があります。
コンテンツとサービス ファーム間の通信の問題 (構成されている場合)。
バックエンドのパフォーマンスの問題
バックエンド クエリのパフォーマンスをトラブルシューティングするための 1 番目の手順は、[SharePoint バックエンド クエリの待機時間] 検索管理レポートを確認することです。レポートの例を次に示します。
.gif "検索バックエンド クエリの待機時間に関するサンプル レポート")
このレポートでは、機能コンポーネントによってグループ化された以下のデータ系列によってバックエンドのパフォーマンスが表されます (各データは、特定の 1 分間において 1 クエリにかかった平均時間です)。
クエリ コンポーネント:
- フルテキスト クエリ: 結果のフルテキスト インデックスをクエリするのにかかった平均時間。
プロパティ データベース:
複数の検索結果の取得: クエリ結果に表示する、ドキュメントのメタデータ (タイトル、作成者など) を取得するのにかかった平均時間。
プロパティ ストア クエリ: プロパティ ベースのクエリについて、プロパティ データベースをクエリするのにかかった平均時間。
検索管理データベース:
おすすめコンテンツ: クエリ用語に関するおすすめコンテンツがあるかどうかを判断するのにかかった平均時間。
精度の高い検索結果: クエリに対して精度の高い検索結果を取得するのにかかった平均時間。
クエリ プロセッサ:
セキュリティによるトリミング: ユーザーがアクセスできないアイテムを削除するのにかかった平均時間。
重複の削除: 重複を削除するのにかかった平均時間。
検索結果の作成: オブジェクト モデルに返されるメモリ内テーブルを作成するのにかかった平均時間。
クエリ コンポーネントのパフォーマンスの問題のトラブルシューティング
クエリ コンポーネントは、特にアクティブの場合、つまりクエリ要求に応答する場合、大量のリソースを消費します。クエリ コンポーネントのパフォーマンスのトラブルシューティングは、より複雑な検索分野の 1 つです。一般的な検討分野を以下に示します。
最大量のリソースを消費するクエリ コンポーネントのイベントはマスター結合です。マスター結合では、シャドウ インデックスがマスター インデックスに結合されます。このイベントは、クエリ コンポーネントごとに独立して発生します。影響の例は、この記事の前述の [SharePoint バックエンド クエリの待機時間] レポートの 1:30 PM 以前の時間で確認できます。このイベントがクエリの待機時間に影響する場合、ブラックアウト期間を定義できます。ブラックアウト期間中は、変更のパーセンテージが定義済みの制限を超えない限り、マスター結合イベントは回避されます。
高い環境の値が持続する場合、以下の処理を行うことをお勧めします。
サーバー上の各コンポーネントのインデックス サイズを調べます。インデックス サイズの合計の約 33 パーセントをキャッシュできる十分な RAM がサーバーに存在することを確認します。
サーバー上のクエリ コンポーネントの IO チャネルを調べます。IO のボトルネックが発生していないことを確認します。
IO と RAM がパフォーマンスの問題の原因でない場合、クエリ コンポーネントのパーティション再分割 (インデックス パーティションの追加) を行って、追加のクエリ コンポーネントを新しいサーバーにスケール アウトする必要があります。
プロパティ データベースの問題のトラブルシューティング
「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2010)」の概念を使用して、SQL Server の状態を調べます。カスタム クエリを実行する場合は、適切なクエリ計画をガイドするヒントを参照することが必要になる場合があります。
検索管理データベースの問題のトラブルシューティング
「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2010)」の概念を使用して、SQL Server の状態を調べます。
クエリ プロセッサの問題のトラブルシューティング
クエリ プロセッサの問題のトラブルシューティングは、以下のどのクエリ プロセッサ領域がクエリの待機時間に影響を与えているかによって異なります。
セキュリティによるトリミング:
Windows クレームの場合、クエリ プロセッサをホストするサーバーからの Active Directory 接続を調べます。
どの場合も、大量の SQL Server ラウンド トリップ間に相互関係がある場合 (SQL Server プロファイラーによって確認される) は、クエリ プロセッサで使用するキャッシュ サイズを増加できます。25 パーセント以上のクエリは、検索管理データベースからセキュリティ記述子を取得するための SQL Server 呼び出しを必要としません。必要とする場合は、クエリ プロセッサのキャッシュ サイズを調整します。
重複の削除:
- 同じコンテンツが複数の場所でクロールされていないかどうかを調べます。検索センターで重複データ検出を無効にします。
複数の検索結果の取得:
- 「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2010)」の概念を使用して、SQL Server の状態を調べます。
ブラウザー ベースのクエリの問題
ユーザーは検索結果の速度によって喜んだり憤慨したりする可能性があります。検索機能に関するユーザーの満足度において、ページ読み込み時間は重要な要因の 1 つです。ページ読み込み時間のほとんどはサーバー側に集中します。特に、サーバーが結果を返すのにかかる時間です。ただし、クライアント側のレンダリングも読み込み時間の重要な部分を構成する可能性があります。したがって、これを検討することも重要です。
検索のユーザー エクスペリエンスでは、総ページ読み込み時間について、1 秒未満の応答が提供されるように設計されます。この時間のうち、クライアントのレンダリング時間は、通常、280 ミリ秒未満です。ただし、ブラウザーとレンダリングの測定基準によって異なります。このエクスペリエンスの場合、ユーザーは非常に高速な結果に満足します。
結果をカスタマイズすることで、レンダリングのパフォーマンスが容易に低下する可能性があります。検索管理者と開発者は、変更のたびにレンダリング時間を測定し、パフォーマンスが大幅に後退していないことを確認して、警戒を怠らないようにする必要があります。ページに何かを追加するたびに (新しい Web パーツから新しいカスケード スタイル シートのスタイルまで)、ブラウザーでのレンダリング時間が増加し、ユーザーへの結果が遅延します。ただし、この遅延時間は、ページをカスタマイズするときにベスト プラクティスに従うかどうかによって大きく変わる可能性があります。
いくつかの一般的なガイドラインについて以下で説明します。
ページの基本的なブランド設定およびスタイルのカスタマイズによって読み込み時間に追加される時間は、約 25 ミリ秒を超えないようにする必要があります。カスタマイズを実装する前後でページ読み込み時間を測定して変更を監視します。
ユーザーは、通常、20 パーセントの増加で変化 (速くなったまたは遅くなったこと) に気づきます。変更を加えるときはこのことを考慮します。標準的なレンダリング時間の 20 パーセントは、50 ミリ秒です (ソース: Designing and Engineering Time (英語))。
カスケード スタイル シートと JScript は、高いレンダリング パフォーマンスの最も一般的で最大の原因です。カスケード スタイル シートと JScript をカスタマイズする必用があった場合、それらが 1 ファイルずつにまで最小化されていることを確認する必要があります。
JScript はページのレンダリング後にオンデマンドで読み込むことができるため、表示可能な結果をより早くユーザーに提供できます。これを行う方法の詳細については、パフォーマンスに関する検討事項の記事で説明されています。
ページに追加するカスタマイズが多いほど、ページの読み込みは遅くなります。追加する機能とスタイルが、ユーザーに対して結果がさらに遅延することに見合う価値があるかどうかを検討します。
これらのガイドラインに加えて、ページ読み込み時間を短縮する方法、および遅いページがユーザー エクスペリエンスに与える影響については、インターネット上に大量の情報が存在します。
クロールのパフォーマンスの問題のトラブルシューティング
SharePoint 検索では、インデックスの取得、メンテナンス、および削除の各段階をシステムが進むにつれて、クロール サブシステムでボトルネックが発生する可能性があります。クロールのパフォーマンスの問題を効果的にトラブルシューティングするには、[検索の正常性追跡] レポートを、この記事で後述する「一般的なボトルネックとその原因」と共に使用してクロールの問題を分離する必要があります。
インデックスの取得段階でのトラブルシューティング
クロールの問題を特定するための最初の場所は、[コンテンツ ソース別のクロール レート] 正常性レポートです。この記事で後述されているとおり、このレポートでは、システム内の各コンテンツ ソースのクロール レートの概要が提供されます。一般に、クロール レートは、人に関するコンテンツ ソースで 15 ドキュメント/秒、他のすべての種類のコンテンツ ソースで 35 ドキュメント/秒を超える必要があります。
.gif "検索クロール レートに関するサンプル レポート")
クロール レートが最適化されていないコンテンツ ソースが特定された場合、以下の手順を実行することをお勧めします。
調査中のコンテンツ ソースを除く他のすべてのクロールを一時停止します。クロール レートが向上し、指定された 15 ～ 35 ドキュメント/秒の目標を超えましたか。
前述の手順で効果がない場合、クロールされるリポジトリに十分な応答性があり、そのリポジトリが遅いクロールの原因となっていないことを確認します。この記事の前述の「リポジトリでのクロールのボトルネック」を参照してください。
リポジトリがボトルネックになっていない場合、クロール サーバーまたはデータベース サーバー内のボトルネックを特定し、それらを最適化します。ガイダンスについては、この記事の前述の「クロールの IOPS のボトルネック」および「クロール CPU スレッドのボトルネック」を参照してください。
インデックスのメンテナンス段階でのトラブルシューティング
インデックスのメンテナンス段階における第一の目標は、インデックスの新しさを可能な限り維持することです。重要な 2 つのインジケーターを以下に示します。
インデックスの新しさ: 予定された時間内にクロールが終了し、インデックスの新しさに関する IT ガイドラインにクロールが従っていますか。
増分クロールの速度: インデックスの新しさの目標が満たされていない場合、増分クロールの速度が、人に関するコンテンツ ソースで 10 ドキュメント/秒、他のすべてのコンテンツ ソースで 35 ドキュメント/秒になっているかどうかを調査します。増分クロールの速度が最適化されていない場合、クロールされるリポジトリおよびクロール サブシステムに対して前述のとおりにボトルネック分析を実行する必要があります。
一般的なボトルネックとその原因
パフォーマンスのテスト中、一般的なさまざまなボトルネックがいくつかわかってきました。ボトルネックとは、特定のファーム構成の容量が限界に達している状態です。これによりファームのスループットが停滞または低下します。
次の表で、いくつかの一般的なボトルネックを示し、その原因と、考えられる解決方法について説明します。
| ボトルネック | 現象 (パフォーマンス カウンター) | 解決方法 |
|---|---|---|
データベース RAM |
プロパティ データベース、 検索管理データベースが以下の状態を示している。 SQL Server バッファー マネージャー/ページの予測保持期間 < 300(秒) (1,000 (秒) を超える必要がある)。 SQL Server バッファー マネージャー/バッファー キャッシュ ヒット率 < 96% (98% を超える必要がある)。 |
メモリをデータベース サーバーに追加します。 毎週のデフラグ ルールが無効になっている場合は、プロパティ データベースを最適化します。 SQL Server 2008 Enterprise Edition を使用してページ圧縮を有効にしていることを確認します。 データベースを別のサーバーに移動し、必要な場合は複数のプロパティ データベースを追加します。 |
データベース サーバーの IOPS |
プロパティ データベースまたはクロール データベースが以下の状態を示している。 平均ディスク読み取り時間 (秒/読み取り) および平均ディスク書き込み時間 (秒/書き込み) ～ 50 ミリ秒または > 50 ミリ秒。 |
重要なテーブル (MSSDocSDIDs + MSSDocProps + MSSDocresults) の 33 パーセントをキャッシュに保持するのに十分な RAM がデータベース サーバーにあることを確認してください。 以下の手順を実行して、データベース専用の IOPS 数を増加します。 異なるストレージ アレイを使用します。 ストレージ構成を最適化します。たとえば、スピンドル (ディスク ドライブ) をストレージ アレイに追加します。 SharePoint Health Analyzer の [検索 - インデックスが断片化されているプロパティ データベースがあります] ルールを実行します (このルールが無効になっている場合)。 SharePoint Health Analyzer の [検索 - 1 つ以上のクロール データベースに断片化されたインデックスがあります] ルールを実行します。 SQL Server 2008 Enterprise Edition を使用してページ圧縮を有効にしていることを確認します。 データベースを別のサーバーに移動し、必要な場合は、複数のプロパティ データベースまたはクロール データベース、あるいはその両方を追加します。 |
クエリ コンポーネントの IOPS |
クエリ コンポーネントのインデックスで使用されている論理ディスクが以下の状態を示している。 持続期間 (インデックス結合中のみではなくほぼ 1 日) における平均ディスク読み取り時間 (秒/読み取り) および平均ディスク書き込み時間 (秒/書き込み) ～ 30 ミリ秒または > 30 ミリ秒。 |
各アクティブ クエリ コンポーネントのインデックス (各アプリケーション サーバー上にある) の 33 パーセントをキャッシュ (オペレーティング システム キャッシュ) に保持するのに十分な RAM が各アプリケーション サーバーにあることを確認します。 以下の手順を実行して、クエリ コンポーネントのインデックスで使用されるドライブ専用の IOPS 数を増加します。 コンポーネントごとに異なるストレージ アレイを使用します。 ストレージ構成を最適化します。たとえば、スピンドル (ディスク ドライブ) をストレージ アレイに追加します。 |
作者について
Brion Stone は、Microsoft での SharePoint Server Search のシニア プログラム マネージャーです。