Windows SharePoint Services グループ作業環境のパフォーマンスと容量の要件を予測する (Office SharePoint Server)
この記事の内容 :
主要特性
テスト環境
使用法プロファイル
推奨事項
このパフォーマンスおよび容量の計画のシナリオには、エンタープライズ環境でのグループ作業とドキュメント管理に使用される単一の Windows SharePoint Services 3.0 ファームが組み込まれています。
主要特性
主要特性とは、環境要因、使用状況の特徴、シナリオにおけるその他一般的な考慮事項のことを表します。
このシナリオの主要特性は次のとおりです。
**認証/アクセス許可 **通常はユーザーの認証が行われるほか、セキュリティ グループを使用するか、ユーザー アカウントに基づいて個々のユーザーにアクセス権を付与することで、サイトとコンテンツの保護も行われます。このシナリオでは統合 Windows 認証を使用します。
**一般的な (読み取り) ユーザー操作と複雑な (読み取り/書き込み) ユーザー操作 **グループ作業環境では、ユーザーによってコンテンツの表示や投稿が行われます。このシナリオのスループット目標は、ドキュメントのアップロードまたはダウンロードなどの複雑なユーザー操作に対する応答時間を妥当な範囲にとどめるためのものです。
**時間の経過に伴うデータの増大とサイトの成長 ** Windows SharePoint Services 3.0 グループ作業環境は、初期のデータ量を予測したうえで、時間の経過に伴うデータの増大やサイトの成長にも対応できるようにする必要があります。初期のデータ量だけを考慮して規模を設定したサーバー ファームは、すぐに容量不足に陥る可能性があります。
**ユーザー応答時間 **各種操作 (一般的な操作、一般的でない操作、長時間の操作、まれにしか実行されない操作) の目標ユーザー応答時間は、「Plan for software boundaries [Windows SharePoint Services]」セクションの末尾にある表「ユーザーの応答時間」に記載されています。ユーザー応答時間の許容範囲は組織によって異なります。予想されるユーザー応答時間は、全体的なスループット目標を左右する重要な要素です。(スループットは、サーバー ファームが 1 秒あたりに処理できる要求の数と定義されています)。多くのユーザーは、より高いスループット目標により、応答時間が均一化されることを望んでいます。
**ユーザーによる同時実行 **同時実行率は 10%、特定の瞬間に同時に要求を行う同時実行ユーザーは 1% であると想定します。つまり、10,000 人のユーザーがいる場合、ソリューションを同時にアクティブに使用するユーザーは 1,000 人、アクティブに要求を行うユーザーは 100 人と想定します。
**長時間行われる非同期タスク **コンテンツのインデックス作成、データベースのバックアップなどのタスクが実行されると、サーバー ファームにパフォーマンス負荷がかかります。トポロジの例における一般的なパフォーマンス特性は、これらのタスクが夜間などのオフピーク時に行われることを前提にしたものです。したがって、業務時間中のユーザーへの応答レートは影響を受けていません。
テスト環境
このシナリオのテストは、同時実行ユーザーの数、ユーザー操作、オブジェクト (サイト コレクション、サイト、ライブラリ、リストなど) の数などの多様な要素の変化により、さまざまなファーム構成がどのような影響を受けるのかを予測できるようにするためのものです。
テスト結果からは特定の結論を導き出すことはできますが、このセクションで示す特定の容量やパフォーマンスの数値は、実際の環境では一様ではありません。これらの結果は、あくまで適切な規模の環境を設計するための手掛かりにすぎません。最初のシステム設計が完了したら、構成をテストし、そのシステムで各自の環境に固有の要素をサポートできるかどうかを確認してください。
展開のテストの詳細については、「Tools for performance and capacity planning (Windows SharePoint Services)」を参照してください。
前提
- **64 ビット アーキテクチャ **このテスト環境では、64 ビット サーバーだけが使用されています。Windows SharePoint Services 3.0 は 32 ビット サーバー上でも展開できますが、Microsoft では Windows SharePoint Services 3.0 ファームを展開する場合は 64 ビット システムを採用することをお勧めしています。詳細については、「About performance and capacity planning (Windows SharePoint Services)」の記事の「64 ビット版と 32 ビット版」セクションを参照してください。
ラボのトポロジ
詳細なテスト結果を提供するため、複数のファーム構成 (Microsoft SQL Server 2005 の実行されている単一のクラスタ化されたコンピュータと、1 ～ 8 台の Web サーバー) をテストに使用しました。また、32 ～ 256 のユーザー接続をシミュレートする 8 台のクライアント コンピュータを使用しました。
次の表に、テストに使用した具体的なハードウェアを示します。
| コンピュータのロール | ハードウェア |
|---|---|
Web サーバー |
2 つのデュアルコア Intel Xeon 2.8 GHz プロセッサ 4 GB RAM |
データベース サーバー |
4 つのデュアルコア Intel Xeon 2.8 GHz プロセッサ 32 GB RAM |
クライアント コンピュータ |
1 つの Pentium 3 1.2 GHz プロセッサ 1 GB RAM |
このテスト環境では、ギガビット (1,000,000,000 bps) ネットワークを使用しました。
使用法プロファイル
次の表に、Windows SharePoint Services 3.0 グループ作業テスト環境の使用法プロファイルを示します。Windows SharePoint Services 3.0 グループ作業シナリオの使用法プロファイルは、ほとんどのユーザー操作がチーム サイト内で行われることを前提にしています。
Windows SharePoint Services 内で行われる検索の対象範囲は、サイト コレクションです。そのため、検索操作がスループットに大きな影響を及ぼすことはありません。
次の表に、テスト環境において、記載した各種ユーザー操作により消費されるスループットの割合を示します。
| 操作 | スループットの割合 |
|---|---|
ホーム ページの取得 |
15.00 |
キャッシュ ドキュメントの取得 |
15.00 |
静的なドキュメントの取得 |
15.00 |
リスト ページ (HTML) の取得 |
10.00 |
リスト ページ (グリッド) の取得 |
10.00 |
リスト フォームの取得 |
7.00 |
404 エラー |
5.00 |
リスト アイテムの挿入 |
2.00 |
リスト アイテムの編集 |
2.00 |
リスト アイテムの削除 |
2.00 |
ドキュメントの挿入 |
2.00 |
Outlook との同期 |
2.00 |
ドキュメントの削除 |
2.00 |
URL の一覧表示 |
2.00 |
*DAV* (Distributed Authoring and Versioning) により、編集用にドキュメントを開く操作 |
1.00 |
DAV によるドキュメントの保存 |
1.00 |
*FPRPC* (FrontPage Server Extensions Remote Procedure Call) により、編集用にドキュメントを開く操作 |
1.00 |
FPRPC によるドキュメントの保存 |
1.00 |
短期間のチェックアウト |
1.00 |
電子メールの受信 |
1.00 |
*RSS* (Really Simple Syndication) |
1.00 |
ワークフローの開始 |
0.75 |
ワークフロー タスクの完了 |
0.75 |
ユーザーの追加/削除 |
0.50 |
推奨事項
ここでは、パフォーマンスと容量に関する一般的な推奨事項を説明します。これらの推奨事項を参照し、「Plan for availability (Windows SharePoint Services)」の記事を基に作成した開始トポロジの容量とパフォーマンスの特性を把握してください。また、開始トポロジをスケール アウトまたはスケール アップする必要があるかどうかも確認してください。
ハードウェアに関する推奨事項
次の表に、Web サーバーとデータベース サーバーの推奨ハードウェアの一覧を示します。システムの最小要件と推奨要件の詳細については、「Determine hardware and software requirements (Windows SharePoint Services)」を参照してください。
注意
Web サーバーとデータベース サーバーのメモリの要件は、ファームのサイズ、同時実行ユーザーの数、およびファームにおける機能やページの複雑さによって変わります。次の表に示すメモリについての推奨事項は、小規模なファームや利用の少ないファームに当てはまるものですが、メモリの使用状況は慎重に監視し、メモリを追加する必要があるかどうかを見極める必要があります。
| コンピュータのロール | 推奨ハードウェア |
|---|---|
Web サーバー |
2.5 GHz 以上のデュアルコア プロセッサ (3 GHz 以上を推奨) 2 GB の RAM (最小推奨値) 3 GB の空きディスク容量 ローカルで、またはネットワークからアクセス可能な DVD ドライブ 解像度が 1024 x 768 以上のモニタ |
データベース サーバー |
2.5 GHz 以上のデュアルコア プロセッサ (3 GHz 以上を推奨) 4 GB の RAM (最小推奨値) コンテンツとデータベース容量の比率が 1:1.2 となるハード ディスク容量。つまり、計画しているコンテンツの量が 100 GB である場合、少なくとも 120 GB の空きディスク容量と、トランザクション ログ用に追加容量が必要です。 ローカルで、またはネットワークからアクセス可能な DVD ドライブ 解像度が 1024 x 768 以上のモニタ |
開始点トポロジ
「Plan for availability (Windows SharePoint Services)」で説明されている開始点トポロジと各自のトポロジを比較することで、各自の開始点トポロジのパフォーマンスを予測できます。この作業を行えば、パフォーマンスや容量の目標に合わせて開始点トポロジの規模を変更する必要があるかどうかを簡単に判断できます。
スケール アウトしたトポロジの容量とパフォーマンス
いずれかの開始点トポロジの容量を増やし、パフォーマンスを向上させるには、より多くの容量を備えたサーバー コンピュータを実装してスケール アップするか、トポロジにサーバーを追加してスケール アウトします。ここでは、スケール アウトしたいくつかのトポロジの一般的なパフォーマンス特性について説明します。トポロジの例で、グループ作業シナリオのトポロジを拡大するための一般的な方法を示します。これには次のような方法が含まれます。
ユーザー負荷の増大に対応するには、Web サーバー コンピュータを追加します。
データ負荷の増大に対応するには、単一の (クラスタ化またはミラー化された) サーバーの容量を増やすか、64 ビット サーバーにアップグレードするか、クラスタ化またはミラー化されたサーバーを追加するなどの方法により、データベース サーバー ロールの容量を増やします。
1 台の (クラスタ化またはミラー化された) データベース サーバー コンピュータあたり 8 台までの Web サーバー コンピュータという比率を維持します。
スループット目標を推定する
スループットは、サーバー ファームが 1 秒あたりに実行できる操作の数を表します。1 秒あたりに要求される操作の数が、所定のレベルのパフォーマンスを維持するために目標とされている数よりも少ない状態が理想です。要求された操作の数が目標の数を超過すると、ユーザー操作やその他の操作が完了するまでに時間がかかるようになります。
スループットの測定単位は、秒あたりの要求 (RPS) です。一般的なエンド ユーザーの動作モデルを使用して、RPS の測定値からユーザーの合計数を求めることができます。多くの人間の動作と同じように、さまざまな "一般的な" 動作があります。Windows SharePoint Services 3.0 のユーザー モデルには、次の 2 つの変数があります。
同時実行 - アクティブにシステムを使用しているユーザーの割合。
要求レート — アクティブ ユーザーが 1 時間あたりに生成する要求の平均数。以下の表に、4 つのレベルのユーザー動作を示します。
一般的な負荷に対するおおまかなスループットの目安は、次の方法で計算できます。
ユーザーの数 × アクティブなユーザーの割合/要求レート
たとえば、1,000 人のユーザーがいるとすると、次の値が求められます。
同時ユーザー = 1,000 × 10% = 100
1 ユーザーの 1 時間あたりの予想要求数 = 36 = 1 ユーザーの 100 秒あたりの要求数 = 1
スループット = 同時ユーザー/要求レート = 100/100 = 1 RPS
そのため、1 RPS で 1 時間あたり 36 の要求を行うユーザーを最大 1,000 人サポートできることになります。
次の表に、4 つのレベルのユーザー負荷に対するスループットの目標を示します。
| ユーザー負荷 | 要求レート | サポートされるユーザー数 |
|---|---|---|
小 |
1 時間あたり 20 要求。アクティブ ユーザーは 180 秒ごとに要求を生成します。 |
スループットの 1 秒あたりの各応答は、180 人の同時ユーザーおよび 1,800 人の総ユーザーをサポートします。 |
標準 |
1 時間あたり 36 要求。アクティブ ユーザーは 100 秒ごとに要求を生成します。 |
スループットの 1 秒あたりの各応答は、100 人の同時ユーザーおよび 1,000 人の総ユーザーをサポートします。 |
大 |
1 時間あたり 60 要求。アクティブ ユーザーは 60 秒ごとに要求を生成します。 |
スループットの 1 秒あたりの各応答は、60 人の同時ユーザーおよび 600 人の総ユーザーをサポートします。 |
極大 |
1 時間あたり 120 要求。アクティブ ユーザーは 30 秒ごとに要求を生成します。 |
スループットの 1 秒あたりの各応答は、30 人の同時ユーザーおよび 300 人の総ユーザーをサポートします。 |
既に組織にグループ作業ソリューションが導入されている場合は、IIS ログを確認して、現在の環境における使用のパターンと傾向を特定できます。IIS ログの解析方法の詳細については、「Analyzing Log Files (IIS 6.0) (英語)」(https://go.microsoft.com/fwlink/?linkid=78825&clcid=0x411) を参照してください。
組織で新しいグループ作業ソリューションの展開を計画している場合は、次のセクションの情報を参照して使用パターンを予測してください。
スループット目標を推定する
前のセクションで示したサーバー ファームの推定スループット パフォーマンスは、次の想定に基づいています。
一般的な操作に対するユーザーへの応答レートは 1 秒未満
ユーザーの同時実行率は 10%
インデックス作成操作の行われる夜間の時間枠は 12 時間
このセクションの情報を基に、組織の特性に合わせてこれらの想定の値を変更してください。組織ごとに異なるスループット目標を推定できます。
テスト結果 : ファーム構成別のスループット
このセクションの表に、さまざまなユーザー操作プロファイルについてのテスト結果を示します。このテストは、この記事の前のセクション「テスト環境」に記載したハードウェアを使用して行いました。ユーザー接続の数は、テスト中に使用した固定パラメータです。
次の表に、ユーザーによる読み取り操作と書き込み操作が混在する場合と、読み取り操作のみの場合のテスト結果を示します。
| ファーム構成 | RPS | ユーザー接続の総数 | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
ユーザー負荷 : 小 |
ユーザー負荷 : 標準 |
ユーザー負荷 : 大 |
ユーザー負荷 : 極大 |
||||
混在 |
読み取り |
混在 |
読み取り |
混在 |
読み取り |
混在 |
読み取り |
混在 |
読み取り |
|
1 対 1 |
50 |
100 |
90,000 |
180,000 |
50,000 |
100,000 |
30,000 |
60,000 |
15,000 |
30,000 |
2 対 1 |
99 |
185 |
178,200 |
333,000 |
99,000 |
185,000 |
59,400 |
111,000 |
29,700 |
55,500 |
3 対 1 |
115 |
265 |
207,000 |
477,000 |
115,000 |
265,000 |
69,000 |
159,000 |
34,500 |
79,500 |
4 対 1 |
120 |
275 |
216,000 |
495,000 |
120,000 |
275,000 |
72,000 |
165,000 |
36,000 |
82,500 |
5 対 1 |
136 |
280 |
244,800 |
504,000 |
136,000 |
280,000 |
81,600 |
168,000 |
40,800 |
84,000 |
6 対 1 |
130 |
280 |
234,000 |
504,000 |
130,000 |
280,000 |
78,000 |
168,000 |
39,000 |
84,000 |
7 対 1 |
134 |
290 |
241,200 |
522,000 |
134,000 |
290,000 |
80,400 |
174,000 |
40,200 |
87,000 |
8 対 1 |
130 |
280 |
234,000 |
504,000 |
130,000 |
280,000 |
78,000 |
168,000 |
39,000 |
84,000 |
次のグラフは、フロントエンド Web サーバーの数が変わると、読み取り/書き込み操作が混在する場合、および読み取り操作のみの場合に、スループットがどのように変化するかを示したものです。ただし、このグラフは上記の表のテスト結果には基づいていません。このグラフは、フロントエンド Web サーバーがシステムに追加された際の一般的なパフォーマンスの傾向を示すためのものです。
静的なポータル サイトなどの読み取り操作だけをサポートしているシステムは、読み取り操作と書き込み操作の両方をサポートしているシステムよりも高いレベルのスループットを維持できていることに注目してください。
.gif "Windows SharePoint Services のパフォーマンス例")
ユーザー応答時間を推定する
まず、組織におけるユーザー応答時間の許容範囲を特定します。応答時間は次のように分類されます。
長 (3 ～ 5 秒) ユーザー応答時間は、このレートまでは問題なく延ばせます。
推奨 (1 ～ 2 秒) ユーザー応答時間の平均目標。
短 (1 秒未満) スピードが要求されるビジネスを行っている組織向け。
組織の要件に最も合った応答時間に基づき、ユーザー数を基にスループット目標を決定してください。単一サーバー展開では最大 1,000 人のユーザーをサポートできるため、一覧には最少人数として 500 人の場合を示します。
次の表に、ユーザー応答時間に基づくスループット目標を示します。
| ユーザーの総数 | 低速 (RPS) | 推奨 (RPS) | 高速 (RPS) |
|---|---|---|---|
500 |
0.4 |
0.5 |
0.7 |
1,000 |
0.7 |
1.0 |
1.2 |
5,000 |
4.0 |
5.0 |
6.0 |
10,000 |
9.0 |
10.0 |
12.0 |
20,000 |
18.0 |
20.0 |
24.0 |
50,000 |
40.0 |
50.0 |
60.0 |
100,000 |
90.0 |
100.0 |
120.0 |
組織に合ったスループット目標を明らかにしてから、トポロジの例のテスト データを再評価し、選択したトポロジとハードウェアが適切であるかどうかを確認してください。
同時実行率を推定する
次に、組織の同時実行率を推定します。同時実行率は、ソリューションを同時に使用しているユーザーの割合を表します。ピーク時に予測される同時実行率を使用してください。次の表に、ユーザーの総数と同時実行率に基づく推奨スループット目標を示します。
次の表に、さまざまな同時実行率ごとのスループット目標を RPS で示します。
| ユーザーの総数 | 同時実行率 : 5% | 10% | 15% | 25% | 50% | 75% | 100% |
|---|---|---|---|---|---|---|---|
500 |
0.25 |
0.5 |
0.75 |
1.25 |
2.5 |
3.75 |
5.0 |
1000 |
0.5 |
1.0 |
1.5 |
2.5 |
5.0 |
7.5 |
10.0 |
5,000 |
2.5 |
5.0 |
7.5 |
12.5 |
25.0 |
37.5 |
50.0 |
10,000 |
5.0 |
10.0 |
15.0 |
25.0 |
50.0 |
75.0 |
100.0 |
20,000 |
10.0 |
20.0 |
30.0 |
50.0 |
100.0 |
150.0 |
200.0 |
50,000 |
25.0 |
50.0 |
75.0 |
125.0 |
250.0 |
375.0 |
500.0 |
100,000 |
50.0 |
100.0 |
150.0 |
250.0 |
500.0 |
750.0 |
1,000 |
予測される同時実行率を基に組織に合ったスループット目標を明らかにしてから、トポロジの例のテスト データを再評価し、選択したトポロジとハードウェアが適切であるかどうかを確認してください。
インデックスを作成する時間枠を推定する
最後に、インデックス作成ジョブを 12 時間の夜間時間枠で完了できるかどうかを確認します。一般に Windows SharePoint Services 3.0 グループ作業環境では、ユーザーによって開始されない最も時間のかかる処理は、インデックス作成ジョブです。各自の環境でテストを行って、インデックス作成ジョブに要する時間を確認すると共に、インデックス作成ジョブによって消費されるスループットが目標とするユーザー応答時間に影響を及ぼさないかどうかを確認してください。
ディスク容量の要件を予測する
ここでは、グループ作業シナリオのディスク容量要件の予測に役立つ表を示します。ハードウェアのディスク容量の要件は、サーバー ロールやシナリオごとに大きく異なります。また、コンテンツ データベースに格納されるデータ、キャッシュの要件、検索でクロールされる外部コンテンツに左右されます。以下の説明では、予測可能なディスク容量の要件に基づき、可能な限り数値が数式に当てはめられています (インストール ファイルのサイズなど)。
まず、サーバー ロールごとのディスク容量の要件を予測します。次に、計画済みのトポロジに基づき、同じ物理的なサーバー コンピュータを共有するサーバー ロールの要件を合計します。最後に、ハードウェアのサイズが適切に設定され、ディスク容量の要件を満たしているかどうかを確認します。
さらに、SQL Server ストレージについてのベスト プラクティスをデータベース サーバーにも適用する必要があります。詳細については、「Physical Database Storage Design (英語)」(https://go.microsoft.com/fwlink/?linkid=78853&clcid=0x411) を参照してください。複数のデータベース サーバーを実装する場合は、各検索サーバーに SQL のディスク容量の要素を別々に適用してください。
注意
オペレーティング システム ファイルとプログラム ファイルは、データ ファイルとは別に、個別のドライブか RAID (*Redundant Array of Independent Disks*) に格納する必要があります。
データベース サーバーのディスク容量の要件
次の表を利用して、ファーム内のデータベース サーバーのディスク容量要件を計算してください。複数のデータベース サーバーを実装する場合は、検索サーバーごとにその合計を計算してください。
| カテゴリ | 説明 | 容量 |
|---|---|---|
オペレーティング システム ファイル |
Windows Server 2003 のセットアップとシステム ファイルに必要なディスク容量。詳細については、「インストール先パーティションのファイル システムを選択する」(http://technet2.microsoft.com/WindowsServer/ja/library/cd14bdf1-73df-4817-8291-2892d5bfc97b1041.mspx?mfr=true) を参照してください。 |
4 GB |
スワップ ファイル |
既定では、スワップ ファイルのサイズは物理メモリのサイズと同じになります。 |
|
SQL Server のインストール ファイル |
SQL Server のセットアップとプログラム ファイルに必要なディスク容量。詳細については、「SQL Server 2005 Standard Edition システム要件」(https://www.microsoft.com/japan/sql/editions/standard/sysreqs.mspx) を参照してください。 |
425 MB |
データベース ログ ファイル |
ログ ファイル用のディスク容量は、ログ設定やデータベースの数によって異なります。詳細については、「Physical Database Storage Design (英語)」(https://go.microsoft.com/fwlink/?linkid=78853&clcid=0x411) を参照してください。 |
|
構成データベース |
構成データベースのサイズは、これ以上大きくなりません。 |
1.5 GB |
コンテンツ データベース |
コンテンツ データベースに保存されるコンテンツの初期の量を予測してください。次の要素も考慮してください。
|
|
将来的なデータの増加 |
将来的なデータの増加は、グループ作業シナリオの大きな特徴です。データ量は初期の量の 2 倍になると考えておく必要があります。各自の環境に合った数値を入力してください。 |
|
空き容量 |
各ハード ディスクやボリュームに少なくとも 25% の空き容量を残します。 |
|
合計 |
検索サーバーのディスク容量の要件
次の表を利用して、ファーム内の検索サーバーのディスク容量要件を計算してください。複数の Windows SharePoint Services 3.0 検索サーバーを実装する場合は、検索サーバーごとにその合計を計算してください。
| カテゴリ | 説明 | 容量 |
|---|---|---|
オペレーティング システム ファイル |
Windows Server 2003 のセットアップとシステム ファイルに必要なディスク容量。詳細については、「インストール先パーティションのファイル システムを選択する」(http://technet2.microsoft.com/WindowsServer/ja/library/cd14bdf1-73df-4817-8291-2892d5bfc97b1041.mspx?mfr=true) を参照してください。 |
4 GB |
ページング ファイル |
既定では、ページング ファイルのサイズは物理メモリのサイズと同じになります。 |
|
Windows SharePoint Services 3.0 インストール ファイル |
これは、完全インストール時のおおよそのサイズです。 |
1.3 GB |
Microsoft .NET Framework Version 3.0 |
60 MB |
|
コンテンツ インデックス |
インデックス サーバーによりインデックス付けされるコンテンツ データベースのコンテンツの量を追加してください。この量を 2 で割って得られた数値がコンテンツ インデックスの推定サイズとなります。 |
|
空き容量 |
各ハード ディスクやボリュームに少なくとも 25% の空き容量を残します。 |
|
合計 |
Web サーバーのディスク容量の要件
次の表を利用して、ファーム内の Web サーバーのディスク容量要件を計算してください。
| カテゴリ | 説明 | 容量 |
|---|---|---|
オペレーティング システム ファイル |
Windows Server 2003 のセットアップとシステム ファイルに必要なディスク容量。詳細については、「インストール先パーティションのファイル システムを選択する」(http://technet2.microsoft.com/WindowsServer/ja/library/cd14bdf1-73df-4817-8291-2892d5bfc97b1041.mspx?mfr=true) を参照してください。 |
4 GB |
スワップ ファイル |
既定では、スワップ ファイルのサイズは物理メモリのサイズと同じになります。 |
|
Windows SharePoint Services 3.0 インストール ファイル |
1.3 GB |
|
.NET Framework Version 3.0 |
60 MB |
|
空き容量 |
各ハード ディスクやボリュームに少なくとも 25% の空き容量を残します。 |
|
合計 |
パフォーマンスの監視
システムのスケール アップやスケール アウトを行うべき時期を見極めるうえで、パフォーマンス カウンタを使用したシステムの正常性の監視が重要になります。次の表の情報を参照して、監視に使用するパフォーマンス カウンタと、その適用対象のプロセスを特定してください。
Web サーバー
次の表に、パフォーマンス カウンタと、ファーム内の Web サーバーにおける監視対象のプロセスを示します。
| パフォーマンス カウンタ | 適用対象のプロセス | メモ |
|---|---|---|
% Processor time |
全体 |
このスレッドがプロセッサを使用して命令を実行するのに費やした時間の割合を表示します。 |
% Memory utilization |
アプリケーション プール |
アプリケーション プールのシステム メモリの平均使用率を表示します。監視対象のアプリケーション プールを特定する必要があります。 ピーク時のメモリ使用率を特定し、その数値に 10% 加えた値をアプリケーション プールに割り当てるのが基本です。 |
データベース サーバー
次の表に、パフォーマンス カウンタと、ファーム内のデータベース サーバーにおける監視対象のプロセスを示します。
| パフォーマンス カウンタ | 適用対象のプロセス | メモ |
|---|---|---|
% Processor time |
全体 |
このスレッドがプロセッサを使用して命令を実行するのに費やした経過時間の割合を表示します。 |
% Memory utilization |
全体 |
システム メモリの平均使用率を表示します。 |
このブックをダウンロードする
このトピックは、簡単に読んだり印刷したりできるように、次のダウンロード可能なブックに収められています。
入手できるすべてのブックの一覧については、「Office SharePoint Server 2007 のダウンロード可能なブック」を参照してください。
関連項目
その他のリソース
Additional performance and capacity planning factors [Windows SharePoint Services]