SharePoint Server 2010 の Access Services でのパフォーマンスと容量の要件を見積もる
適用先: SharePoint Server 2010 Enterprise
トピックの最終更新日: 2016-11-30
この記事では、Microsoft SharePoint Server 2010 を実行しているトポロジで Microsoft SharePoint Server 2010 の Access Services を使用する場合に占有する領域についてのガイダンスを示します。
この記事の内容:
テスト ファームの諸特性
テスト結果
推奨事項
トラブルシューティング
テスト ファームの諸特性
ここでは、テスト中に使用したデータセットについて説明します。パフォーマンス収集時に製品に与えたワークロード、テスト中に使用したハードウェア、およびハードウェアの展開方法を示すトポロジを示します。
データセット
Access Services の容量とパフォーマンスは、このサービスでホストされるアプリケーションの構成に大きく左右されます。多くの場合、容量とパフォーマンスに最も大きな影響を与えるのは、テーブルのサイズとクエリの複雑さです。テストでは典型的なサイズと複雑さを使用しましたが、アプリケーションとデータセットはそれぞれ異なります。容量とパフォーマンスは、使用しているアプリケーション、各アプリケーションの複雑さ、およびデータ サイズに左右されます。
容量プロファイルを評価するために、Access Services 専用のファームで (他の SharePoint テストは実行していない状態で) Access Services アプリケーションをシミュレートしました。ファームは、次の典型的なサイトで構成しました。
"小" サイズ プロファイルの 1,500 個の Access Services アプリケーション、1 リストあたり最大 100 項目
"中" サイズ プロファイルの 1,500 個の Access Services アプリケーション、1 リストあたり最大 2,000 項目
"大" サイズ プロファイルの 1,500 個の Access Services アプリケーション、1 リストあたり最大 10,000 項目
各アプリケーションは複数のリストで構成され、その他のリストは、この最大のリストに基づいて適切なサイズに設定されます。Access Services は、10,000 項目を超えるデータを処理できます。ただし、これより大きいアプリケーションは一般的でないと判断し、"大" プロファイルにこの数値を選択しました。
アプリケーションは、次のアプリケーションに均等に配分しました。
連絡先 単純な連作先管理アプリケーションで、1 つのリストで制御します。
プロジェクト 単純なタスクとプロジェクトの追跡アプリケーションで、2 つのリスト (プロジェクトおよび各プロジェクトに関連付けられたタスク) で制御します。
受注 単純な受注管理システムで、Microsoft Access の Northwind Traders サンプルに似ていますが、規模を縮小しています。多数の相互に関連するリスト (受注、受注明細、請求書、請求書明細、発注書、発注書明細など) を含んでいます。
ワークロード
アプリケーションの使用をシミュレートするために、次の操作を 1 つ以上実行するためのワークロードが作成されました。
フォームを開く
フォームのページ間移動
データ シートのフィルター処理と並べ替え
レコードの更新、削除、および挿入
アプリケーションの発行
レポートのレンダリング
各ワークロードには、ユーザーの動作と動作の間の "思考時間" が含まれています。その範囲は 5 ～ 20 秒です。これは、他の SharePoint 容量計画ドキュメントと異なります。Access Services はステートフルです。メモリ カーソルとレコード セットはユーザーの操作と操作の間で維持されるので、単に個々の要求ではなく、完全なユーザー セッションをシミュレートすることが重要でした。1 つのユーザー ワークロードの場合、1 秒あたり平均 2 つの要求を含んでいます。
次の表は、使用するアプリケーションとアプリケーションのサイズを決定するときに使用したパーセンテージを示しています。
| 小 | 中 | 大 | |
|---|---|---|---|
連絡先 |
16% |
10% |
9% |
プロジェクト |
18% |
12% |
10% |
受注 |
11% |
8% |
6% |
グリーン ゾーンとレッド ゾーンの定義
構成ごとに、2 つのテストを実行して、"グリーン ゾーン" と "レッド ゾーン" を特定しました。グリーン ゾーンは、持続できる推奨のスループットです。レッド ゾーンは、短期間であれば許容できるが、回避する必要がある最大スループットです。
グリーン ゾーンは、実行中のテストがボトルネックになっているリソースの最大半分を消費する地点として定義しました。この場合、ボトルネックになっているリソースは、3 層 (フロントエンド Web サーバー、アプリケーション サーバー (Access Data Services)、データベース サーバー (SQL Server)) のいずれかの %CPU でした。最初に、ボトルネックは特定の構成で確認されました。ボトルネックが Access Data Services の CPU の場合、グリーン ゾーンのテストで、Access Data Services コンピューターの 40 ～ 50% の CPU を消費していることを確認しました。
レッド ゾーンの場合、最大スループットに到達した地点を選択しました。これは、80 ～ 90% の範囲の CPU 使用率であることがわかりました。ボトルネックを探すときに、ボトルネックとなる可能性がある %CPU、メモリ使用量 (プライベート バイト)、ディスク キューの長さ、ネットワーク I/O、およびその他のリソースを観察しました。
グリーン ゾーンとレッド ゾーンのテストは、両方とも固定のユーザー ロードで 1 時間実行しました。
結果の相違の可能性
この記事で示す特定の処理能力とパフォーマンスの数値は、現実の環境における数値とは異なります。このシミュレーションは、実際のユーザーが行う可能性がある操作を推測したものにすぎません。ここで示す数値は、ある一定規模の環境を設計する際の出発点を提供することを目的としています。最初のシステム設計が終了したら、実際の環境におけるさまざまな要素にシステムが対応できるかどうかを判断するために構成をテストする必要があります。
ハードウェアの設定とトポロジ
ラボのハードウェア
テスト結果の詳細を高いレベルで提供できるように、テストでは複数のファーム構成を使用しました。具体的には、1 ～ 4 台のフロントエンド Web サーバー、1 ～ 4 台のアプリケーション サーバー (Access Services または Access Data Services がある場合)、および Microsoft SQL Server 2008 を実行している 1 台のデータベース サーバー コンピューターでファームを構成しました。また、テストは、4 台のクライアント コンピューターを使用して実行しました。サーバー コンピューターはすべて 64 ビットでした。クライアント コンピューターはすべて 32 ビットでした。
次の表は、テストで使用されたハードウェアを示しています。
| コンピューターのロール | CPU | メモリ | ネットワーク | ディスク |
|---|---|---|---|---|
フロントエンド Web サーバー |
2 台のプロセッサ、4 コア 2.33 GHz |
8 GB |
1 ギガ |
2 スピンドル RAID 5 |
アプリケーション サーバー (Access Data Services) |
2 台のプロセッサ、4 コア 2.33 GHz |
8 GB |
1 ギガ |
2 スピンドル RAID 5 |
データベース サーバー (SQL Server) |
4 台のプロセッサ、4 コア 2.6 GHz |
32 GB |
1 ギガ |
論理ユニット番号 (LUN) ごとに Direct Attached Storage (DAS) 接続の RAID 0 |
トポロジ
経験から、Access Data Services を実行しているアプリケーション サーバー層の CPU が、スループットの重要な制限要因であると考えられます。Access Data Services コンピューターをそれがボトルネックでなくなるまで追加してトポロジを変化させ、さらにスループットを向上するために 1 台のフロントエンド Web サーバーを追加しました。
1x1: 1 台のフロントエンド Web サーバー コンピューターに 1 台の Access Data Services コンピューター
1x2: 1 台のフロントエンド Web サーバー コンピューターに 2 台の Access Data Services コンピューター
1x3: 1 台のフロントエンド Web サーバー コンピューターに 3 台の Access Data Services コンピューター
1x4: 1 台のフロントエンド Web サーバー コンピューターに 4 台の Access Data Services コンピューター
2x1: 2 台のフロントエンド Web サーバー コンピューターに 1 台の Access Data Services コンピューター
2x2: 2 台のフロントエンド Web サーバー コンピューターに 2 台の Access Data Services コンピューター
2x4: 2 台のフロントエンド Web サーバー コンピューターに 4 台の Access Data Services コンピューター
SQL Server を実行しているコンピューターは、比較的強固なコンピューターで、ボトルネックになることはありませんでした (ただし、2x4 テストで CPU 飽和状態に近づき始めました)。このため、トポロジではこのコンピューターを変化させませんでした。現実のアプリケーション混合に含まれるクエリによっては、データベース サーバー (SQL Server) 層がボトルネックになる可能性があると予想されます。
Reporting Services は、すべてのテストにおいて接続モードで実行し、アプリケーション サーバー (Access Data Services) 層で実行しました。
テスト結果
以下の表は、Access Services のテスト結果を示しています。テストのグループごとに、特定の変数を変えているので、ファームのパフォーマンスに対する漸進的な影響がわかります。
この記事で報告されているすべてのテストは、思考時間または待ち時間を入れて実行しました。これは、他の部分の SharePoint に関する容量計画の結果と異なります。
Access Services のボトルネックの詳細については、後の「一般的なボトルネックとその原因 (英語)」を参照してください。
全体的なスケール
次の表とグラフでは、フロントエンド Web サーバーと専用の Access Data Services コンピューターをファームに追加したことによる影響をまとめています。このスループット数値は Access Data Services コンピューター専用です。ファーム全体への影響は反映されません。
| トポロジ | ベースライン ソリューションの最大値 (RPS) | 推奨ベースライン (RPS) |
|---|---|---|
1x1 |
25 |
15 |
1x2 |
54 |
29 |
1x3 |
82 |
45 |
1x4 |
88 |
48 |
2x1 |
25 |
15 |
2x2 |
55 |
29 |
2x4 |
116 |
58 |
.gif "最大および推奨の RPS")
推奨結果
次のグラフは、推奨の持続できるスループットの結果を示しています。
.gif "スループットと ADS")
前述のとおり、4 台目の Access Data Services コンピューターを追加すると、ボトルネックはフロントエンド Web サーバーに変わり、2 台目のフロントエンド Web サーバーを追加すると、フロントエンド Web サーバー層でのリソースの制約が解消されます。つまり、これは、1x1、1x2、および 1x3 が妥当な構成であることを示しています。ただし、4 台目の Access Data Services コンピューターを追加するときには、フロントエンド Web サーバーも追加する必要があります。比率は直線的 (1x1 から 1x4 までの間が直線) なので、7 台目の Access Data Services コンピューターを追加する場合は、ファームのニーズを満たすために 3 台目のフロントエンド Web サーバーの追加も必然的に伴うと考えられます。
これらの結果は、シミュレートしたワークロードにのみ基づいています。このため、実際の展開を監視して、Access Data Services コンピューターの追加をサポートするためにフロントエンド Web サーバーの追加が必要な地点を見つける必要があります。また、このテストのフロントエンド Web サーバーは Access Services 専用ですが、実際には、多くの場合、フロントエンド Web サーバーは、他の SharePoint ワークロードと共有されます。次のグラフは結果を示しています。
.gif "応答時間と ADS")
次のグラフは、このスループット レベルでの応答時間を示しています。応答時間は高速で、1 要求あたり平均 ¼ 秒未満です。
.gif "SQL %CPU と ADS")
これらの結果は、SQL Server コンピューターはボトルネックにならなかったことを示しています。2 台目のフロントエンド Web サーバーの追加により、リソース不足が解消され、SQL Server CPU は常時 50% 未満でした。ただし、SQL Server のインスタンスは他の SharePoint サービスおよび SharePoint 自体と共有されるので、累積的影響によって CPU またはディスク I/O キューの長さがボトルネックとなる地点に到達する可能性があります。
最大
次のグラフは、スループットが押し上げられ、維持できるスループットを超えたときの結果を示しています。
このグラフでは、同様に、4 台目の Access Data Services コンピューターの有効性を最大限に高めるには、2 台目のフロントエンド Web サーバーが必要であることがわかります。ここでも、実際の結果は、アプリケーションとその使用パターンに大きく左右されるので、これとは異なる可能性があります。
.gif "スループットと ADS")
この場合、システム全体に負荷がかかっているので、応答時間は増加します。ただし、それでも約 1 秒で、この数値はほとんどのユーザーの許容範囲です。
Access Data Services コンピューターを 4 台使用しているときに、フロントエンド Web サーバーが 2 台の場合のほうが 1 台の場合よりも応答時間が増加するのは普通ではないように見えますが、これは、2 台のフロントエンド Web サーバーを使用しているときにシステムの全体のスループットが増加するためです。
2 台目のフロントエンド Web サーバーを追加することで比率の線が直線状に戻るので、ここでも SQL Server は制限要因ではありません。ただし、SQL Server のインスタンスで CPU 使用率が約 90% に到達しています。このため、余裕はほとんど残っていません。5 台目の Access Data Services コンピューターを追加した場合、SQL Server コンピューターがボトルネックになる可能性があります。
.gif "SQL %CPU と ADS")
結果の詳細
次の表は、推奨構成時の結果の詳細を示しています。
| 全体 | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
要求数/秒 |
14.96 |
28.76 |
45.22 |
48.01 |
14.85 |
28.77 |
58.02 |
テスト数/秒 |
2.00 |
3.81 |
6.11 |
6.42 |
1.99 |
3.81 |
7.80 |
平均待機時間 |
235.80 |
241.21 |
247.21 |
244.87 |
240.70 |
242.26 |
250.94 |
| 平均フロントエンド Web サーバー層 | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
%CPU |
13.82 |
24.40 |
41.02 |
43.62 |
6.31 |
12.48 |
26.18 |
w3wp プライベート バイトの最大サイズ |
9.46E+08 |
2.31E+08 |
1.49E+09 |
1.55E+09 |
8.43E+08 |
9.84E+08 |
1.19E+09 |
| 平均アプリケーション サーバー (Access Data Services) 層 | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
%CPU |
46.30 |
42.83 |
43.74 |
34.51 |
46.56 |
43.45 |
42.13 |
%CPU w3wp |
33.61 |
31.15 |
30.71 |
24.29 |
33.48 |
31.64 |
29.72 |
%CPU RS |
8.62 |
7.94 |
9.17 |
6.84 |
9.03 |
8.02 |
8.71 |
合計プライベート バイトの最大サイズ |
4.80E+09 |
4.89E+09 |
4.91E+09 |
4.62E+09 |
5.32E+09 |
4.82E+09 |
5.07E+09 |
w3wp プライベート バイトの最大サイズ |
2.10E+09 |
1.97E+09 |
2.04E+09 |
1.86E+09 |
2.00E+09 |
2.00E+09 |
2.07E+09 |
RS プライベート バイトの最大サイズ |
1.78E+09 |
2.00E+09 |
1.97E+09 |
1.86E+09 |
2.30E+09 |
1.89E+09 |
2.02E+09 |
| データベース サーバー (SQL Server) 層 (単一のコンピューター) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
%CPU |
12.07 |
18.64 |
32.53 |
36.05 |
9.89 |
21.42 |
47.46 |
プライベート バイトの平均サイズ |
2.96E+10 |
3.22E+10 |
3.25E+10 |
3.25E+10 |
2.89E+10 |
3.22E+10 |
3.25E+10 |
プライベート バイトの最大サイズ |
3.26E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
ディスク キュー長合計の平均 |
0.74 |
1.18 |
1.64 |
1.77 |
0.67 |
1.24 |
2.18 |
次の表は、最大構成時の結果の詳細を示しています。
| 全体 | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
要求数/秒 |
14.96 |
28.76 |
45.22 |
48.01 |
14.85 |
28.77 |
58.02 |
テスト数/秒 |
2.00 |
3.81 |
6.11 |
6.42 |
1.99 |
3.81 |
7.80 |
平均待機時間 |
235.80 |
241.21 |
247.21 |
244.87 |
240.70 |
242.26 |
250.94 |
| 平均フロントエンド Web サーバー層 | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
%CPU |
13.82 |
24.40 |
41.02 |
43.62 |
6.31 |
12.48 |
26.18 |
w3wp プライベート バイトの最大サイズ |
9.46E+08 |
2.31E+08 |
1.49E+09 |
1.55E+09 |
8.43E+08 |
9.84E+08 |
1.19E+09 |
| 平均アプリケーション サーバー (Access Data Services) 層 | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
%CPU |
46.30 |
42.83 |
43.74 |
34.51 |
46.56 |
43.45 |
42.13 |
%CPU w3wp |
33.61 |
31.15 |
30.71 |
24.29 |
33.48 |
31.64 |
29.72 |
%CPU RS |
8.62 |
7.94 |
9.17 |
6.84 |
9.03 |
8.02 |
8.71 |
合計プライベート バイトの最大サイズ |
4.80E+09 |
4.89E+09 |
4.91E+09 |
4.62E+09 |
5.32E+09 |
4.82E+09 |
5.07E+09 |
w3wp プライベート バイトの最大サイズ |
2.10E+09 |
1.97E+09 |
2.04E+09 |
1.86E+09 |
2.00E+09 |
2.00E+09 |
2.07E+09 |
RS プライベート バイトの最大サイズ |
1.78E+09 |
2.00E+09 |
1.97E+09 |
1.86E+09 |
2.30E+09 |
1.89E+09 |
2.02E+09 |
| データベース サーバー (SQL Server) 層 (単一のコンピューター) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
%CPU |
12.07 |
18.64 |
32.53 |
36.05 |
9.89 |
21.42 |
47.46 |
プライベート バイトの平均サイズ |
2.96E+10 |
3.22E+10 |
3.25E+10 |
3.25E+10 |
2.89E+10 |
3.22E+10 |
3.25E+10 |
プライベート バイトの最大サイズ |
3.26E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
ディスク キュー長合計の平均 |
0.74 |
1.18 |
1.64 |
1.77 |
0.67 |
1.24 |
2.18 |
推奨事項
ここでは、パフォーマンスおよび容量に関する全般的な推奨事項を説明します。
Access Services の容量とパフォーマンスは、このサービスでホストされるアプリケーションの構成に大きく左右されます。多くの場合、最も大きな影響を与えるのは、テーブルのサイズとクエリの複雑さです。テストでは典型的なサイズと複雑さを使用しましたが、アプリケーションとデータセットはそれぞれ異なります。このため、容量とパフォーマンスは、使用しているアプリケーション、各アプリケーションの複雑さ、およびデータ サイズに左右されます。
ハードウェアに関する推奨事項
Access Services では、フロントエンド Web サーバーとアプリケーション サーバーに標準のハードウェアを使用します。特別な要件は必要ありません。CPU 数、速度、およびメモリに関する一般的な SharePoint Server 2010 のガイドラインをアプリケーション サーバー (Access Data Services) 層のコンピューターに適用できます。
スケール アップ トポロジとスケール アウト トポロジ
開始点トポロジの容量を増やし、パフォーマンスを向上させる方法は 2 つあります。1 つは既存のサーバーの容量を増やしてスケール アップする方法で、もう 1 つは追加のサーバーをトポロジに追加してスケール アウトする方法です。このセクションでは、複数のスケール アウト トポロジの一般的なパフォーマンス特性について説明します。
サンプル トポロジでは、次の一般的な方法によって Access Services シナリオのトポロジをスケール アウトします。
ユーザー ロードの増加に備えて、既存の Access Services アプリケーション サーバーの CPU を確認します。追加できる場合は、CPU またはコア、あるいは両方を追加します。必要に応じて Access Services サーバー コンピューターを追加します。この処置は、フロントエンド Web サーバーがボトルネックになった時点で行うことができ、必要に応じてフロントエンド Web サーバーを追加します。
このテストでは、フロントエンド Web サーバー層とアプリケーション サーバー (Access Data Services) 層のメモリはボトルネックではありませんでした。結果セットのサイズによっては、メモリが問題となる可能性があります。ただし、それが標準になるとは予想していません。ここで説明しているように、Access Data Services w3wp プロセスのプライベート バイトを追跡します。
このテストでは、SQL Server はボトルネックではありませんでした。ただし、他の SharePoint Server 2010 サービスから切り離した状態でテストを実行しました。SQL Server の CPU とディスク I/O を監視し、必要に応じてサーバーまたはスピンドルを追加する必要があります。
パフォーマンスに関する Access Services の設定
Access Services のパフォーマンス特性を制御する方法の 1 つとして、実行できるクエリのサイズと複雑さを制限する方法があります。Access Services では、一連の調整設定を構成してクエリを制御できます。以下の各クエリは、SharePoint サーバーの全体管理から設定できます ([アプリケーション構成の管理] セクションで、[サービス アプリケーションの管理]、[Access Services] の順にクリックします)。
一般に、クエリを実行するために SharePoint から取得する必要があるデータの量は、パフォーマンスに大きな影響を与えます。これは、複数の方法で制御できます。最初に、クエリへの入力を制限できます。
クエリ 1 つあたりの最大ソース数
テーブル 1 つあたりの最大レコード数
次に、生成されるクエリのサイズを制限できます。
クエリ 1 つあたりの最大列数
クエリ 1 つあたりの最大行数
外部結合の許可
クエリのサイズ (入出力されるデータのサイズ) に加えて、データに対する処理の複雑さを制御して、アプリケーション サーバー (Access Data Services) 層での CPU ロードを軽減できます。
クエリ 1 つあたりの集計列の最大数
クエリ 1 つあたりの ORDER BY 句の最大数
上記の設定がサーバーで実行できるアプリケーションに影響するのは明らかです。たとえば、クエリの 40 個の出力列を使用してアプリケーションが書き込まれるときに設定がこのレベルを下回っている場合には、そのアプリケーションで実行時エラーが発生します。ユーザーのニーズと許容できるパフォーマンの間でバランスをとる必要があります。これは、ファームで実行されることが予想される Access アプリケーションの種類に大きく左右されます。
さらに制限することもできます。SharePoint Server 2010 は、一連のクエリ操作をネイティブにサポートしています。Access Services では、より広範なアプリケーション シナリオに対応できるようにこのクエリ操作を増強しています。Access Services が SharePoint からのクエリを向上する場合には、大量のデータを SharePoint コンテンツ データベースから取得する必要がある可能性があります。代わりに、SharePoint によってネイティブにサポートできるクエリ操作だけを実行し続けるように Access Services を設定することで、より複雑な操作に必要なデータ フェッチを回避できます。
- リモート化不可能なクエリの許可
最適化
一般的なボトルネックとその原因
パフォーマンスのテスト中、一般的なさまざまなボトルネックがいくつかわかってきました。ボトルネックとは、特定のファーム構成の容量が限界に達している状態です。これによりファームのスループットが停滞または低下します。
後の「トラブルシューティング」の表では、いくつかの一般的なボトルネックを示し、その原因と考えられる解決方法について説明しています。
パフォーマンスの監視
システムをスケール アップまたはスケール アウトするタイミングを判断するには、パフォーマンス カウンターを使用してシステムの正常性を監視します。次の表の情報を使用して、監視するパフォーマンス カウンターと、そのパフォーマンス カウンターが適用されるプロセスを判断します。
フロントエンド Web サーバー
次の表は、ファーム内の Web サーバーを監視するためのパフォーマンス カウンターおよびプロセスを示しています。
| パフォーマンス カウンター | 対象のオブジェクト | メモ |
|---|---|---|
% Processor Time |
Processor(_Total) |
このスレッドが手順を実行するためにプロセッサを使用した経過時間の比率を表します。 |
Private Bytes |
Process(w3wp) |
この値が、w3wp プロセスに対して設定したプライベート バイトの最大サイズに近づかないようにします。近づいた場合は、メモリを使用しているコンポーネントを特定するために追加の調査が必要です。 |
Access Data Services
次の表に、ファーム内のアプリケーション サーバー (この場合は Access Data Services (Access Data Services)) を監視するためのパフォーマンス カウンターおよびプロセスを示します。
| パフォーマンス カウンター | 対象のオブジェクト | メモ |
|---|---|---|
% Processor Time |
Processor(_Total) |
このスレッドが手順を実行するためにプロセッサを使用した経過時間の比率を表します。 |
% Processor Time |
Process(w3wp) |
Access Data Services は独自の w2wp プロセス内で実行されるので、CPU 時間が大きくなったときにどの w2wp プロセスが原因かを簡単に特定できます。 |
Avg. Disk Queue Length |
PhysicalDisk(_Total) |
ログ記録のため、過剰な量のディスク書き込みを監視します。 |
% Processor Time |
Process(ReportingServicesService) |
レポートは、SQL Server Reporting Services によって処理されます。実行されているレポートの数が多すぎる場合、または、レポートが非常に複雑な場合、このプロセスの CPU とプライベート バイトが大きくなります。 |
Private Bytes |
Process(w3wp) |
Access Services は、ユーザーのセッションが期限切れになるまでクエリの結果をメモリにキャッシュします (セッションのタイムアウトは構成できます)。大量のデータが Access Data Services によって処理されている場合、Access Data Services の w3wp によるメモリ消費量が増加します。 |
Private Bytes |
Process(ReportingSrevicesService) |
レポートは、SQL Server Reporting Services によって処理されます。実行されているレポートの数が多すぎる場合、または、レポートが非常に複雑な場合、このプロセスの CPU とプライベート バイトが大きくなります。 |
データベース サーバー
次の表に、ファーム内のデータベース サーバーを監視するためのパフォーマンス カウンターおよびプロセスを示します。
| パフォーマンス カウンター | 対象のオブジェクト | メモ |
|---|---|---|
% Processor Time |
Processor(_Total) |
このスレッドが手順を実行するためにプロセッサを使用した経過時間の比率を表します。 |
% Processor Time |
Process(sqlservr) |
平均値が 80% を上回っている場合はデータベース サーバーのプロセッサ容量が不十分です。 |
Private Bytes |
Process(sqlservr) |
SQL Server によって消費されているメモリの平均量を表します。 |
Avg. Disk Queue Length |
PhysicalDisk(_Total) |
平均ディスク キュー長、つまり、ディスクにコミットされるのを待機しているデータベース要求の数を表します。これは、多くの場合、SQL Server のインスタンスがオーバーロードになっていること、およびディスク スピンドルを追加することによってロードを分散できる可能性があることを示すよい目安となります。 |
トラブルシューティング
次の表で、いくつかの一般的なボトルネックを示し、その原因と、考えられる解決方法について説明します。
| ボトルネック | 原因 | 解決方法 |
|---|---|---|
Access Data Services の CPU |
Access Services が、アプリケーション サーバー層で大量の処理を負っています。1x1、1x2、または 1x3 構成を使用している場合、Access Data Services サーバーの CPU が最初のボトルネックになることが予想されます。 |
既存の Access Data Services コンピューターで CPU またはコア、あるいはその両方の数を増やします。追加できる場合は、Access Data Services コンピューターを追加します。 |
Web サーバー CPU 使用率 |
Web サーバーがユーザー要求でオーバーロードになると、平均 CPU 使用率が 100% 近くになります。これにより、Web サーバーが要求にすぐに応答できなくなり、タイムアウトが発生してクライアント コンピューターにエラー メッセージが表示される場合があります。 |
この問題を解決する方法は 2 つあります。1 つは、Web サーバーをファームに追加してユーザー ロードを分散する方法で、もう 1 つは、より高速なプロセッサを追加して Web サーバーをスケール アップする方法です。 |
データベース サーバーのディスク I/O |
ハード ディスクに対する I/O 要求の数がディスクの I/O 容量を超えると、要求はキューに入れられます。その結果、各要求が完了するまでの時間が増加します。 |
複数の物理ドライブにデータ ファイルを分散すると、並列 I/O が可能になります。ディスク I/O に関する問題の解決に役立つ情報については、ブログ「SharePoint Disk Allocation and Disk I/O (英語)」(https://go.microsoft.com/fwlink/?linkid=129557&clcid=0x411) (英語) を参照してください。 |
Reporting Services CPU 利用率 |
Reporting Services のプロセスが、大量の CPU リソースを使用しています。 |
コンピューターを Reporting Services 専用にし、アプリケーション サーバー (Access Data Services) 層 (接続モード) またはフロントエンド Web サーバー層 (ローカル モード) からロードを取り除きます。 |