次の方法で共有

Web サーバーのパフォーマンスを調整する (Office SharePoint Server)

  • [アーティクル]

この記事の内容 :

  • アーキテクチャ

  • チューニング

物理的なアーキテクチャとチューニングについて、この記事で説明する推奨事項に従うことは、Web サーバーのパフォーマンス向上に役立ちます。

アーキテクチャ

このセクションでは、Microsoft Office SharePoint Server 2007 ファーム内にある Web サーバーの構成、トポロジ、その他の側面についての検討事項に関する情報を示します。

64 ビット サーバーを Web サーバーとして使用する

業務上の明確な理由がない限り、Web サーバーは、64 ビット オペレーティング システムの 64 ビットの Office SharePoint Server 2007 にインストールすることを強くお勧めします。

32 ビット サーバーを慎重に構成する

32 ビットの Web サーバーを実行する必要がある場合は、以下の推奨事項に従ってください。

  • 32 ビット システムでは /3gb スイッチを使用しない。32 ビットの Web サーバーを実行する場合、Windows Server 2003 では、すべてのユーザー モード プロセスの処理を目的とした /3gb スイッチの使用による 2 ギガバイト (GB) の仮想アドレス空間の 3 GB への変更操作は行わないことをお勧めします。/3gb スイッチの使用を勧めない理由は、ほとんどの SharePoint サイトのトラフィックでは、オペレーティング システムを介して大量のデータが送信されるためです。したがって、オペレーティング システム用のアドレス空間として 1 GB だけ残された場合、コンピュータが不安定になる可能性があります。詳細については、マイクロソフト サポート技術情報の記事「Windows Server 2003 3 GB スイッチは、Windows SharePoint Services 2.0、それ以降のバージョンに、SharePoint Portal Server 2003 SP2 またはそれ以降のバージョンにサポートされていません。」(https://go.microsoft.com/fwlink/?linkid=105919&clcid=0x411) を参照してください。

  • 32 ビット サーバーと 64 ビット サーバーを混在させると、負荷の分散に影響を与えることがある。 Office SharePoint Server 2007 の 32 ビット バージョンを実行する Web サーバーと 64 ビット バージョンを実行する Web サーバーが混在する環境を運用できます。ただし、ネットワーク ロード バランサを、ラウンド ロビン方式のようなインテリジェンス度が低いモデルを使用するように構成した場合、32 ビットの Web サーバーが過負荷になる場合があるというリスクがあります。ロード バランサは、負荷に応じて分散を管理するように構成することをお勧めします。

    また、32 ビットと 64 ビット両方のサーバーを展開すると、サードパーティ製アプリケーション、カスタム ソリューション、パッチ、およびソフトウェア更新プログラムの状況把握や管理作業をそれぞれのアーキテクチャごとに行う必要が生じるため、ファームのメンテナンスに関するオーバーヘッドが増大します。

Web ガーデンは使用しない

Web ガーデンとは、複数のワーカー プロセスによってサポートされるインターネット インフォメーション サービス (IIS) アプリケーション プールです。Web ガーデンを使用するとページ出力のキャッシュに悪影響が出るため、エンタープライズ コンテンツ管理サイトでは使用を避けることをお勧めします。

アクティブなワークフローが多いシステムでは、リソースの追加を検討する

アクティブなワークフロー インスタンスが多いシステムでは、SQL Server 2005 を実行するコンピュータの RAM、Web サーバー、およびリソースを増やすことを検討してください。

エンド ユーザーに公開しないサービスについては、専用 Web サーバーを使用する

専用 Web サーバーとは、エンド ユーザーに公開するロード バランサには接続されていない Web サーバーです。リソースの負荷が高い次のようなサービスは専用の Web サーバーを使用して実行することをお勧めします。

  • 検索インデックス

  • サーバーの全体管理

  • プロファイル

  • Excel Services

必要な機能だけを有効にする

Office SharePoint Server 2007 にはさまざまな機能が備わっています。ユーザーに必要とされる機能のみを有効にすると、リソースをより効率的に使用できるようになります。機能の無効化の詳細については、「フィーチャーを操作する」(https://go.microsoft.com/fwlink/?linkid=105337&clcid=0x411) を参照してください。

使用負荷の高いファームでは Kerberos 認証を使用する

単位時間あたりに処理する要求件数が多いファームでは、(ビジネス上の他のニーズに合えば) Kerberos 認証を使用することをお勧めします。Kerberos 認証ではキャッシュを使用するので、認証要求の結果を迅速に返すことができます。

注意

リソース負荷の高いサーバー アプリケーションを Windows Server 2003 のドメイン メンバ上で実行していると、ユーザー認証処理に遅延が発生することがあります。詳細については、サポート技術情報の記事 906736「Windows 2000 または Windows Server 2003 でドメイン メンバに量の多いサーバー プログラムを実行すると、ユーザーの認証プロセスで遅延をするします」 (https://support.microsoft.com/kb/906736/ja-jp) を参照してください。

チューニング

このセクションでは、既存の Office SharePoint Server 2007 ファームの最適化について、構成、エンドユーザー トレーニング、メンテナンス、その他の推奨事項に関する情報を示します。

SQL Server のパフォーマンスを監視する

データベース サーバーにかかる負荷は Web サーバーにかかる負荷の原因にもなることが多いため、パフォーマンスと能力の監視は、スタックの最下位から最上位に向かって行うのが最良の方法です。たとえば、SQL Server を実行するサーバーが Web サーバーからの要求に応答するのに長い時間を要していると、エンドユーザーが Web サーバーに要求を送る頻度が通常程度であっても、Web サーバー上に要求が蓄積されていきます。その場合、結果として Web サーバーのパフォーマンスに問題があるかのような現象が発生する可能性がありますが、原因は Web サーバーでなくデータベース サーバーにあります。

では、SQL Server インデックスの断片化を監視し、マイクロソフト サポート技術情報の記事「Windows SharePoint Services 3.0 のデータベースおよび SharePoint Server 2007 データベースを最適化する方法」(https://go.microsoft.com/fwlink/?linkid=105588&clcid=0x411) で説明されている、SharePoint 製品とテクノロジにおける SQL Server 断片化のガイドラインに従ってください。検索の所要時間を大幅に短縮できる可能性があります。

ASP.NET # Induced GC カウンタの修正プログラムを適用する

Microsoft .NET Framework version 2.0 を使用して開発された Microsoft ASP.NET 2.0 Web アプリケーション (Office SharePoint Server 2007 など) を実行すると、# Induced GC パフォーマンス カウンタの値が急速に増加します。また、CPU 使用率が上がってコンピュータのパフォーマンスが低下します。この問題を解決するには、サポート技術情報の記事「[FIX]: # Induced GC のパフォーマンス カウンタ値がすぐに増加し, .NET Framework 2.0 で組み込まれている ASP.NET 2.0 Web アプリケーションを実行すると CPU 使用率なります高い」(https://go.microsoft.com/fwlink/?linkid=105921&clcid=0x411) から入手できる修正プログラムを適用してください。

可用性が向上するようにアプリケーション プールのリサイクルを構成する

可用性が向上するようにアプリケーション プールを調整するには、このセクションの説明に従ってください。

  • ファーム内に複数の Web サーバーがある場合、アプリケーション プールをリサイクルする時間の設定が Web サーバーごとに異なっていることを確認します。

  • ファーム内にあるすべての Web サーバーについて、IIS Web サイトごとに異なるタイミングでリサイクルを実行するようにします。1 つの Web サイトにある複数のアプリケーション プールを同時にリサイクルする必要がある場合は、その Web サーバーを一時的にロード バランサから削除することでリサイクル処理中のパフォーマンス低下を防ぎます。

  • 32 ビット サーバーについてアプリケーション プールのリサイクルを計画する際には、各アプリケーション プールで使用されるメモリ量を考慮し、使用メモリ量に基づいてリサイクルの頻度を変更します。メモリ リソース使用量の少ないアプリケーション プールでは、使用量の多いアプリケーション プールほど頻繁にリサイクルを行う必要はありません。

    64 ビット サーバーのメモリ管理は 32 ビット サーバーよりも効率的ですが、64 ビット サーバーについても夜間にアプリケーション プールのリサイクルをスケジュールすることをお勧めします。これは、断片化によって問題が発生する可能性を低減するために有効です。

アプリケーション プールのリサイクルの詳細については、「Overlapped Recycling And SharePoint: What Are The 64-bit Settings? (英語)」(https://go.microsoft.com/fwlink/?linkid=127018&clcid=0x411) を参照してください。

32 ビット ワーカー プロセスのリサイクルを監視および管理する

個々の 32 ビット Windows ユーザー モード プロセスには既定で 2 GB の仮想アドレス空間が割り当てられます。このアドレス空間の一部は、動的割り当てのために未使用のままにしておく必要があります。また、Office SharePoint Server における一部の操作では、動的割り当てを実行するために、連続したアドレス空間に大きなブロックを確保する必要があります。アドレス空間の断片化は長時間にわたって動作するプロセスであるほど進行するため、1.2 GB から 1.4 GB を超えるサイズになった Office SharePoint Server ワーカー プロセスには、メモリ不足エラーやその他の異常が発生し始めます。プロセスがさらにアドレス空間を消費し続けると、エラーはいっそう深刻になり、最終的には IIS によってプロセスが終了されることになります。

重要

64 ビット環境では、プロセス リサイクルの設定は既定値のままで十分適切といえる場合がほとんどなので、変更することはお勧めしません。

この問題を解決するには、それぞれの 32 ビット Web サーバー上に次のプロセスをセットアップすることをお勧めします。

  • IIS のオーバーラップしたリサイクルを使用する

    ワーカー プロセスを定期的に再起動すると、アドレス空間の断片化を軽減することができます。断片化が少ないと、プロセスの堅牢性と効率性がよくなります。IIS のオーバーラップしたリサイクル機能では、既存のユーザー要求の完了に必要な時間が確保され、SharePoint ワーカー プロセスを円滑にリサイクルできます。既存のプロセスが停止および再開される前に、新しい要求をすべて受け付ける新しいプロセスが開始されます。古いプロセスは、既存の要求への対応がすべて済んだ後、または、シャットダウン時間制限を超過した場合に終了します。

    最良のパフォーマンスを得るには、特定の時点およびメモリ利用状況が特定のレベルに達した場合にリサイクルを実行するように IIS を設定してください。

    • 仮想メモリベースのリサイクルを 1,700 MB で実行するように構成します。

    • メモリ使用のリサイクルを 1,000 MB で実行するように構成します。

    • 大きなファイルのアップロードなど、長時間実行する必要のあるユーザー要求を完了できるように、シャットダウン時間制限を少なくとも 300 秒に設定します。

    • 特定の時間帯に大きな負荷が定期的に発生する環境では、時間ベースのリサイクルを使用します。リサイクルのスケジュールは、ピーク トラフィックが始まる約 30 分前に設定します。

    32 ビット サーバーでは、これらの設定を構成しないと ASP.NET のキャッシュ管理に悪影響があります。プロセス メモリ制限を設定しない場合は制限値が自動的に算定されます。ユーザー モード アドレス空間が 2 GB の場合、物理的な RAM 容量の 60% と 800 MB のどちらか小さい値が使用されます。キャッシュがメモリをクリーンアップする処理をどの程度積極的に実行するかは、この値に基づいて決定されます。値が小さすぎると、メモリ クリーンアップ処理が必要以上に多く実行されることになります。値が大きすぎると、プロセスのサイズが大きくなりすぎて OutOfMemory 例外やその他のエラーが発生する原因になります。

    ワーカー プロセスのリサイクルの詳細については、「IIS 6.0 を使用してワーカー プロセスをリサイクルする」(https://go.microsoft.com/fwlink/?linkid=105924&clcid=0x411) を参照してください。

  • LogEventOnRecycle IIS メタベース プロパティを有効にしてプロセス リサイクルの状況を記録する

    ワーカー プロセスのリサイクルが実行されている頻度を把握するには、Internet Information Services (IIS) 6.0 メタベースの LogEventOnRecycle プロパティを使用してシステム イベント ログのエントリを生成します。ワーカー プロセスが 4 時間に 1 回より短い間隔でリサイクルされる場合は、負荷に対応するために Web サーバーを追加することを検討してください。

    フラグの設定は Adsutil.vbs を使用して実行できます。すべてのアプリケーション プール プロセスでイベント ログが記録されるようにする手順は次のとおりです。

    1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「cmd」と入力し、Enter キーを押します。

    2. Adsutil があるディレクトリに移動します。このディレクトリは、既定では %SYSTEMDRIVE%\Inetpub\AdminScripts です。

    3. 次のコマンドを入力し、Enter キーを押します。

      cscript adsutil.vbs Set w3svc/AppPools/ <アプリケーション プール名> /LogEventOnRecycle 255

      ただし、アプリケーション プール名 の部分には、イベント ログを有効にする実際のアプリケーション プールの名前を指定します。

      注意

      アプリケーション プール名に、"SharePoint- 80" のようにスペースが含まれる場合は、次の例のように、コマンド内のメタベース パスを二重引用符で囲む必要があります。

      cscript adsutil.vbs Set "w3svc/AppPools/SharePoint - 80/LogEventOnRecycle" 255

    詳細については、「IIS 6.0 でアプリケーション プールのリサイクル イベントを変更する方法」(https://go.microsoft.com/fwlink/?linkid=105925&clcid=0x411) を参照してください。

オフピーク時にメンテナンスを実行する

他のサイトが使用されている間にサイトの移動や削除を行うと、ポータル全体が反応しなくなることがあります。リソース負荷の高いメンテナンス作業は、オフピーク時に実行してください。

ページをチェックアウトしたままで放置しない

エンタープライズ コンテンツ管理を使用している場合、ページをチェックアウトしたままにすることは避け、可能であれば変更を加えるたびに迅速にチェックインしてください。チェックアウトしたままのページがあると、ページ レンダリングのパフォーマンスが低下します。

カスタマイズと Web パーツの使用状況を慎重に監視する

カスタマイズは、次の資料で説明されているベスト プラクティスに沿っているもののみ展開するようにしてください。

また、Web パーツとページのレンダリング時間についても監視が必要です。仕事仲間 Web パーツを使用すると処理負荷が高くなることがあります。他の情報を多く表示するページ上では仕事仲間 Web パーツを使用しないでください。

大きいファイルを監視および管理する

サイズが 5 MB を超えるファイルを処理する場合は、ドキュメントの最大アップロード サイズの設定を、ビジネスに必要なファイルの最大サイズと考えられる値に変更してください。ファイルの最大アップロード サイズは既定では 50 MB です。SharePoint 製品とテクノロジでサポートされている最大のファイル サイズは 2 GB です。

エンドユーザーによって頻繁にアクセスされるファイルが多数あり、それらの更新される頻度が小さい場合は、該当するファイルを Office SharePoint Server の外部に格納し、オフラインのコラボレーション クライアントの使用を検討することをお勧めします。

大きいファイルの取り扱い方についてエンドユーザーを教育する

エンドユーザーが大きいファイルをどのように扱うかによって、パフォーマンスは大きく変わります。

  • すべてのエンドユーザーについて、インターネット一時ファイル (Internet Explorer キャッシュ) 用として少なくとも 50 MB の領域、大きいファイルをよく使用する場合は、さらに大きい領域を確保してください。

  • サイズが 25 MB を超えるドキュメントを使用するエンドユーザーは、ドキュメントを各自のローカル コンピュータに保存するようにしてください。大きいファイルをドキュメント ライブラリから直接に開くと、ドキュメントを開いている間は帯域幅とリソースが消費され、また、ドキュメントに変更を加えた内容が自動保存でドキュメント ライブラリに書き込まれる可能性もあります。

    エンドユーザーがドキュメントを開く場合は、あらかじめドキュメントを右クリックして自分のコンピュータ上に保存してから作業し、編集作業が済んでからドキュメント ライブラリに変更内容をアップロードするようにしてください。

  • エンドユーザーが大きいドキュメントを表示する際は、エクスプローラ ビューではなく、[すべてのドキュメント] ビューを使用するようにしてください。SharePoint ドキュメント ライブラリをエクスプローラ ビューで表示しているとき、列挙されているファイルのいずれかにマウス カーソルを合わせると、参照しているフォルダ内のファイルすべてについてメタデータを取得する要求が送信されます。場合によっては、該当するファイル全体の内容を取得する要求が送信される可能性もあります。このため、サイズの大きいファイルをエクスプローラ ビューで多数同時に参照すると、非常に大きな負荷がサーバーにかかることがあります。

  • ドキュメント ライブラリの [編集] メニューにある [送信] サブメニューの [コピーのダウンロード] をエンドユーザーが使用することは望ましくありません。[コピーのダウンロード] を選択すると、該当するファイル全体が Web サーバーのメモリ上に開かれます。

大きいドキュメント ライブラリの取り扱い方についてエンドユーザーを教育する

エンドユーザーが大きいドキュメント ライブラリをどのように扱うかによって、パフォーマンスは大きく変わります。

  • サイズの大きいドキュメント ライブラリに対してエンドユーザーが作業する場合は、カスタマイズしたビュー フィルタを使用し、ライブラリには直接アクセスしないようにしてください。

  • エンドユーザーが大きいドキュメント ライブラリを表示する際は、エクスプローラ ビューではなく、[すべてのドキュメント] ビューを使用するようにしてください。SharePoint ドキュメント ライブラリをエクスプローラ ビューで表示しているとき、列挙されているファイルのいずれかにマウス カーソルを合わせると、参照しているフォルダ内のファイルすべてについてメタデータを取得する要求が送信されます。場合によっては、該当するファイル全体の内容を取得する要求が送信される可能性もあります。項目数の多いフォルダでは、この処理に長い時間がかかることがあり、サーバー ファームのパフォーマンスに悪影響を及ぼす可能性があります。

  • 大規模なリストを扱うビューについては、管理者がエンドユーザーと話し合ってニーズに適したビューを作成するようにし、エンドユーザー自身にビューを作成させることは避けてください。大規模なリストを多数含んだ Web アプリケーションがある場合は、その Web アプリケーション全体について [個人用ビューの管理] アクセス許可を無効に設定することを検討してください。

パフォーマンスを維持するように大規模なリストを管理する

SharePoint 製品とテクノロジでは、大規模なリストがサポートされていますが、パフォーマンスに悪影響が出ないよう、エンドユーザーのリスト表示方法を注意深く管理する必要があります。

  • 最良のパフォーマンスを得るために、1 つのリスト レベル (リストのルート、単一のフォルダなど) に含まれる項目が 2,000 個を超えないようにしてください。

  • 大規模なリストの作成や参照が必要な場合は、次のベスト プラクティスに従ってください。

    • 1 つまたは複数の列に基づくインデックスをリストに付ける。

    • 次の推奨事項に沿ってカスタマイズしたフィルタ ビューを、リストの既定ビューにする。

      • ビューから返される項目を 5,000 個未満にすること。

      • 最初のフィルタ処理にインデックス付きの列を使用し、また、その列によって項目数が十分に絞り込まれるようにすること。

      • 必要不可欠な列のみビューに表示すること。

      • ビューに含めるルックアップ列はできるだけ少なくすること。リスト内のルックアップ列がビューに 1 つ含まれるごとに、結合が行われ、余分なデータベース呼び出しが発生します。

  • リスト サイズを評価する際には、リストに含まれる列の数も考慮してください。多数の列を含んだリストの操作には時間がかかります。

大規模なリストを含んだサイトで次の設定や操作を使用するとパフォーマンスに大きく影響することに注意してください。

  • 明示的なアクセス許可 (リストやライブラリ、フォルダ、項目、ドキュメントのレベルに対するアクセス許可) の複雑な設定。個々の項目ごとに承認チェックが発生します。

  • 承認設定の変更操作。

  • インデックスの作成、更新、および削除操作。

  • コンテンツのインポートおよびエクスポート操作。

  • リストの削除操作。

  • 新しいコンテンツの種類の展開操作、または、既存のコンテンツの種類の変更操作。

タスクおよび履歴項目を大量に生成するワークフローがあると、大規模なリストが作成される可能性があります。非常に頻繁に実行されるワークフローについては、次のベスト プラクティスに従ってください。

  • 経過日数が 60 日を超えた完了済みワークフローをクリーンアップするために、AutoCleanupDays タイマ ジョブの実行を続けてください。

  • いずれかのワークフローが非常に多用されることやタスクおよび履歴項目を大量に生成することが見込まれる場合、ワークフローの関連付けを作成する際に、既定以外のタスクおよび履歴リストを使用してください。

大規模なリストを使用するサイトがあると、Stsadm のバックアップ操作で実行されるサイト コレクション バックアップのパフォーマンスが低下する可能性があることに注意してください。

大規模なリストを現在使用しているか、将来的に使用する予定がある場合は、次のドキュメントを参照されることをお勧めします。

このブックをダウンロードする

このトピックは、簡単に読んだり印刷したりできるように、次のダウンロード可能なブックに収められています。

入手できるすべてのブックの一覧については、「Office SharePoint Server 2007 のダウンロード可能なブック」を参照してください。