SharePoint Server 2010 の監視と保守

 

適用先: SharePoint Server 2010

トピックの最終更新日: 2015-03-09

この記事では、Microsoft SharePoint Server 2010 ファームの監視とパフォーマンス カウンターについて説明します。SharePoint Server 2010 のシステム パフォーマンスを維持するには、サーバーを監視して潜在的なボトルネックを特定する必要があります。監視を効果的に行うには、ファームの特定の部分に注意が必要な場合にそれを伝える重要な指標、およびその指標を解釈するためのノウハウを理解しておく必要があります。定義した目標の範囲外でファームが運用されていることを確認した場合、ハードウェア リソースの追加や削除、トポロジの変更、またはデータの格納方法の変更を行ってファームを調整できます。

この記事の情報は、管理者がパフォーマンス カウンターとその他の設定を手動で構成する際に役立つことを目的とします。SharePoint サーバーの全体管理インターフェイスに組み込まれた正常性監視ツールを使用して、正常性監視とトラブル シューティングを行う方法については、以下の記事を参照してください。

この記事を読む前に、「SharePoint Server 2010 での容量管理と規模設定の概要」を読む必要があります。

この記事の内容

  • 監視の構成

  • ボトルネックの解消

監視の構成

以下の表に示された設定を変更して、初期の段階の環境を監視できます。これにより、必要な変更があるかどうかを確認できます。監視機能を増強すると、使用状況データベースで必要とされるディスク領域の量が影響を受けます。環境が安定し、この詳細監視の必要がなくなった場合、設定を既定に戻すことをお勧めします。

設定 メモ

イベント ログのオーバーフロー防止

無効

既定値は、[有効] です。この設定を無効にすると、可能な限り多くの監視データを収集できます。通常の運用では、この設定は有効にしておく必要があります。

タイマー ジョブ スケジュール

   

Microsoft SharePoint Foundation 利用状況データのインポート

5 分

既定値は、30 分です。この設定を低くすると、利用状況データベースにデータをインポートする頻度が増加するため、トラブルシューティング時に特に役立ちます。通常の運用では、この設定は 30 分にしておく必要があります。

診断プロバイダー

   

すべての診断プロバイダーを有効にする

有効

"検索の正常性追跡 - トレース イベント" プロバイダーを除いて、既定値は、[無効] です。このプロバイダーでは、さまざまな機能とコンポーネントの正常性データが収集されます。通常の運用では、既定に戻すことをお勧めします。

"job-diagnostics-performance-counter-wfe-provider" と "job-diagnostics-performance-counter-sql-provider" のスケジュール間隔を設定する

1 分

既定値は、5 分です。この設定を低くすると、データのポーリング頻度を増加できるため、トラブルシューティング時に特に役立ちます。通常の運用では、この設定は 5 分にしておく必要があります。

その他

   

コンテンツ要求のスタック トレースを有効にする

有効

既定値は、[無効] です。この設定を有効にすると、プロセスのスタック トレースを使用して、コンテンツ要求エラーを診断できます。通常の運用では、この設定を無効にしておく必要があります。

開発者ダッシュボードを有効にする

有効

既定値は、[無効] です。この設定を有効にすると、開発者ダッシュボードを使用して、表示の遅いページまたはその他の問題を診断できます。通常の運用時、およびトラブルシューティングの必要がなくなった場合は、この設定を無効にする必要があります。

利用状況データの収集

   

コンテンツ インポートの利用状況

コンテンツ エクスポートの利用状況

ページの要求

機能の利用状況

検索クエリの利用状況

サイト インベントリの利用状況

タイマー ジョブ

利用状況の評価

有効

この一連のカウンターのログ記録を有効にすると、環境全体からより多くの利用状況データを収集でき、環境内のトラフィック パターンをより深く理解できます。

パフォーマンス カウンター

利用状況データベースを使用する場合、ファームのパフォーマンスの監視と評価に役立つパフォーマンス カウンターを利用状況データベースに追加できます。パフォーマンス カウンターは特定の間隔 (既定では 30 分) で自動的にログ記録されます。これにより、利用状況データベースへのクエリを実行し、これらのカウンターを取得して、結果を経時的にグラフ表示できます。次のコードは、"% Processor Time" カウンターを利用状況データベースに追加する Add-SPDiagnosticsPerformanceCounter PowerShell コマンドレットの使用例です。このコマンドレットは、Web サーバーの 1 つで実行するだけで済みます。

