検索のパフォーマンス向上のためのベスト プラクティス (Office SharePoint Server 2007)

この記事では、Microsoft Office SharePoint Server 2007 の検索システムで正常および効率的な状態を維持するためのベスト プラクティスについて説明します。

この記事の内容 :

• フル クロールを開始する理由

• Web サーバーの監視

• データベース サーバーの監視

• インデックス サーバーの監視

• SharePoint 診断を使用した Office SharePoint Server の監視

• 統合ログ サービスのログを使用したクエリのボトルネックの診断

• Office SharePoint Server 2007 で検索を行うための SQL Server の最適化

• 検索のための SQL Server データベースのメンテナンス

• クローラ中止の回避

• アクセス制御リストが原因のボトルネックの回避

• 検索ボックス Web パーツが見つからない場合のトラブルシューティング

フル クロールを開始する理由

大量の情報、ドキュメント、および Web ページに対してクロールおよびインデックス作成を行うにはかなりの量のコンピュータ処理が伴います。また、クロール処理は、ネットワークやその他のリソースも消費します。そこで、Office SharePoint Server 2007 ファームを慎重に構成し、クロールおよびインデックス作成処理がユーザーへのサービスに悪影響を及ぼさないようにする必要があります。たとえば、コンテンツのクロールおよびインデックス作成は、通常、サーバーの利用率が低いオフピーク時に行い、ピーク時におけるユーザーへのサービスが維持されるようにします。

フル クロールではなく増分クロールをスケジュールすることで、クロールの影響を少なくすることもできます。増分クロールでは、変更された項目のみにインデックスが作成されるので、処理に必要なコンピュータ リソースが大幅に減ります。フル クロールおよび増分クロールはコンテンツ ソースごとにスケジュールできます。たとえば、平日の深夜に増分クロールを実行し、土曜日の深夜にフル クロールを実行するようにスケジュールできます。

注意

クロールのスケジュールを計画する方法については、「コンテンツのクロールを計画する (Office SharePoint Server)」を参照してください

インデックスを確実に作成するには、以下の場合にフル クロールを手動で開始する必要があります。

• 管理者が更新プログラムまたはサービス パックをファームのサーバーに適用した。

• 管理者が新しい管理プロパティを検索構成に追加した。

• 管理者がクロール ルールを追加または変更した。

• Windows SharePoint Services 3.0、Microsoft Office SharePoint Server 2007、または Search Server 2008 のサイトで ASP.NET ページをインデックスを再作成する必要がある。これらの Web ページが変更されてもクローラでは検出できません。したがって、こうしたページのインデックスはフル クロールでのみ再作成されます。

• 増分クロールの障害が連続して発生している。リポジトリ内の任意のレベルで増分クロールに 100 回連続で失敗すると、インデックス サーバーにより、影響を受けるコンテンツがインデックスから削除されます。

• 管理者が破損したインデックスを修復した。

• 管理者がサーバー名マッピングを作成した。

• 一部のコンテンツの権限を変更したが、コンテンツ自体が変更されておらず、サーバーに Service Pack 1 以降の修正プログラム パッケージ (KB941442) またはそれ以降のサービス パックを適用していない。この修正プログラム パッケージが適用されていないと、増分クロールではアクセス制御リスト (ACL) が確認されません。最後にフル クロールした後に管理者がユーザーの権限を削除しても、ACL が確認されなければ、ユーザーが検索した結果に項目が表示される場合があります。

以下の場合、増分クロールがスケジュールされたとき、または手動で開始されたときは、Office SharePoint Server 2007 によってフル クロールが実行されます。

• 管理者が直前のクロールを手動で停止した。

• 管理者がバックアップからコンテンツ データベースを復元した。

  注意

  Microsoft Office Servers インフラストラクチャ更新プログラム をインストールしている場合、復元操作によってフル クロールを実行するかどうかを、Stsadm コマンドライン ツールのオプションを使用して指定できます。

• 管理者がコンテンツ データベースを切断し、再接続した。

• Office SharePoint Serverがコンテンツでフル クロールを実行しなかった。

• 変更ログにクロール内のアドレスの情報が含まれていない。変更ログは、前回のクロール以降に項目が変更されたかどうかを判断する際に使用します。変更ログ情報がない場合、増分クロールは発生しません。

• コンテンツのアクセスに使用されるアカウントが変更された。このアカウントは、既定のアクセス アカウントまたはクロール ルールに指定されたアクセス アカウントの可能性があります。

• インデックスが破損した。

クロールを手動で開始する場合、またはスケジュールに従って開始する場合、フル クロールには、増分クロールで必要とするよりも多くのリソースが必要なことがあり、これは、ユーザーに対するサービスに影響を及ぼす可能性があります。したがって、上記の状況では、自分の操作について慎重に検討する必要があります。

Web サーバーを監視する

Office SharePoint Server 2007 の検索パフォーマンスを最大限に高めるには、システムを詳細に解析します。また、サーバーを詳細に調査することでベースラインを作成し、パフォーマンス テストを定期的に再実行して早期に変更を確認し問題を診断する必要があります。最適化を行う場合は、このベースラインを使用すると、結果として生じる向上点を特徴付けることができます。以下のセクションでは、Office SharePoint Server 2007 のパフォーマンスに関連するパフォーマンス モニタ カウンタ、および他のツールで入手できるデータの一覧を示します。

注意