Add-SPDiagnosticsPerformanceCounter -Category "Processor" -Counter "% Processor Time" -Instance "_Total" -WebFrontEnd

あらゆるサーバー ファームで監視する必要のあるいくつかの汎用的なパフォーマンス カウンターがあります。これらのパフォーマンス カウンターの概要を以下の表で説明します。

パフォーマンス カウンター 説明

プロセッサ

プロセッサのパフォーマンスを監視して、すべてのプロセッサの使用状況が一貫して高い状態 (80% 以上) になっていないことを確認する必要があります。この状態では、システムは活動の突然の急増を処理できません。また、通常の状態では、1 つのコンポーネントのエラーによって残りのコンポーネントが機能しなくなるドミノ効果が起きることはありません。たとえば、3 つの Web サーバーがある場合、サーバー全体の平均 CPU 使用率が 60% 未満であることを確認する必要があります。この場合、1 つのサーバーにエラーが発生しても、他の 2 つのサーバーで追加の負荷を受け入れる余裕があります。

ネットワーク インターフェイス

ネットワーク インターフェイス カード経由でデータが送受信される速度を監視します。これは、ネットワーク容量の 50% 未満を維持する必要があります。

ディスクとキャッシュ

定期的に監視する必要のある多くの論理ディスク オプションがあります。空きディスク容量は、すべての容量調査で不可欠の項目です。ただし、ディスクがアイドル状態になっている時間も確認する必要があります。サーバーで実行するアプリケーションまたはサービスの種類によっては、ディスクの読み取りと書き込みの回数を確認する場合があります。書き込みまたは読み取り機能用のキューを拡張すると、パフォーマンスに影響します。キャッシュは、読み取りおよび書き込み操作に大きな影響を与えます。キャッシュ エラーが増加してないかどうかを監視する必要があります。

メモリとページング ファイル

割り当て可能な物理メモリの量を監視します。メモリが十分でない場合、ページ ファイルが過度に使用され、1 秒あたりのページ フォールト数が増加します。

システム カウンター

利用状況データベース内で監視する一連のカウンターに追加できるシステム オブジェクトとカウンターに関する情報を以下の表に示します。これらのカウンターは、Web サーバーで SPDiagnosticPerformanceCounter を使用して監視します。

オブジェクトとカウンター 説明

プロセッサ

 

% Processor Time

これは、一定の期間におけるプロセッサの使用状況を表します。この値が一貫して非常に高い場合、パフォーマンスに悪影響が生じている場合があります。マルチプロセッサ システムの "合計" をカウントすることに注意する必要があります。各プロセッサの使用率を測定して、コア間でパフォーマンスのバランスがとれていることを確認することもできます。

ディスク

 

- Avg. Disk Queue Length

これは、サンプル期間中に、選択したディスクで待ち状態となっていた読み取りおよび書き込み要求の平均個数を表します。ディスク キューの長さが大きくても、ディスクの読み取り/書き込みが正常に行われ、キューが拡大されることなくシステムが安定した状態で機能する限り、問題は発生しない場合があります。

Avg. Disk Read Queue Length

キューに入れられた読み取り要求の平均個数。

Avg. Disk Write Queue Length

キューに入れられた書き込み要求の平均個数。

Disk Reads/sec

1 秒あたりのディスクの読み取り回数。

Disk Writes/sec

1 秒あたりのディスクの書き込み回数。

メモリ

 

- Available Mbytes

これは、割り当て可能な物理メモリの量を表します。メモリが十分でない場合、ページ ファイルが過度に使用され、1 秒あたりのページ フォールト数が増加します。

- Cache Faults/sec

このカウンターは、ファイル システム キャッシュでページがシークされ、そのページが検出されない場合にフォールトが発生する割合を表します。ページがメモリ内で見つかった場合はソフト フォールトになり、ページがディスク上で見つかった場合はハード フォルトになる場合があります。

読み取り操作と書き込み操作用のキャッシュを効果的に使用することで、サーバーのパフォーマンスに大きく影響する可能性があります。キャッシュのエラーが増加してないかどうかを監視する必要があります。このエラーの増加は、[Async Fast Reads/sec] または [Read Aheads/sec] が減少することで示されます。

- Pages/sec

このカウンターは、ハード ページ フォールトを解決するためのディスク ページの読み書きの速度を表します。値が高い場合、システム規模のパフォーマンスに問題があります。

ページング ファイル

 

- % Used および % Used Peak