一般的なシステム監視の詳細については、「パフォーマンスを監視する」(https://go.microsoft.com/fwlink/?linkid=105584&clcid=0x411) を参照してください。

Office SharePoint Server 2007 では、すべてのサイトとサイト コレクションは、Web サーバーによってホストされます。Web サーバーは、データベース サーバーに格納されているコンテンツを取得して、ユーザーの要求に応答します。ユーザーの検索クエリに対する応答は Web サーバーが送信するため、Web サーバーのパフォーマンスは、検索パフォーマンスに直接的に影響します。また、Web サーバーはインデックスの作成にも影響します。クローラが Web サーバーに要求を送信して、Office SharePoint Server のコンテンツのインデックスを作成するためです。

Web サーバーの正常性を監視するには、以下のパフォーマンス モニタ カウンタを使用します。

• Processor/% Processor Time/_Total

  このカウンタは主にプロセッサの動作を表しており、アイドル以外のスレッドの実行にプロセッサが費やした時間の割合を測定します。このカウンタの平均値が長期間にわたって 80% を超える場合は、プロセッサがボトルネックになっている可能性があり、アップグレードを検討する必要があります。

• Memory/Available Mbytes

  このカウンタは、処理またはシステムですぐに使用できる物理メモリを測定します。このカウンタの値が低すぎる場合は、多くのページングを使用しているので、システムの速度が低下します。この場合は、サーバーにメモリを追加することを検討する必要があります。

• Web Service/Current Connections

  このカウンタは、World Wide Web サービスへの接続数を測定します。Office SharePoint Server 2007 Web サーバーでは、すべての同時実行ユーザーおよびクローラ (インデックス作成中の場合) がこの数に含まれます。このカウンタを使用して、使用パターンのプロファイルを作成したりピーク時を診断したりします。このカウンタに制限はありません。非常に高い値が示されている場合、それはパフォーマンスに優れていることを示している可能性があります。

  注意

  Office SharePoint Server ファームに複数の Web サーバーがある場合、このカウンタは、1 つのサーバーのみの接続数を測定します。ファーム全体のユーザー操作を監視する方法については、「Monitoring Office SharePoint Server with SharePoint Diagnostics」を参照してください。

データベース サーバーを監視する

Office SharePoint Server 2007 は、Microsoft SQL Server 2005 または Microsoft SQL Server 2008 を使用して、コンテンツ データベースを保存します。インデックス サーバーでは、コンテンツ インデックスはデータベースではなくファイル システムに保存されますが、ドキュメント メタデータおよび権限は検索データベースに保存されます。検索の多くがメタデータを確認し、すべての検索でセキュリティによるトリミングが行われるので、データベース サーバーのパフォーマンスは検索パフォーマンスに直接影響します。

データベース サーバーの正常性を監視するには、以下のパフォーマンス モニタ カウンタを使用します。

• Processor/% Processor Time/_Total

  このカウンタは主にプロセッサの動作を表しているので、Web サービスでこのカウンタが重要であるのと同じくらい、データベースでも重要です。

• LogicalDisk/% Disk Time/<ディスク名>**

  このカウンタは、読み取りまたは書き込み要求のサービスにディスクが費やした経過時間の割合を測定します。検索では、検索データベースを持つディスクのこのカウンタを監視してください。このカウンタの平均が 90% を超えることが多い場合、ディスクが検索のボトルネックになっている可能性があります。

• System: Processor Queue Length

  このカウンタの平均は、サーバー上の CPU コアの数を 2 倍した値を下回っている必要があります。

• Memory: Available Mbytes

  このカウンタの平均は、合計物理 RAM の 20% 以上が必ず必要です。

• Memory: Pages/sec

  このカウンタの平均は 100 未満である必要があります。

• Logical Disk: Disk Transfers/sec

  このカウンタは、パーティションの全体的なスループットを測定します。

• Logical Disk: Disk Read Bytes/sec と Disk Write Bytes/sec

  このカウンタは、特定のディスクの合計帯域幅を測定します。

• Logical Disk: Average Disk sec/Read

  読み取り待機時間とも呼ばれます。このカウンタは、ディスクがデータを取得するのに必要な時間を示します。読み取り待機時間を短くすることは、ユーザー クエリに対する応答を短縮するうえで重要です。

• Logical Disk: Average Disk sec/Write

  書き込み待機時間とも呼ばれます。このカウンタは、ディスクがデータを書き込むのに必要な時間を示します。書き込み待機時間を短くすることでインデックス作成のパフォーマンスが向上します。

• LogicalDisk/% Disk Read Time/<ディスク名>**

  このカウンタは、読み取り要求のサービスにディスクが費やした経過時間の割合を測定します。検索データベース ディスクに対する読み取り要求の割合が高い場合は、ユーザーが多数の検索を実行していることを示す可能性があります。

• LogicalDisk/% Disk Write Time/<ディスク名>**

  このカウンタは、書き込み要求のサービスにディスクが費やした経過時間の割合を測定します。インデックス作成処理中は、検索データベース ディスクに対する書き込み要求の割合が高くなります。

  注意

  可能な場合は、他のデータベースとは別のディスクに検索データベースを配置して、検索パフォーマンスを最適化します。このように検索データベースを切り離すと、ディスクは検索だけに使用されるので、これらの論理ディスク カウンタは高い可能性で検索パフォーマンスの診断に使用できます。

• SQLServer:Buffer Manager/Page life expectancy

  このカウンタは、参照がないバッファ プールにデータベース ページが維持される秒数を測定します。この値は 300 秒以上である必要があります。値が 300 秒を下回る場合、高い可能性でメモリがボトルネックになっていると診断でき、サーバーにメモリを追加することを検討する必要があります。

注意

一般的な SQL Server の最適化の詳細については、この Office SharePoint Server の記事では説明しません。詳細については、以下のリソースを参照してください。

• Storage Top 10 Best Practices (英語) (https://go.microsoft.com/fwlink/?linkid=148543&clcid=0x411)

• SQL Server Best Practices Article (英語) (https://go.microsoft.com/fwlink/?linkid=148544&clcid=0x411)

• RAID レベルと SQL Server (https://go.microsoft.com/fwlink/?linkid=105581&clcid=0x411)

• Microsoft SQL Server パフォーマンス モニタ カウンタおよび SharePoint 製品とテクノロジの詳細については、「SharePoint 用 SQL Server 記憶域の計画と監視 : パフォーマンスの推奨事項とベスト プラクティス (ホワイト ペーパー)」(https://go.microsoft.com/fwlink/?linkid=119398&clcid=0x411) を参照してください。

インデックス サーバーを監視する

Office SharePoint Server 2007 では、インデックス サーバーでコンテンツがクロールされ、インデックス ファイルが作成されます。クロール処理が完了すると、インデックスは、ユーザーからの検索要求に応答するクエリ サーバーに伝達されます。

インデックス サーバーのパフォーマンスが良くなくても、それがユーザーに直接影響を及ぼすことはありません。ただし、クロール処理が長引くと、場合によっては、クロール処理をオフピーク時だけに行うように制限できなくなり、バックアップなどのオフピーク時の他の操作からクロール処理を切り離せなくなることがあります。

注意

使用可能なサーバー数によっては、インデックス サーバーは個別のサーバーに配置されるとは限りません。

インデックス サーバーの正常性を監視するには、クロール中に以下のパフォーマンス モニタ カウンタを使用します。

• Office Server Search Archival Plugin/Total Docs in first queue/Portal_Content

  このカウンタは、アーカイブ プラグインの最初のキューのドキュメントの数を測定します。クロール中のこの値は 500 を下回っていなければなりません。また、クロール中以外はさらに低い値である必要があります。このカウンタが 500 を超えると、データベース サーバー上の検索データベース ドライブは高い可能性でボトルネックになっています。

• Office Server Search Archival Plugin/Total Docs in second queue/Portal_Content

  このカウンタは、アーカイブ プラグインの 2 番目のキューのドキュメントの数を測定します。前のカウンタと同様、クロール中のこの値は 500 を下回っている必要があります。

• Office Server Search Gatherer/Idle Threads

  このカウンタは、ドキュメントを待っている収集処理中のスレッドの数を測定します。このカウンタが 0 の場合、Gatherer でリソースが不足しているので、同時クロール数を減らすことを検討してください。

• Office Server Search Gatherer/Threads Accessing Network

  このカウンタは、リモート データ ストアに要求を送信して応答を待機または処理している収集処理中のスレッドの数を測定します。このカウンタの値が常に高い場合は、ネットワーク帯域幅がボトルネックになっているか、インデックス サーバーが 1 つ以上の低速ホストに接続され、コンテンツのインデックスを作成している可能性があります。

• Office Server Search Gatherer/Filtering Threads

  このカウンタは、コンテンツを取得してフィルタ処理しているスレッドの数を測定します。この数値が高い場合、インデックス サーバー上のリソースがボトルネックになっている可能性があります。

• Office Server Search Gatherer/Threads In Plug-Ins

  このカウンタは、コンテンツを取得して、IFilter などのプラグインを使用して処理しているスレッドの数を測定します。インデックスおよび検索データベースが自動入力されている場合、これはクロール処理で実行されます。

• Office Server Search Gatherer Projects/Crawls in progress

  このカウンタは、進行中のクロールの数を測定します。管理者が手動でクロールを開始していない限り、この値はスケジュールされたクロールを持つコンテンツ ソースの数と一致する必要があります。

SharePoint 診断で Office SharePoint Server を監視する

SharePoint 診断ツール v1.0 (SPDiag) は高度な診断および分析ツールで、SharePoint 製品およびテクノロジを実行するサーバーまたはファームに関する非常に広範な情報を提供します。SPDiag を使用すると、サーバーおよびファーム構成の詳細なスナップショットを表示できます。また、インターネット インフォメーション サービス (IIS)、統合ログ サービス (ULS) ログ、およびイベント ログの情報を結合および表示し、要求の速度が遅いなど、パフォーマンスに関する問題を調査することもできます。

注意

SPDiag は、「Microsoft SharePoint Administration Toolkit v3.0 (英語)」(https://go.microsoft.com/fwlink/?linkid=141504&clcid=0x411) に含まれています。

SPDiag では、ファーム上のどのサーバーからでもパフォーマンス カウンタのグラフを提供できます。ただし、この SPDiag には、IIS ログに基づいてファーム全体のデータを測定するカウンタも複数含まれています。こうしたファーム全体の分析は、パフォーマンス モニタだけで実行することはできません。

注意

SPDiag を効果的に使用するには、「SharePoint Diagnostics Tool (SPDiag) User Guide (英語)」(https://go.microsoft.com/fwlink/?linkid=141204&clcid=0x411) に目を通す必要があります。

以下のファーム全体のカウンタを使用して、Office SharePoint Server 2007 ファームの応答を調査します。

• SharePointRequests/Number of unique client IP

  このカウンタは、指定した期間に要求を行った一意のクライアントの数を測定します。プロキシ サーバーを介してファームにアクセスするクライアントは 1 つの IP アドレスとして表示されます。

• SharePointRequests/Number of unique client agents

  このカウンタは、指定した期間に要求を行った一意のクライアント エージェント (ブラウザ) の数を測定します。このカウンタは、ブラウザの HTTP 要求で指定されたエージェントに基づいているので、プロキシ サーバーを介してファームにアクセスする各クライアントを区別できます。

  注意

  以下のカウンタは、要求の数を測定します。これらの要求には、コンテンツに対する検索クエリと要求の両方が含まれます。

• SharePointRequests/Total requests

  このカウンタは、指定した期間にわたって変化する要求の合計数を測定します。このカウンタは常に以下のカウンタと一緒に監視して、高速要求と低速要求の割合を確認する必要があります。

• SharePointRequests/Number of requests with time taken < 1 second

  このカウンタは、1 秒以内で満たされる要求の数を測定します。パフォーマンスに優れたファームでは、このカウンタは Total requests カウンタの値に近くなります。

• SharePointRequests/Number of requests with time taken 1-5 seconds

  このカウンタは、1 ～ 5 秒の間に満たされる要求の数を測定します。このパフォーマンスは、通常、ユーザーにとっては許容範囲内ですが、時間経過に沿って要求の割合が増加している場合は、ボトルネックが発生していることを示す可能性があります。

• SharePointRequests/Number of requests with time taken 5-10 seconds

  このカウンタは、5 ～ 10 秒の間に満たされる要求の数を測定します。ユーザーは結果が返される前にクリックしてページから離れることができます。

• SharePointRequests/Number of requests with time taken > 10 seconds

  このカウンタは、満たされるまでにかかる時間が 10 秒を超える要求の数を測定します。Total requests の中でこれらの要求がかなりの割合を占める場合、ファームは応答していません。この場合、ボトルネックを調査し、ハードウェアのアップグレードを検討する必要があります。

統合ログ サービス ログを使用してクエリのボトル ネックを診断する

統合ログ サービス (ULS) を使用して、Office SharePoint Server 2007 システムのパフォーマンスを監視および最適化できます。ULS は、システムを最適化する手段の 1 つとして使用します。その他に、パフォーマンス モニタ、イベント ログ、および Web ログを使用することもできます。

このセクションでは、ULS ログを使用して検索パフォーマンスにおける遅延を診断する方法について説明します。ULS ログを使用すると、検索処理のどの段階に一番時間がかかり、ユーザーへの検索結果の表示を遅らせているかを診断できます。また、システム構成へのわずかな変更によるパフォーマンス向上を評価する場合にも、ULS ログを使用します。

注意

パフォーマンスとディスクの空き領域が影響を受けないように、ULS ログは慎重に使用してください。ULS によるパフォーマンスの問題の診断後、ULS ログを無効にすると、パフォーマンスを最大限に高めることができます。また、ULS ログは、空き領域の多いディスクに保存するようにします。

注意

Log Parser 2.2 で使用するクエリの詳細および追加の例については、ブログ「Microsoft Enterprise Search Blog」の「How to: Mine the ULS logs for query latency (英語)」(https://go.microsoft.com/fwlink/?linkid=148540&clcid=0x411) を参照してください。

統合ログ サービスを構成する

まず、Office SharePoint Server 2007 サーバーの全体管理 Web サイトで ULS を構成します。

重要

以下の手順を完了するには、ファームの管理者グループのメンバシップが必要です。

統合ログ サービスを構成して検索パフォーマンスの問題を診断するには

1. [スタート] ボタンをクリックし、[すべてのプログラム] をポイントします。次に、[Microsoft Office Server] をクリックし、[SharePoint 3.0 サーバーの全体管理] をクリックします。

2. [サーバー構成の管理] タブをクリックします。

3. [ログおよびレポートの作成] セクションで、[診断ログ] をクリックします。

4. [記録されるイベントの設定] セクションの [カテゴリの選択] の一覧で、[MS Search クエリ プロセッサ] をクリックします。

5. [トレース ログの記録対象となる重要度の最も低いイベント] の一覧で、[高] をクリックします。

6. ページの下部の [OK] をクリックします。

Log Parser ツールを使用する

インターネット インフォメーション サービス (IIS) ログと同様、Office SharePoint Server 2007 ULS ログは非常に大きなテキスト ファイルです。こうしたファイルの内容を解析するには、ログ解析ユーティリティを使用して必要なトレースに焦点を当て、データの書式を設定します。Microsoft Log Parser 2.2 (https://go.microsoft.com/fwlink/?linkid=148542&clcid=0x411) は、この目的での使用に適した無料のツールです。

Log Parser ツールは、コマンドライン プログラムです。以下のパラメータを使用して、ULS ログが Unicode 形式のタブ区切りテキスト ファイルであることを指定する必要があります。

logparser -i:TSV -iCodepage:-1 -fixedSep:ON

これらのパラメータの他に、Transact-SQL-style クエリを指定して、ログ ファイルの解析方法を Log Parser に指示する必要があります。たとえば、クエリ プロセッサ タイマ メッセージに焦点を当てるには、以下の WHERE 句を使用します。

WHERE Category = 'MS Search Query Processor' AND Message LIKE '%Completed query execution with timings:%'

注意

SQL クエリのテキストは Log Parser コマンド プロンプトに直接入力できます。また、テキスト ファイルに保存し、file: パラメータを使用して、そのファイルの場所を Log Parse に渡すこともできます。この方法は長いクエリや複雑なクエリ、およびよく使用するクエリを実行する場合に役立ちます。

ULS ログの検索メッセージ

上記のとおりに ULS が構成されている場合、ユーザーがクエリを実行すると、以下のメッセージが表示されます。

• Completed query execution with timings

  クエリが完了したことを示します。クエリの実行に関する 6 種類の時間がミリ秒単位で示されています。この 6 つの時間は以下のとおりです。

  • v1。クエリの処理に要した合計時間。

  • v2。重複の検出後に測定されたクエリの待機時間。

  • v3。セキュリティによるトリミングの後に測定されたクエリの待機時間。

  • v4。インデックスからの結果を検索データベースからの結果に結合した後に測定されたクエリの待機時間。

  • v5。インデックス サーバーからの結果の待機に要した時間。

  • v6。データベースへの呼び出しで、検索データベースからの取得プロパティの除外に要した時間。

  この 6 種類の時間から以下の情報を計算できます。

  • v1 - v2。プロパティの取得および検索語句の強調表示に要した時間。

  • v2 - v3。重複の検出に要した時間。

  • v3 - v4。セキュリティによるトリミングに要した時間。

  • v4 - v5。検索データベースへのインデックス結果の結合に要した時間。

• Join retry

  検索データベースから返された結果とフルテキスト インデックスから返された結果が一致せず結合できなかったので、再試行されたことを示します。

• Security Trimming retry

  ユーザーが実行したクエリが、そのユーザーに読み取り権限がない結果を返したことを示します。このようなクエリはさらに多くの結果を要求し、十分な結果が返されるまで再試行されます。

• Near duplicate removal retry

  ほぼ同じドキュメントが多数存在し、これらが結果から取り除かれために、表示するのに十分な数の結果がクエリ プロセッサにないことを示します。このようなクエリはさらに多くの結果を要求し、十分な結果が返されるまで再試行されます。

クエリ時間を解析する

クエリ処理における遅延を診断するとき、このセクションで説明したメッセージの中で最もよく使用されるのが Completed query execution with timings というメッセージです。たとえば、セキュリティによるトリミングの速度が遅い場合は、合計処理時間 v1 に対する v3 – v4 計算がかなり大きな割合を占めることになります。

時間を解析するには、以下の SQL クエリを Log Parser ツールに渡します。このツールによって、v1 ～ v6 の時間とその相違点が含まれているコンマ区切りのファイルが作成されます。

Select  Timestamp,
TO_INT(Extract_token(Message,7, ' ')) as TotalQPTime,
      TO_INT(Extract_token(Message,8, ' ')) as v2,
      TO_INT(Extract_token(Message,9, ' ')) as v3,
      TO_INT(Extract_token(Message,10, ' ')) as v4,
      TO_INT(Extract_token(Message,11, ' ')) as TimeSpentInIndex,
      TO_INT(Extract_token(Message,12, ' ')) as v6,
      SUB(v4, TimeSpentInIndex) as JoinTime,
      SUB(v3, v4) as SecurityTrimmingTime,
      CASE v2
           WHEN 0 THEN 0 
           ELSE SUB(v2, v3) 
      End as DuplicateDetectionTime,
      SUB(TotalQPTime, v2) as FetchTime
INTO QTiming
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log'
WHERE Category = 'MS Search Query Processor' 
AND Message LIKE '%Completed query execution with timings:%'

結果として作成された CSV ファイルは Microsoft Office Excel または他の分析ツールにインポートして、グラフおよびレポートを作成できます。稼働率の高いシステムでは多くのクエリが実行されていることを考慮してください。適切な分析を行うには、多数の結果の平均をとらなければならないことがあります。

再試行を解析する

Completed query execution with timings メッセージで入手できる時間のデータには、再試行に関する情報 (セキュリティによるトリミングが原因で発生した再試行など) は一切含まれません。クエリ プロセッサで再試行に要した時間を解析するには、クエリの合計数とさまざまな種類の再試行の数を比較する必要があります。

以下のクエリでは、実行されたクエリの合計数がカウントされます。

SELECT count (Message) 
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log' 
WHERE Category = 'MS Search Query Processor' 
AND Message LIKE '%Completed query execution%'

以下のクエリでは、セキュリティによるトリミングが原因で発生した再試行の合計数がカウントされます。

SELECT count (Message) 
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log' 
WHERE Category = 'MS Search Query Processor' 
AND Message LIKE '%Security trimming retry%'

以下のクエリでは、重複結果が削除されたことにより発生した再試行の合計数がカウントされます。

SELECT count (Message) 
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log' 
WHERE Category = 'MS Search Query Processor' 
AND Message LIKE '%Near duplicate removal retry%'

これらのクエリを使用して、再試行によってクエリ結果がどのように遅延しているかを診断します。クエリの合計数に対する再試行の数の割合が高い場合は、構成の変更を検討する必要があります。たとえば、コンテンツ ソースの 1 つにあるドキュメントにわずかなユーザーしかアクセスできないと、セキュリティ トリミングによる再試行数が増加することがあります。この場合は、このソースをインデックスから削除することを検討します。

Office SharePoint Server 2007 用に SQL Server を最適化する

Microsoft Office SharePoint Server 2007 では、Microsoft SQL Server を使用して、インデックス コンテンツのプロパティ、構成情報、およびコンテンツを保存します。Office SharePoint Server で最適なパフォーマンスを確保するには、SQL Server を最適化する必要があります。

注意

Office SharePoint Server 2007 では、SQL Server 2008 または SQL Server 2005 に保存されたデータベースを使用できます。

一般的な SQL Server の最適化

最適化の中には、サーバーの目的に関係なく SQL Server のパフォーマンスを向上させるものがあります。これらの最適化は、必ず Office SharePoint Server データベースに対して行うようにしてください。

データベース サーバーを計画および展開するときは、以下の推奨事項を考慮してください。

• 可能な場合は、専用サーバーまたはサーバー ファームで SQL Server を実行します。

• サーバー ファームで複数のデータベース サーバーにスケール アウトします。一般的には、最大限の能力で稼働している 4 台の Web サーバーすべてにデータベース サーバーをインストールする必要があります。

• コンピュータ上で 64 ビット バージョンの SQL Server および 64 ビット オペレーティング システムを使用します。

• ハードウェア予算が許す限り多くの物理ディスク スピンドルを使用します。

• 高速ディスクを使用します。

• データベースを RAID 1+0 または RAID 1 ディスク アレイに配置します。

• プライマリ データ ファイルおよびセカンダリ データ ファイルが保存されていない物理ディスクにログ ファイルを切り離して配置します。

注意

一般的な SQL Server の最適化の詳細については、この Office SharePoint Server の記事では説明しません。詳細については、以下のリソースを参照してください。

• Storage Top 10 Best Practices (英語) (https://go.microsoft.com/fwlink/?linkid=148543&clcid=0x411)

• SQL Server Best Practices Article (英語) (https://go.microsoft.com/fwlink/?linkid=148544&clcid=0x411)

• RAID レベルと SQL Server (https://go.microsoft.com/fwlink/?linkid=105581&clcid=0x411)

検索クエリおよびインデックス作成用に SQL Server を最適化する

多くの Office SharePoint Server 2007 管理者にとっての最優先事項は、クロール、インデックス作成、およびクエリの最適化です。Office SharePoint Serverのコンテンツ インデックスは SQL Server データベース外のファイル システムに保存されています。しかし、検索データベースには、インデックス ファイルのメタデータと ACL が保存されています。したがって、SQL Server のパフォーマンスは、以下の 2 つの検索操作に直接影響します。

• インデックス作成 (Office SharePoint Serverにメタデータと ACL が保存されている場合)

• クエリの実行。すべてのOffice SharePoint Serverで、セキュリティによるトリミングが行われます。この間、Office SharePoint Serverは検索データベースの ACL を確認し、ユーザーへの表示が許可されていない結果を削除します。また、ユーザーがプロパティ検索を実行した場合は、検索データベースからメタデータが取得されなければなりません。

最初は、この記事で説明した一般的な SQL Server の最適化に関する推奨事項に従う必要があります。また、次のセクションで説明する最適化は特にインデックス作成とクエリで役立ちます。

tempdb データベースのパフォーマンスを最適化する

すべてのユーザー クエリに、SQL Server の tempdb データベース操作が伴います。したがって、このデータベースの構成は、クエリ応答がユーザーに表示される速度に直接影響します。

tempdb を最適化するには、以下の手順を実行します。

• 復旧モデルを SIMPLE に設定します。

• tempdb ファイルを必要に応じて自動拡張できるようにします。

• ファイル拡張の増分単位を適切な値に設定します。通常、この値は tempdb ファイル サイズの約 10% に設定します。

• クロールおよびクエリの実行中のすべての操作に対応できる値にファイル サイズを設定することで、tempdb ファイルの領域を事前に割り当てます。

• 複数のデータ ファイルを使用してディスクの帯域幅を最大化します。通常は、SQL Server を実行しているコンピュータの CPU コアごとに 1 つのデータ ファイルを使用します。

• 各データ ファイルを同じサイズにします。

• コンテンツ データベースが保存されているディスクとは別の物理ディスクに tempdb データベースを配置します。

注意

tempdb 最適化の詳細については、「tempdb のパフォーマンスの最適化」(https://go.microsoft.com/fwlink/?linkid=148537&clcid=0x411) を参照してください。

ファイル グループを使用してパフォーマンスを向上させる

Office SharePoint Server 2007 のクロールおよびインデックス作成処理では I/O が集中的に発生し、大量のデータが検索データベースに書き込まれます。システムにオフピーク時がある場合、インデックス作成はこの時間に行われるようにスケジュールし、インデックス作成で使用するリソースがユーザー クエリのリソースと競合しないようにします。ただし、一部の世界的組織、または 24 時間稼働している組織では、需要が大幅に低下する時間帯はありません。検索データベースをホストするデータベース サーバーがその I/O 能力に近い場合は、他の方法でインデックス作成の I/O 操作を、ユーザー クエリに関連する I/O 操作から切り離すことを検討します。

検索データベースは、インデックス作成用のテーブルと、主にユーザー クエリで使用するテーブルに分割できます。これらのテーブルのグループを 2 つの物理ディスクに切り離して配置すると、インデックスによるクエリ パフォーマンスへの影響を最小限に抑えられます。インデックス テーブルとクエリ テーブルが 1 つのデータベースにあっても、Microsoft SQL Server のファイル グループ機能を使用することで切り離すことができます。

これを行うには、ユーザー ファイル グループを作成し、そのグループの中にセカンダリ データ ファイルを作成します。このデータ ファイルは、パフォーマンスを向上させるために専用の物理ディスクに配置する必要があります。そして、以下の手順に従って、このファイル グループにインデックス作成用のテーブルを移動します 。検索データベースのサイズによっては、この手順に相当な時間がかかる場合があります。したがって、この手順は、需要が少ない時間帯に実行します。

注意

テーブルを移動する Transact-SQL スクリプトなど、検索データベースのファイル グループを使用する方法の詳細については、「SQL File groups and Search (英語)」(https://go.microsoft.com/fwlink/?linkid=132066&clcid=0x411) を参照してください。

インデックス テーブルを専用のファイル グループに分割するには

1. SQL Server Management Studio で、検索データベースを右クリックし、[プロパティ] をクリックします。

2. [ページの選択] ボックスの一覧で [ファイル グループ] をクリックします。

3. [追加] をクリックし、"CrawlFileGroup" という新しいファイル グループ名を付けます。

4. [ページの選択] ボックスの一覧で [ファイル] をクリックします。

5. [追加] をクリックし、新しいファイルに名前を付けます。

6. [ファイル グループ] セルで、[CrawlFileGroup] を選択します。

7. [パス] セルで、PRIMARY ファイル グループとは別の物理ディスクのパスを選択します。

8. [OK] をクリックします。

9. SQL Server Management Studio で、[新しいクエリ] をクリックします。

10. 以下のクエリをクエリ ウィンドウにコピーして、[実行] をクリックします。この Transact-SQL コードでは、テーブルを新しいファイル グループに移動する新しいストアド プロシージャが作成されます。

    IF EXISTS (SELECT * FROM sysobjects WHERE type = 'P' AND name = 'proc_MoveTableToFileGroup')
       BEGIN
          DROP  Procedure  dbo.proc_MoveTableToFileGroup
       END
    GO
    CREATE PROCEDURE [dbo].[proc_MoveTableToFileGroup]
    (
       @fileGroup sysname,
       @tableName sysname
    )
    as
    begin
       declare @data_space_id int
       declare @object_id int
       declare @index_id int
       declare @index_name sysname
       declare @object_name sysname
       declare @fileGroupName sysname
       declare @index_cols nvarchar(4000)
       declare @sql nvarchar(4000)
       declare @key_ordinal int
       set @index_id = 0
       set @key_ordinal = 0
       select @data_space_id = data_space_id, @fileGroupName = name from sys.filegroups where name = @fileGroup
       if @data_space_id is null
       begin
          raiserror ('The specified filegroup does not exist.', 16, 1)
          return
       end
       while 1=1
       begin
          select top 1
                @object_id = i.object_id, 
                @index_id = i.index_id,
                @index_name = i.name,
                @object_name = o.name
             from 
                sys.indexes AS i
             inner join 
                sys.objects AS o
             ON
                i.object_id = o.object_id
             where 
                i.index_id > 0 and
                o.type = 'U' and
                o.name = @tableName and
                i.index_id > @index_id and
                i.data_space_id <> @data_space_id
             order by i.index_id
          if @@rowcount = 0 
          begin
             if @index_id = 0
                print 'There are no indexes to move to filegroup ' + @fileGroupName + ' for table ' + @tableName
             break
          end
          set @index_cols = null
          set @key_ordinal = 0
          while 1=1
          begin
             select top 1 
                @index_cols = case when @index_cols is null then '[' + c.name + ']' else @index_cols + ', [' + c.name + ']' end + 
                case when i.is_descending_key = 0 then ' asc' else 'desc' end, 
                @key_ordinal = i.key_ordinal
             from 
                sys.index_columns i 
             inner join 
                sys.columns as c
             on 
                i.object_id = c.object_id and
                i.column_id = c.column_id
             where 
                i.object_id = @object_id and 
                i.index_id = @index_id and 
                i.key_ordinal > @key_ordinal
             order by i.key_ordinal
             if @@rowcount = 0 
                break
          end
          select @sql = 
             case when i.is_primary_key = 1 then 
                N'begin try ' + 
                N'begin tran ' + 
                N'alter table [' + @object_name + '] drop constraint [' + i.name + '] ' + 
                N'alter table [' + @object_name + '] add constraint [' + i.name + '] ' + 
                'primary key ' +
                case when  i.type = 1 then 'clustered ' else 'nonclustered ' end +
                ' (' + @index_cols + ') ' + 
                'with (' +
                'IGNORE_DUP_KEY = ' + case when  i.ignore_dup_key = 1 then 'ON ' else 'OFF ' end +
                ', PAD_INDEX = ' + case when  i.is_padded = 1 then 'ON ' else 'OFF ' end +
                case when  i.fill_factor = 0 then '' else ', FILLFACTOR = ' + CONVERT(nvarchar(10),i.fill_factor) end + 
                ') ' + 
                'ON [' + @fileGroupName + ']' + 
                N' commit ' + 
                N'end try ' + 
                N'begin catch ' + 
                N'rollback ' + 
                N'end catch ' 
             else 
                N'create ' + 
                case when  i.is_unique = 1 then 'unique ' else '' end +
                case when  i.type = 1 then 'clustered ' else 'nonclustered ' end +
                'index [' + i.name + '] on [' + @object_name + '] (' + @index_cols + ') ' + 
                'with (' +
                'IGNORE_DUP_KEY = ' + case when  i.ignore_dup_key = 1 then 'ON ' else 'OFF ' end +
                ', PAD_INDEX = ' + case when  i.is_padded = 1 then 'ON ' else 'OFF ' end +
                case when i.fill_factor = 0 then '' else ', FILLFACTOR = ' + CONVERT(nvarchar(10),i.fill_factor) end + ', DROP_EXISTING = ON ) ' + 
                'ON [' + @fileGroupName + ']'
             end
    from 
             sys.indexes AS i
          where 
             i.object_id = @object_id and
             i.index_id = @index_id
          print 'Moving index ' + @index_name + ' to filegroup ' + @fileGroupName 
          print @sql
          print ''
          exec sp_executesql @sql
       end
    end
    

11. SQL Server Management Studio で、[新しいクエリ] をクリックします。

12. 以下のクエリをクエリ ウィンドウにコピーして、[実行] をクリックします。この Transact-SQL コードでは、インデックス テーブルごとに新しいストアド プロシージャが実行されます。

    declare @fileGroup sysname
    set @fileGroup = 'CrawlFileGroup'
    if not exists (select 1 from sys.filegroups where name = @fileGroup)
    begin
       raiserror ('The specified filegroup does not exist.', 16, 1)
       return
    end
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorChangeLog'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorPendingChangeLog'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorText'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorTransactions'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlChangedSourceDocs'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlChangedTargetDocs'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlContent'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlDeletedErrorList'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlDeletedURL'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlErrorList'
    begin try
       begin tran
       IF  EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id = OBJECT_ID(N'[dbo].[FK_MSSCrawlContent_MSSCrawlHistory]') AND parent_object_id = OBJECT_ID(N'[dbo].[MSSCrawlContent]'))
       ALTER TABLE [dbo].[MSSCrawlContent] DROP CONSTRAINT [FK_MSSCrawlContent_MSSCrawlHistory]
       exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlHistory'
       ALTER TABLE [dbo].[MSSCrawlContent]  WITH CHECK ADD  CONSTRAINT [FK_MSSCrawlContent_MSSCrawlHistory] FOREIGN KEY([CrawlID])
       REFERENCES [dbo].[MSSCrawlHistory] ([CrawlID])
       commit
    end try
    begin catch 
       rollback
    end catch
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlHostList'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlQueue'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlURL'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlURLLog'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSTranTempTable0'
    

検索で使用する SQL Server データベースを維持する

複雑なシステムと同様、SQL Server データベースで最大限のパフォーマンスを維持するには定期的なメンテナンスが必要です。このセクションでは、最大限のパフォーマンスを維持するための推奨プラクティスについて説明します。

以下のディスク メンテナンス手順によって、データベース サーバーのパフォーマンスを向上させることができます。

• データベースを拡張できるように少なくとも 25% のディスク空き容量を確保します。ディスク サイズと空き容量を定期的に監視し、この割合が低下しないようにしてください。管理者が新しいコンテンツ ソースを追加すると、検索データベースのサイズが急速かつ大幅に拡大する場合があります。

• ディスク コントローラでディスク書き込みキャッシュが使用されている場合は、バックアップ バッテリがあることを確認し、電源障害が発生してもサービスが中断されないようにします。

以下の SQL Server メンテナンス手順によって、データベース サーバーのパフォーマンスを向上させることができます。

• DBCC CHECKDB Transact-SQL ルーチンをすべての Office SharePoint Server データベースに対して定期的に実行します。ただし、このルーチンを実行すると、SQL Server コンピュータに大幅な負荷がかかるため、応答速度に影響する場合があります。そこで、PHYSICAL_ONLY オプションを使用して、DBCC CHECKDB をオフピーク時にスケジュールします。このルーチンを Office SharePoint Server のクロール中に実行しないでください。

• SQL Server を実行している本番コンピュータで、サポートされていない操作を実行しないでください。たとえば、データベースの照合順序を変更したり、Office SharePoint Serverのデータベース テーブルに列を追加したりしないでください。サポートされていない操作の詳細については、マイクロソフト サポート技術情報の記事「Office サーバー製品や Windows SharePoint Services によって使用されているデータベースへの変更のサポート」(https://go.microsoft.com/fwlink/?linkid=105589&clcid=0x411) を参照してください。

時間が経つと、検索データベースをサポートする SQL Server インデックスが断片化し、これがインデックス作成やクエリのパフォーマンスに影響を及ぼす可能性があります。マイクロソフト サポート技術情報の記事 943345 には、proc_DefragmentIndices と呼ばれるストアド プロシージャを作成する Transact-SQL スクリプトが記載されています。proc_DefragmentIndices を使用すると、Office SharePoint Server ファームで検索データベースとコンテンツ データベースの両方を最適化できます。ただし、このストアド プロシージャは、非常に多くのサーバー リソースを必要とします。したがって、これを使用する場合は、クエリ応答の速度が低下しないように細心の注意を払う必要があります。

注意

proc_DefragmentIndices スクリプトおよびその使用方法の詳細については、「Windows SharePoint Services 3. 0 のデータベースや SharePoint Server 2007 データベースを最適化する方法」(https://go.microsoft.com/fwlink/?linkid=105588&clcid=0x411) を参照してください。

また、Office SharePoint Serverの検索データベースのために設計された proc_DefragSearchIndexes と呼ばれる最適化ストアド プロシージャを使用することもできます。これは、IX_MSSDocProps や IX_MSSDocSdids など、パフォーマンスに対する効果が最大限に発揮されるインデックスのみを最適化することで、データベース サーバー リソースの需要を最小限に抑えます。このストアド プロシージャは、オフピーク時に実行されるようにスケジュールし、ユーザーへの影響を慎重に監視する必要があります。

注意

proc_DefragSearchIndexes スクリプトとその使用方法の詳細については、Microsoft Enterprise Search Blog の「SQL Index defrag and maintenance tasks for Search (英語)」(https://go.microsoft.com/fwlink/?linkid=158799&clcid=0x411) を参照してください。

ファームのデータベース サーバーでディスクまたは RAID のボトルネックを診断する場合は、次の操作により問題の影響が軽減される可能性があります。

• データ ファイルおよびトランザクション ログの場所を、別のディスクまたは RAID アレイに変更します。この記事で説明したように、ファイル グループを使用するとパフォーマンスを最大限に高めることができます。

• ディスクを RAID アレイに追加する。

• 低速ディスクを高速ディスクに取り替えます。

クローラ中止を回避する

大規模組織または複雑な組織では、Office SharePoint Server 2007 インデックス システムを構成するにあたり解決すべき問題が山積みです。たとえば、クロールに時間がかかる、非常に大きなコンテンツのコーパスを持つさまざまなコンテンツ ソースが多数存在する場合があります。また、検索結果に最新のコンテンツが反映されるように、インデックスのエントリの鮮度について慎重に計画された目標も必要です。鮮度目標を達成するには、インデクサがすべてのコンテンツを定期的にクロールできるように、そのインデクサのパフォーマンスを最適化する必要があります。

インデックス作成の速度の主な妨げになっているのがクローラ中止です。クローラが中止状態になるのは、キュー内の次のドキュメントを取り出すために、別のスレッドを割り当てることができないときです。中止の原因として考えられるものを以下に示します。

• 検索データベースをホストするデータベース サーバー上のリソースに対して、競合が発生している

• クロールに参加しているホスト数が多すぎる

• ホストがスレッドをすぐに解放しない (この記事では、このホストは "ハングリ" ホストとも呼ばれる)。

• バックアップがクロールと同時に実行されている

ハングリ ホストによりスレッドがロックされ、そのスレッドが次のドキュメントに移動できなくなります。このロックは、以下の場合に発生する可能性があります。

• CPU、メモリ、またはその他のリソースが不足しているためホストの速度が遅い。

• ホストで増分クロールを対象とした追加作業が必要である。たとえば、ソースが SharePoint Portal Server 2003 サーバーの場合、権限が変更されたときに、クローラはドキュメント全体を再処理する必要があります。

• ホストまたはドキュメントのプロパティがリッチである。各ドキュメントにプロパティが多数存在する場合、検索データベースをホストするデータベース サーバーはさらに激しく動作します。ビジネス データ カタログのコンテンツ ソースおよび個人用サイトには、通常、多くのプロパティがあります。

最も効率的なクロールは、通常、以下の種類のホストで発生します。

• Office SharePoint Server 2007 サーバー。これらのサーバーでは、クローラが使用できる変更のログが維持されます。

• ファイル共有。クローラはフォルダ レベルで変更を確認できます。各ドキュメントを調べることはしません。

• Exchange パブリック フォルダ。クローラはフォルダ レベルで変更を確認できます。各投稿を調べることはしません。

中止を回避するためのガイドライン

クローラ中止を最小限に抑えるには、次のベスト プラクティスに従います。

• コンテンツ ソースの数を最小限に抑えます。これにより、同様のサイズおよび種類のホストを、より効率的に 1 つのコンテンツ ソースにグループ化できます。

• 大規模な Office SharePoint Server 2007 ホストをクロールしてから、他のホストの種類を追加します。これらのホストは非常に効率的にクロールでき、増分クロールによって極めて迅速にスレッドが解放されます。

• 複数のハングリ ホストに対するクロールを同時に行うようにスケジュールしないでください。

• 出発点として、4 つの同時クロールをスケジュールします。一部のインデックス サーバーについては、この数を増やせる場合があります。詳細については、この記事の次のセクションを参照してください。

• クローラ中止が発生した場合は、ハングリ ホストのクロールを一時停止してスレッドを解放します。

中止を診断する方法

新しい Office SharePoint Server 2007 検索システムをインストールするときに、数日または数週間にわたって新しいコンテンツ ソースを追加することで、クローラ構成を構築します。各コンテンツ ソースを追加しながらシステムのパフォーマンスを監視し、中止を回避してトラブルシューティングを容易に行えるようにします。このようにして、クロール中のシステムの動作を十分に理解できます。

クローラが使用するスレッドの数は、[インデクサのパフォーマンス] の設定によって決まります。この設定を変更するには、[サーバーの全体管理] で [サーバー構成の管理] タブをクリックし、[サーバーのサービス] をクリックして、[Office SharePoint Server Search] をクリックします。以下の表は、[インデクサのパフォーマンス] の設定でクロール スレッドを制御する方法を示しています。

インデクサのパフォーマンス設定	スレッドの合計数	ホストごとの最大スレッド数
低下	プロセッサの数	プロセッサの数
一部低下	プロセッサ数の 4 倍	プロセッサ数 + 4
最大	プロセッサ数の 16 倍	プロセッサ数 + 4

Office SharePoint Server 2007 では、クロール スレッド数は 64 を超えません。

中止の最も一般的な原因は、データベース サーバー上でのリソースの競合です。この競合を診断するには Archival Plugin を監視します。パフォーマンス モニタで、Office Server Search Archival Plugin オブジェクトと、Total docs in first queue カウンタおよび Total docs in second queue カウンタを使用してください。このカウンタの両方について、Portal_Content インスタンスが 500、または ProfileImport インスタンスが 50 である場合、クローラは中止されています。この場合は、この記事の「Optimizing SQL Server for search in Office SharePoint Server 2007」で説明したように、データベース サーバーを調整することを検討してください。

Archival Plugin が原因ではない中止状態を診断するには、パフォーマンス モニタの Office Server Search Gatherer オブジェクトを使用します。Idle Threads、Threads Accessing Network、および Threads In Plug-ins カウンタを確認し、この値と、システムに対するスレッドの合計数を比較してください。これらのカウンタの詳細については、この記事の「Monitoring index servers」を参照してください。

アクセス制御リストによって発生するボトルネックを回避する

Office SharePoint Server 2007 はコンテンツ ソースに対するクロールおよびインデックス作成を実行するときに、アクセス制御リスト (ACL) を確認して検索データベースに保存します。ユーザーがインデックスを検索すると、検索結果ごとに検索データベースが検査され、その結果へのアクセスがユーザーに許可されていることが確認されます。この処理は、セキュリティによるトリミングとも呼ばれます。ACL のサイズが大きく、多数のレベルで入れ子になっている場合、この ACL は、Office SharePoint Server内での検索とクロール処理の両方のパフォーマンスに悪影響を及ぼす可能性があります。このセクションでは、こうしたパフォーマンス低下を最小限に抑える方法について説明します。

Active Directory は、以下の種類のセキュリティ プリンシパルを提供します。これらのセキュリティ プリンシパルは、Office SharePoint Serverのサイトやインデックス コンテンツをセキュリティで保護するのに役立ちます。

• ユーザー アカウント

• グローバル グループ

• ドメイン ローカル グループ

• ユニバーサル グループ

Office SharePoint Server 2007には、SharePoint グループもあります。このシステムは非常に柔軟で複数の層の入れ子を使用できますが、セキュリティ プリンシパルが Office SharePoint Server の検索パフォーマンスに悪影響を及ぼす可能性があります。

Office SharePoint Server 2007 クローラおよび検索で最大限のパフォーマンスを確保するには、Active Directory セキュリティ プリンシパルおよび SharePoint グループを使用するときに、以下のルールに従ってください。

• ユーザー アカウントをグローバル グループに配置し、グローバル グループをローカル グループに配置します。また、権限をドメイン ローカル グループに割り当てます。これは、Active Directory でセキュリティ プリンシパルを使用するための推奨ベスト プラクティスです。これにより、ドメイン コントローラがグループ メンバシップをすばやく検索でき、ユーザーがフォレストでリソースにアクセスできるようになります。

• ユニバーサル グループが必要な場合は、同じシステムを使用しますが、グローバル グループをユニバーサル グループに配置し、ユニバーサル グループをドメイン ローカル グループに配置します。

• ドメイン ローカル グループを SharePoint グループに配置し、権限を SharePoint サイトおよびその他のリソースに割り当てます。

• グループ メンバシップで使用されている入れ子のレベルの数を制限します。

以下の状況は Office SharePoint Server 2007 の検索のパフォーマンスに悪影響を及ぼすので、回避する必要があります。

• Office SharePoint Server サイトの権限を個別のユーザーに割り当てないでください。

  2,000 を超えるセキュリティ プリンシパルが Office SharePoint Server サイトの DACL に表示されている場合、そのサイトは遅くなります。ただし、Active Directory グループまたは SharePoint グループは、そのグループに所属するユーザーの数にかかわらず 1 つのセキュリティ プリンシパルです。したがって、SharePoint グループを使用して、サイト権限を割り当てて、ユーザーまたは Active Directory グループを SharePoint グループに配置します。

• 深く入れ子にされた Active Directory セキュリティ グループを使用しないでください。

  ユーザーがOffice SharePoint Server サイトにアクセスしようとすると、サーバーはグループ メンバシップを評価してユーザーを許可する必要があります。グループが深く入れ子にされていると、ドメイン コントローラに対するクエリが多数必要です。また、フォレスト内のリモート ドメインへのクエリも必要な場合があります。これらのクエリは、ユーザーがアクセスを許可される前に完了していなければなりません。

• 連絡先が含まれるセキュリティ グループまたは配布リストを使用しないでください。

  Active Directory の連絡先はグループに追加して、たとえば、電子メールを配布できます。ただし、連絡先はセキュリティ プリンシパルではなく、認証には関与しません。連絡先が含まれるグループに権限を割り当てると、パフォーマンスが低下する可能性があります。

Office SharePoint Server 2007では、各サイトのサイト所有者がユーザーおよびグループをサイト DACL に追加できます。ボトルネックを回避するには、サイトの所有者に対してグループ メンバシップの使用方法を責任を持って指導することが重要です。

検索ボックス Web パーツが見つからない場合のトラブルシューティング

以下の場合、検索ボックス Web パーツは、Office SharePoint Server 2007 ユーザー インターフェイスの検索センタなどの場所に表示されません。

• 開発者が [検索センタ] コンテンツ ページまたはサイト マスタ ページを変更し、検索ボックス Web パーツを非表示にしたか削除した。

• サイト上でフル コントロールまたはデザインのアクセス許可レベルを持つユーザーが、検索ボックス Web パーツを非表示にしたか削除した。

• 検索サービスが中断されたか、管理者がそのサービスをオフラインにしたため、Office SharePoint Server ファームでサービスを使用できない。

注意

検索ボックス Web パーツの詳細については、「検索ボックス Web パーツのプロパティを構成する (Office SharePoint Server 2007)」を参照してください。

関連項目

概念

Office SharePoint Server 2007 のトラブルシューティング
Office SharePoint Server の検索のベスト プラクティス