サーバーのページング ファイル (スワップ ファイルとも呼ばれる) は、ディスク上の "仮想" メモリ アドレスを保持します。ページ フォールトは、必要な "仮想" リソースがディスクからメモリに取り込まれる間、プロセスが停止して待機する必要がある場合に発生します。物理メモリが不適切な場合、このフォールトの発生頻度は高くなります。

NIC

 

- Total Bytes/sec

これは、ネットワーク インターフェイス カード経由でデータが送受信される速度です。この速度がネットワーク容量の 40 ~ 50% を超える場合、詳細な調査が必要になる場合があります。調査を調整するには、[Bytes received/sec] と [Bytes Sent/sec] を監視します。

プロセス

 

- Working Set

このカウンターは特定プロセスのワーキング セットの現在のサイズ (バイト単位) を表します。このメモリは、使用されていない場合もプロセス用に予約されています。

- % Processor Time

このカウンターは、特定のプロセスで使用されるプロセッサー時間の比率を表します。

Thread Count (_Total)

スレッドの現在の数。

ASP.NET

 

Requests Total

サービスが開始されてからの要求の合計数。

Requests Queued

Microsoft SharePoint Foundation 2010 は、HTTP でユーザーのブラウザーにレンダリングされる HTML ページの構成要素を提供します。このカウンターは処理を待機している要求の数を表します。

Request Wait Time

最新の要求がキュー内で処理を待機した時間 (ミリ秒単位)。待機イベントの数が増加すると、ユーザーへのページの表示が遅くなります。

Requests Rejected

処理するためのサーバー リソースが不足したために実行されなかった要求の合計数。このカウンターは、503 HTTP ステータス コードを返す要求の数を表します。このステータス コードは、サーバーが非常にビジーであることを表します。

Requests Executing (_Total)

現在実行されている要求の数。

Requests/Sec (_Total)

1 秒あたりの実行された要求の数。これは、アプリケーションの現在のスループットを表します。負荷が一定で、他のサーバー作業 (ガーベジ コレクション、キャッシュのクリーンアップ スレッド、外部サーバー ツールなど) がなければ、この数値は特定の範囲内にとどまる必要があります。

.NET CLR メモリ

 

# Gen 0 Collections

アプリケーションが開始されてから、ジェネレーション 0 のオブジェクト (最も最近割り当てられた最も新しいオブジェクト) のガベージ コレクションが実行された回数を表示します。この数値は、#Gen 0 対 #Gen 1 対 #Gen 2 の比率として役立ちます。これにより、Gen 2 の収集数が Gen 0 の収集数を大きく上回ってないことを確認します。最適な数値は 2 の倍数です。

# Gen 1 Collections

アプリケーションが開始されてから、ジェネレーション 1 のオブジェクトのガベージ コレクションが実行された回数を表示します。

# Gen 2 Collections

アプリケーションが開始されてから、ジェネレーション 2 のオブジェクトのガベージ コレクションが実行された回数を表示します。カウンターは、ジェネレーション 2 のガベージ コレクション (フル ガベージ コレクションとも呼ばれる) の終了時に増加します。

% Time in GC

前回のガベージ コレクション サイクル以降のガベージ コレクションの実行にかかった経過時間の割合を表示します。通常、このカウンターは、ガベージ コレクターがアプリケーションに代わってメモリの収集と最適化のための作業を終了したことを表します。このカウンターは、各ガベージ コレクションの終了時にのみ更新されます。このカウンターは平均ではありません。この値は、最後に検出された値を反映します。通常の運用では、このカウンターは 5% 未満になっている必要があります。

SQL Server カウンター

次の表に、SQL Server オブジェクトとカウンターに関する情報を示します。

オブジェクトとカウンター 説明

General Statistics

このオブジェクトは、サーバーの全般的な活動を監視するためのカウンターを提供しています。たとえば、現在の接続数、SQL Server インスタンスを実行しているコンピューターに対する 1 秒間当たりのユーザー接続数/切断数などがあります。

User Connections

このカウンターは、SQL Server インスタンスでのユーザー接続数を表します。この値が基準値の 500 パーセントを超える場合は、パフォーマンスの低下が見られることがあります。

Databases

このオブジェクトは、一括コピー操作、バックアップと復元のスループット、およびトランザクション ログ活動を監視するためのカウンターを提供しています。トランザクションとトランザクション ログを監視することによって、データベース内でのユーザーの活動量とトランザクション ログの消費状況を調べます。ユーザーの活動量は、データベースのパフォーマンスのほか、ログ サイズ、ロック、およびレプリケーションに影響することがあります。ユーザーの活動およびリソースの利用状況の指標となる低レベルのログ活動を監視すると、パフォーマンスのボトルネックを見つけるのに役立つ場合があります。

Transactions/sec

このカウンターは、特定のデータベースまたは SQL Server インスタンス全体における 1 秒間当たりのトランザクション数を表します。この数値は、基準値の作成および問題のトラブルシューティングに役立ちます。

Locks

このオブジェクトは、リソース タイプごとの SQL Server のロックに関する情報を提供します。

Number of Deadlocks/sec

このカウンターは、SQL Server 上の 1 秒間当たりのデッドロック数を表します。通常、この値は 0 である必要があります。

Average Wait Time (ms)

このカウンターは、待ち状態となった各ロック要求の平均待機時間を表します。

Lock Wait Time (ms)

このカウンターは、この 1 秒間に生じたロックの合計待機時間を表します。

Lock Waits/sec

このカウンターは、直ちに解決されないためにリソース待ちとなる 1 秒間当たりのロック数を表します。

Latches

このオブジェクトは、SQL Server 内部のラッチと呼ばれるリソース ロックを監視するためのカウンターを提供しています。ラッチを監視してユーザーの活動およびリソースの利用状況を調べると、パフォーマンスのボトルネックを見つけるのに役立つ場合があります。

Average Latch Wait Time (ms)

このカウンターは、待ち状態となったラッチ要求の平均ラッチ待機時間を表します。

Latch Waits/sec

このカウンターは、直ちに許可できなかった 1 秒間あたりのラッチ要求数を表します。

SQL Statistics

このオブジェクトは、コンパイルや特定の SQL Server インスタンスに対して送信された要求の種類を監視するためのカウンターを提供しています。クエリのコンパイルおよび再コンパイルの回数や特定の SQL Server インスタンスが受け取るバッチの数を監視すると、SQL Server におけるユーザー クエリの処理速度やクエリ オプティマイザーにおけるクエリの処理効率を示す指標を得ることができます。

SQL Compilations/sec

このカウンターは、1 秒間にコンパイル コードのパスが入力された回数を表します。

SQL Re-Compilations/sec

このカウンターは、1 秒間にステートメントの再コンパイルが起動された回数を表します。

Plan Cache

このオブジェクトは、SQL Server がメモリを使用して、ストアド プロシージャ、その場限りの (または事前に準備された) Transact-SQL ステートメント、トリガーなど、オブジェクトをどのように格納しているかを監視するカウンターを提供しています。

Cache Hit Ratio

このカウンターは、プランを検索したときにキャッシュがヒットする比率を表します。

Buffer Cache

このオブジェクトは、SQL Server がメモリを使用してデータ ページ、内部データ構造、プロシージャ キャッシュをどのように格納しているかを監視するカウンターや、SQL Server がデータベース ページを読み書きする際の物理 I/O を監視するカウンターを提供しています。

Buffer Cache Hit Ratio

このカウンターは、バッファー キャッシュ内で見つかったためにディスクから読み取る必要のないページの比率を表します。この比率は、SQL Server インスタンスが開始された以降におけるキャッシュ ヒット総数をキャッシュ検索総数で割ったものです。

ボトルネックの解消

システムのボトルネックは、ユーザーのトランザクション要求を処理するためのリソースが十分でないという論点を提示します。そのリソースには、物理的なハードウェア、運用環境、アプリケーション ベースが考えられます。多くの場合、非効率的なカスタム コードやサードパーティ ソリューションがボトルネックの原因となります。したがって、ハードウェアを追加するよりも、これらをレビューするほうが良好な結果が得られる可能性があります。ボトルネックのもう 1 つの一般的な原因として、ファームの誤った構成または非効率的なソリューションの実装により、必要以上のリソースを要求するデータ構造が構築されていることがあります。システム管理者にとって、パフォーマンスを常に監視してボトルネックを管理することは不可欠です。パフォーマンスの問題を特定した場合、ボトルネックを解消するための最適なソリューションを評価する必要があります。パフォーマンス カウンター、および System Center Operations Manager (SCOM) などのパフォーマンス監視アプリケーションは、問題の追跡と分析を行う上で重要なツールであり、これによりソリューションを開発できます。

物理的なボトルネックの解決

物理的なボトルネックはプロセッサ、ディスク、メモリ、およびネットワーク接続に基づきます。つまり、非常に多くの要求が非常に少ない物理リソースを求めて争っています。「パフォーマンスの監視」のトピックで説明されているオブジェクトとカウンターでは、ハードウェア プロセッサ、ASP.NET など、パフォーマンスの問題がどこに存在するかが示されます。ボトルネックを解決するには、問題を特定して、パフォーマンスの問題を軽減する変更を加える必要があります。

瞬間的に発生する問題はほとんどありません。通常は、パフォーマンスが徐々に低下します。ユーザーは、パフォーマンス監視ツールまたはより高度なシステム (SCOM など) を使用して定期的な監視を行っていると、これを追跡できます。この両方のオプションにおいて、推奨テキストやスクリプト化されたコマンドの形式で、さまざまな程度のソリューションを通知に埋め込むことができます。

ボトルネックの原因が、誤った構成、非効率なカスタム コードまたはサード パーティ ソリューション、または非効率なソリューションの実装でないことが確認された場合、ハードウェアまたはシステムの構成を変更してボトルネックの問題を解決する必要が生じる場合があります。次の表に、問題のしきい値および考えられる解決オプションを示します。一部のオプションでは、ハードウェアのアップグレードまたは変更が推奨されます。

オブジェクトとカウンター 問題 解決オプション

プロセッサ

プロセッサ - % Processor Time

75 ~ 85% を超える

プロセッサをアップグレードします

プロセッサ数を増やします

サーバーを追加します

ディスク

   

Avg. Disk Queue Length

徐々に増加する。システムが安定した状態でなく、キューが飽和状態になっている

ディスクの数を増やすか、ディスクの速度を上げます

アレイ構成をストライプに変更します

一部のデータを代替サーバーに移動します

% Idle Time

90% より大きい

ディスク数を増やします

データを代替のディスクまたはサーバーに移動します

% Free Space

30% 未満

ディスク数を増やします

データを代替のディスクまたはサーバーに移動します

メモリ

   

Available Mbytes

Web サーバーで 2GB 未満。

メモリを追加します。

注意

SQL サーバーの使用可能なメモリは意図的に低くなっていますが、これが必ずしも問題を示すとは限りません。

Cache Faults/sec

1 より大きい

メモリを追加します

可能であれば、キャッシュの速度を上げるか、キャッシュのサイズを増やします

データを代替のディスクまたはサーバーに移動します

Pages/sec

10 より大きい

メモリを追加します

ページング ファイル

   

% Used および % Used Peak

サーバーのページング ファイル (スワップ ファイルとも呼ばれる) は、ディスク上の "仮想" メモリ アドレスを保持します。ページ フォールトは、必要な "仮想" リソースがディスクからメモリに取り込まれる間、プロセスが停止して待機する必要がある場合に発生します。物理メモリが不適切な場合、このフォールトの発生頻度は高くなります。

メモリを追加します

NIC

   

Total Bytes/sec

ネットワーク容量の 40 ~ 50% を超える。これは、ネットワーク インターフェイス カード経由でデータが送受信される速度です。

[Bytes Received/sec] と [Bytes Sent/sec] を監視して、さらに調査します。

ネットワーク インターフェイス カードの速度を再評価します

メモリ バッファーの数、サイズ、使用状況を確認します。

プロセス

   

Working Set

合計メモリの 80% より大きい

メモリを追加します

% Processor Time

75 ~ 85% を超える。

プロセッサ数を増やします

追加のサーバーに負荷を再度分散します

ASP.NET

   

Application Pool Recycles

1 日に数回発生し、これが原因で一時的な遅延が発生する。

終日、不必要に、アプリケーション プールが自動的にリサイクルされるような設定を実装していないことを確認します。

Requests Queued

数百または数千の要求がキューに入れられる。

追加の Web サーバーを実装します。

既定では、このカウンターの最大値は 5,000 です。この設定は Machine.config ファイルで変更できます。

Request Wait Time

待機イベントの数が増加すると、ユーザーへのページの表示が遅くなります。

追加の Web サーバーを実装します。

Requests Rejected

0 より大きい

追加の Web サーバーを実装します。

See Also

Concepts

SharePoint Server 2010 での容量管理と規模設定の概要
SharePoint Server 2010 のパフォーマンス テスト
SharePoint Server 2010 の容量計画
正常性の監視 (SharePoint Server 2010)
ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2010)