SharePoint Diagnostic Studio 2010 (SPDiag 3.0) (SharePoint Server 2010)

  • [アーティクル]

 

適用先: SharePoint Server 2010

トピックの最終更新日: 2011-07-29

Microsoft SharePoint Diagnostic Studio 2010 (SPDiag バージョン 3.0) は、Microsoft SharePoint 2010 製品 のトラブルシューティングを簡略化および標準化し、収集されたデータの統合ビューを提供するために作成されました。SharePoint 2010 Productsの管理者は、SPDiag 3.0 を使用してファームから関連情報を収集し、意味のある方法で結果を表示し、パフォーマンスに関する問題を識別して、収集されたデータとレポートを Microsoft サポート担当者による分析のために共有またはエクスポートできます。

SharePoint 2010 Productsのプラットフォームは非常に複合的であり、さまざまな用途に使用できます。SharePoint 2010 Productsの展開、管理、およびトラブルシューティングでは、セキュリティ、ネットワーク、ASPX のような Web テクノロジ、Microsoft SQL Server など、複数の技術分野にわたる広範な知識が必要になります。

従来、SharePoint 2010 Productsのトラブルシューティングでは、影響を受けたファームのサーバーからさまざまなデータを手動で収集し、そのデータを手動で分析して問題の原因を判断していました。このようなプロセスは複雑で時間がかかり、データ収集そのものがサーバーに大きな負荷をかけることがありました。

SPDiag では、SharePoint のパフォーマンスと容量に関する問題の診断に一般的に使用される広範なデータ ポイントを対象とする一連の構成済みレポートのデータ コレクションとプレゼンテーションに対する単一のインターフェイスが提供されており、トラブルシューティング プロセスが格段に簡単になります。ほとんどの一般的なトラブルシューティング シナリオは SPDiag によって対処されていますが、SharePoint の一部の問題では SPDiag によって収集されない追加データの分析が必要になる場合があります。

この記事の内容

  • SPDiag 3.0 の新機能

  • SPDiag 3.0 をインストールして構成する

  • SPDiag 3.0 を使用する

  • 既知の問題

SPDiag 3.0 の新機能

SharePoint Diagnostic Studio 2010 (SPDiag Version 3.0) には、トラブルシューティングのツールとしての有効性を向上させる重要な更新と新機能がいくつか含まれています。SPDiag 3.0 は新しいバージョンであり、以前のバージョンの SPDiag にあった機能の一部が削除されている場合があります。

SPDiag 3.0 の新機能と変更点の一覧を次に示します。

  • 事前に構成されているレポート   SharePoint ファームからデータを収集して SharePoint の一般的なトラブルシューティング シナリオに役立つビューを表示する一連の構成済みレポートが提供されます。詳細については、後の「構成済みレポートを使用する」を参照してください。

  • スナップショット   ファームのスナップショットを取得して、レポート イメージ、ファームのトポロジ情報、統合ログ サービス (ULS) のログ、および利用状況データベースのデータを集約できます。これにより、SharePoint ファームに関する重要なトラブルシューティング情報を簡単に統合して、他のユーザーと共有したり、比較や傾向分析のために保存したりできます。

  • SharePoint Server との統合の向上   より多くのソースを対象とするようにデータ コレクションが拡張されました。

SPDiag 3.0 をインストールして構成する

SPDiag は、Microsoft SharePoint 2010 Administration Toolkit v2 に収められています。このツールキットをダウンロードするには、「SharePoint 2010 Administration Toolkit (SharePoint Server 2010)」を参照してください。

SPDiag は、ファーム サーバーまたはファームの一部ではないリモート コンピューターにインストールできます。新しいプロジェクトを作成したり、既存のプロジェクトにアクセスしたりするには、ファーム管理権限のあるユーザー アカウントでログインする必要があります。

一部の SPDiag 3.0 診断ジョブを実行するには、ファーム アカウントに、SharePoint 2010 Productsのデータベースが存在する SQL Server で sysadmin または sqladmin ロールが割り当てられている必要があります。

SPDiag 3.0 をインストールするには、SharePoint 2010 Administration Toolkit v2 のコンポーネントのインストール メニューから [SharePoint Diagnostic Studio] を選択します。その後、以下の手順を使用して、SPDiag を使用できるようにクライアント コンピューターと SharePoint Server ファームを構成します。

SPDiag を使用できるようにクライアント コンピューターと SharePoint Server ファームを構成するには

  1. SPDiag をインストールするコンピューターに, .NET Framework 3.5 をインストールします。

  2. 必要に応じて、SharePoint Server 2010 の最新のサービス パックまたは累積的な更新プログラム (CU) をすべてのファーム サーバーにインストールし、最新のパフォーマンス アップグレードがインストールされるようにします。特に、2010 年 8 月の SharePoint Server 2010 CU には、特定の SPDiag レポートのパフォーマンスが大幅に向上する可能性のある利用状況データベースの更新が含まれます。

  3. SPDiag をインストールするコンピューターに、Microsoft Chart Controls for Microsoft .NET Framework 3.5 をインストールします。

  4. リモート クライアント コンピューターに SPDiag をインストールしている場合は、SPDiag の接続先の "ファーム サーバー" で、Windows PowerShell リモート処理機能および RemoteSigned 実行ポリシーを有効にする必要があります。

    重要

    SPDiag をファーム サーバーにインストールする場合であっても、SPDiag の接続先のファーム サーバーで RemoteSigned 実行ポリシーを有効にする必要があります。

    ターゲット サーバーの Windows PowerShell で次のコマンドレットを実行し、プロンプトが表示されたら「Yes」と入力します。

    1. Enable-PSRemoting -force

    2. Enable-WSManCredSSP -role Server -force

    3. Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 1000

    4. Set-ExecutionPolicy RemoteSigned

  5. リモート クライアント コンピューターに SPDiag をインストールしている場合は、"クライアント コンピューター" で Windows PowerShell リモート処理機能を有効にします。クライアント コンピューターの Windows PowerShell で次のコマンドレットを実行し、プロンプトが表示されたら「Yes」と入力します。

    1. Enable-PSRemoting -force

    2. Enable-WSManCredSSP -role Client -DelegateComputer “<ターゲット コンピューター>” -force

      注意

      <target_computer> の値は、接続先の SharePoint Server Web サーバーのホスト名です。

  6. ターゲット ファームで Usage and Health Data Collection が構成されていることを確認します。SPDiag 診断プロバイダーは、利用状況データベースからデータを収集します。利用状況データベースを準備しないで SPDiag を使用すると、"Usage Database is not provisioned. Please provision it first." というエラーが表示されます。

Usage and Health Data Collection の構成方法については、「Usage and Health data collection を構成する (SharePoint Server 2010)」を参照してください。

SPDiag 3.0 を使用する

SPDiag 3.0 は、トラブルシューティングのために SharePoint ファームからデータを収集、抽出、および表示するために使用するツールです。SPDiag は読み取り専用ツールであり、ファームに変更を加えることはできません。SPDiag を使用すると、ファームのトラブルシューティングのために、自分自身で問題を識別したり、サポート担当者が必要とするデータを収集したりするうえで役立ちます。

このセクションでは、プロジェクトの作成とインポート、データの抽出と収集、グラフとレポートの生成、およびファイルへのデータのエクスポートの各方法について理解を深めるための情報を示します。

SPDiag は、ULS ログ、Windows イベント ログ、パフォーマンス カウンター、SharePoint ログ、および SQL データベースからデータを収集して集計し、パフォーマンスおよび容量の特定の特性や傾向が明らかになるように設計されたさまざまな構成済みレポートにそのデータを表示します。

このセクションの内容

  • プロジェクトを使用する

  • SPDiag のユーザー インターフェイス

  • 構成済みレポートを使用する

プロジェクトを使用する

SPDiag プロジェクトは、SharePoint Server、インターネット インフォメーション サービス (IIS)、ULS、およびイベント ログからのデータのコレクションと、ファーム サーバーからのパフォーマンス カウンター ログ データで構成されます。プロジェクトのメタデータは、ローカル コンピューターの .ttfarm ファイルに格納されます。プロジェクトは無期限に保存でき、アーカイブや共有のために複数の方法でプロジェクトのデータをエクスポートできます。

新しいプロジェクトを作成する

SPDiag を使用してファームのトラブルシューティングを始める前に、新しいプロジェクトを作成する必要があります。プロジェクトを作成すると、SPDiag がインストールされているコンピューターに .ttfarm ファイルが作成され、ファームの利用状況データベースに複数のテーブルが作成されます。

新しいプロジェクトを作成する

  1. SPDiag アプリケーション ウィンドウで、[New Project] をクリックします。

  2. [Create Project] ダイアログ ボックスで、接続先のサーバーのホスト名を入力し、[Create Project] をクリックします。

    ヒント

    特定の環境では、ターゲット サーバーの FQDN を使用しないと接続できない場合があります。

  3. [Windows PowerShell Credential Request] ウィンドウで、ターゲットの SharePoint Server ファームにおいてファーム管理者の権限があるユーザー アカウントとパスワードを入力し、[OK] をクリックします。

  4. 新しいプロジェクトが作成され、概要ウィンドウがメイン SPDiag ウィンドウに表示されます。

プロジェクトを開く

プロジェクトを開くには、プロジェクトの .ttfarm ファイルにアクセスできる必要があります。.ttfarm ファイルが SPDiag を実行する別のコンピューターに作成されている場合は、プロジェクトを開くために使用するコンピューターが、前の「SPDiag 3.0 をインストールして構成する」のガイダンスに従って適切に構成されていることを確認します。

また、ファーム管理者の資格情報を持つアカウントにログインするか、またはプロンプトが表示されたらアカウントを入力する必要があります。

プロジェクトを開く

  1. SPDiag アプリケーション ウィンドウで、[Open Project] をクリックします。

  2. [Open] ダイアログ ボックスで、目的の .ttfarm ファイルを参照し、選択して、[Open] をクリックします。

SPDiag のユーザー インターフェイス

SPDiag アプリケーションは、メニュー バー、[Guide] ウィンドウ、[Reports] ウィンドウ、[Report Display] ウィンドウの 4 つの主要セクションに分かれています。ここではそれぞれについて説明します。

メニュー バー

メニュー バーはアプリケーション ウィンドウの最上部に表示されます。

メニュー バー

  • [New Project]   新しい SPDiag プロジェクトを作成します。

  • [Open Project]   .ttfarm ファイルから既存の SPDiag プロジェクトを開きます。

  • [Take Snapshot]   ファームのスナップショットを作成します。すべての開いているレポートの PNG イメージ、ファーム トポロジについての情報を含むテキスト ドキュメント、およびスナップショット プロセスからのログ ファイルで構成されます。使用できるスナップショットには、Light と Full の 2 種類があります。

    • [Light Snapshot]   現在開いているレポートおよびファームのトポロジ情報をエクスポートします。

    • [Full Snapshot]   [Light Snapshot] のすべてのデータに加えて、特定の時点における ULS ログと SharePoint 利用状況データベースのデータが含まれます。[Full Snapshot] を選択した場合、[Start Time] フィールドと [End Time] フィールドを使用して、ULS ログおよび利用状況データベースのデータ収集の範囲を指定できます。

  • [Search]   特定の要求を探していて、相互関係 ID または要求送信元のユーザー アカウントがわかっている場合は、このボタンをクリックして [Search] ダイアログ ボックスを開きます。[Search] ダイアログ ボックスでは、相互関係 ID、ユーザー アカウント、および検索を開始する要求の推定日時を入力できます。

  • [Assign Permission]   特定のユーザー アカウントまたはグループに対する SharePoint ファームのアクセス許可を設定し、SPDiag へのアクセスを有効にできます。

[Guide] ウィンドウ

[Guide] ウィンドウは、アプリケーション ウィンドウの中央左側に表示されます。このウィンドウには各レポートについての情報が表示され、表示されているデータの説明、データを操作および抽出する方法についての指示、使用可能なレポートに固有のトラブルシューティング ガイダンスなどが含まれます。一部のレポートでは、問題を識別する方法についてのガイダンス、およびその問題を解決するための提案が示されています。

[Reports] ウィンドウ

[Reports] ウィンドウは、アプリケーション ウィンドウの左下隅表示されます。

[レポート] ウィンドウ

[Reports] ウィンドウは展開できるメニューであり、表示できるすべてのレポートが含まれます。各ノードをクリックしてセクションを展開すると含まれるレポートが表示され、レポートをダブルクリックすると [Report Display] ウィンドウにレポートが表示されます。

レポート ツール バーの [Save] ボタンを使用してレポートを保存すると、[Reports] ウィンドウの下部の [Customs] ノードにレポートが表示されます。

使用できるレポートの詳細および一覧については、後の「構成済みレポートを使用する」を参照してください。

[Report Display] ウィンドウ

[Report Display] ウィンドウは、アプリケーション ウィンドウの中心となる部分を構成します。プロジェクトを作成するか開くと、概要レポートが表示されます。

[レポート表示] ウィンドウ

概要レポートには、2 つの主要なレポートである [Availability] と [Latency Percentiles] がグラフとして表示されます。

  • [Availability] レポート   HTTP Web サービスの利用可能性がグラフで表示されます。

  • [Latency Percentiles] レポート   最も早くて一般的な要求の表示にかかる時間を示します。

SPDiag の他のグラフと同様に、マウスを使用してグラフ上の領域を選択することにより、特定の時間範囲を拡大できます。概要レポートでこれを行うと、選択したレポートがメイン SPDiag ウィンドウの新しいタブで開き、選択した領域からの結果が表示されます。

[Reports] ウィンドウでダブルクリックしてレポートを開くと、ファーム サーバーから必要なデータが収集されて、メイン ウィンドウの新しいタブに表示されます。この表示は、レポート ツール バー、[Filter] ウィンドウ、[Data Display] ウィンドウという 3 つのコンポーネントで構成されます。

レポート ツール バー

レポート ツール バーは開かれる各レポート タブの最上部に表示されます。

レポート ツールバー

このツール バーには、表示されているレポートのタイム スケールの更新、保存、エクスポート、変更など、レポート データを操作するためのツールがあります。

  • [Refresh]   ファーム サーバーに新しいデータを要求します。

  • [Save]   拡張子が SPR の XML ファイルに現在のレポートを保存します。ファイルは、SPDiag クライアント コンピューターの C:\Users\Administrator\Documents\SharePoint Diagnostic Studio\Custom Reports フォルダーに保存されます。これらのファイルは任意の XML エディターまたはテキスト エディターで開くことができます。

  • [Hour]   データ表示を過去 1 時間の範囲に調整します。このボタンおよび他の 3 つの時間調整ボタンは、範囲の終了時刻を現在時刻に自動的に設定します。

  • [6 Hours]   データ表示を過去 6 時間の範囲に調整します。

  • [12 Hours]   データ表示を過去 12 時間の範囲に調整します。

  • [Day]   データ表示を過去 24 時間の範囲に調整します。

  • [Open Log]   ログ ファイルのデータがレポートに含まれる場合、[Filter] ウィンドウでログを選択してから [Open Log] ボタンをクリックすることで、未加工のログ ファイルの内容を表示できます。

  • [Export]   現在のレポートを、SPDiag クライアント コンピューターの C:\Users\Administrator\Documents\SharePoint Diagnostic Studio\Exported Reports\<日時> フォルダーに PNG イメージとしてエクスポートします。最後のフォルダーの名前は、レポートがエクスポートされた日付と 24 時間制時刻から "年.月.日-時.分.秒" の形式で動的に生成されます。たとえば、2011 年 3 月 31 日の午後 6 時 11 分 22 秒にエクスポートされるレポートは、2011.3.31-18.11.22 という名前のフォルダーに保存されます。

[Filter] ウィンドウ

[Filter] ウィンドウのレポート固有のフィールドを使用すると、レポートのデータおよび日時範囲をフィルター処理して表示できます。フィールドの値を変更してレポート データを更新するには、フィールドをクリックします。

[フィルター] ウィンドウ

[Data Display] ウィンドウ

[Data Display] ウィンドウには、表示されているレポートのグラフ、チャート、表、ログ ファイルのデータが表示されます。

[データ表示] ウィンドウ

一部のレポートでは、ウィンドウの上部の表にオブジェクトの一覧が表示され、下部の独立したウィンドウに表で選択したオブジェクトについての詳細が表示されます。たとえば、[Timer Jobs] レポートでは、[Data Display] ウィンドウの上半分にタイマー ジョブの一覧が表示されます。一覧でタイマー ジョブを選択すると、そのジョブについての詳細な ULS トレース ログ情報がウィンドウの下半分に表示されます。

[デュアル表示] ウィンドウ

また、QuickFilter 機能を使用すると、フィールドを右クリックして、レポートをその値でフィルター処理できます。レポートを更新するには、フィールドを右クリックし、[QuickFilter] メニューから機能を選択します。

[クイック フィルター] メニュー

  • =   厳密な値でフィルターします。

  • <>   選択した範囲内のすべての値でフィルターします。

  • >   選択した値より大きいすべての値でフィルターします。

  • <   選択した値より小さいすべての値でフィルターします。

レポート内の特定のレコードのデータが問題の存在を示す場合、レコードの先頭に赤い円と感嘆符が表示されます。マウス ポインターを赤い円の上に移動すると、問題についての情報を含むツールヒントが表示されます。

エラーのヒント

レポートにチャートやグラフなどのグラフィック表示要素が含まれる場合は、マウスを使用してグラフの領域を選択することで、特定の時間範囲を拡大できます。元の時間範囲に戻すには、グラフのどこかを右クリックします。

注意

データの収集には時間がかかる場合があります。特に、SPDiag クライアント コンピューターとファーム サーバーの間のネットワーク待機時間が長い場合や、ファームに大きい負荷がかかっているときなどです。データの収集とレポートの表示が開始した後ではプロセスを取り消す方法はなく、このプロセスが完了するまで SPDiag は応答しません。

構成済みレポートを使用する

SPDiag には、ログ、SharePoint データベース、およびパフォーマンス カウンターからのデータを表示するさまざまなレポートが用意されています。レポートでは、SharePoint ファームからデータが収集されて、ファームのパフォーマンスの特定の部分に焦点を当てて集計された情報が表示されます。

また、ガイド ウィンドウの下部に表示される [Reports] ウィンドウからレポートを直接開いて、調査を開始することもできます。これらのレポートについては後で説明します。

基本レポート グループ

基本レポート グループには、重要な一般的パフォーマンス指標についての情報を表示する複数のレポートが含まれます。

HTTP レポート

このレポートには、ファーム全体のすべての HTTP 要求が表示されます。上部のレポートで行を選択すると、要求からの完全なトレースがフェッチされて、下部のウィンドウに表示されます。

任意のセルを右クリックし、選択した列名と値でフィルターを追加します。または、レポートの上部にあるフィルター一覧を使用して、結果をフィルター処理することもできます。LIKE 演算子を使用する場合、"%" はワイルドカード文字として扱われます。

任意の列見出しをクリックして、その列で表示を並べ替えることができます。たとえば、最も遅い要求を見つけるには、[Duration] 列をクリックします。見出しを再びクリックすると、結果の順序が逆になります。

フィルター リストをカスタマイズした場合は、あらためて生成する必要がないようにレポートを保存できます。保存したレポートは、画面の左下の [Reports] ウィンドウの [Customs] ノードに表示されます。次にレポートを読み込んだときには、保存されている並べ替えとフィルターが復元されて、新しいデータに適用されます。

現在の結果セットを共有したりスプレッドシートで表示したりするために保存するには、[Export] ボタンをクリックします。

Windows イベント

このレポートには、ファーム内のすべてのコンピューターの Windows イベント ログから重要な SharePoint 関連イベントが表示されます。指定した時間枠の間に発生した重要な問題を探すには、このレポートを使用します。

任意のセルを右クリックし、選択した列名と値でフィルターを追加します。または、レポートの上部にあるフィルター一覧を使用して、結果をフィルター処理することもできます。LIKE 演算子を使用する場合、"%" はワイルドカード文字として扱われます。

任意の列見出しをクリックして、その列で表示を並べ替えることができます。

フィルター リストをカスタマイズした場合は、あらためて生成する必要がないようにレポートを保存できます。保存したレポートは、画面の左下の [Reports] ウィンドウの [Customs] ノードに表示されます。次にレポートを読み込んだときには、保存されている並べ替えとフィルターが復元されて、新しいデータに適用されます。

現在の結果セットを共有したりスプレッドシートで表示したりするために保存するには、[Export] ボタンをクリックします。

ULS トレースの問題

このレポートには、Unified Logging Service (ULS) トレース ログで検出された問題が表示されます。問題の時点で発生している上位レベルのトレースは、原因究明の手がかりになることがあります。上部のレポートで行を選択すると、要求またはタイマー ジョブから完全なトレースがフェッチされて、下部のウィンドウに表示されます。

任意のセルを右クリックし、選択した列名と値でフィルターを追加します。または、レポートの上部にあるフィルター一覧を使用して、結果をフィルター処理することもできます。LIKE 句を使用する場合、"%" はワイルドカード文字として扱われます。

任意の列見出しをクリックして、その列で表示を並べ替えることができます。たとえば、最も遅い要求を見つけるには、[Duration] 列をクリックします。見出しを再びクリックすると、結果の順序が逆になります。

フィルター リストをカスタマイズした場合は、あらためて生成する必要がないようにレポートを保存できます。保存したレポートは、画面の左下の [Reports] ウィンドウの [Customs] ノードに表示されます。次にレポートを読み込んだときには、保存されている並べ替えとフィルターが復元されて、新しいデータに適用されます。

現在の結果セットを共有したりスプレッドシートで表示したりするために保存するには、[Export] ボタンをクリックします。

タイマー ジョブ

このレポートには、すべてのタイマー ジョブの実行が表示されます。上部のレポートで行を選択すると、そのタイマー ジョブからの完全なトレースがフェッチされて、下部のウィンドウに表示されます。

任意のセルを右クリックし、選択した列名と値でフィルターを追加します。または、レポートの上部にあるフィルター一覧を使用して、結果をフィルター処理することもできます。LIKE 句を使用する場合、"%" はワイルドカード文字として扱われます。

任意の列見出しをクリックして、その列で表示を並べ替えることができます。たとえば、最も遅いジョブを見つけるには、[Duration] 列をクリックします。見出しを再びクリックすると、結果の順序が逆になります。

フィルター リストをカスタマイズした場合は、あらためて生成する必要がないようにレポートを保存できます。保存したレポートは、画面の左下の [Reports] ウィンドウの [Customs] ノードに表示されます。次にレポートを読み込んだときには、保存されている並べ替えとフィルターが復元されて、新しいデータに適用されます。

現在の結果セットを共有したりスプレッドシートで表示したりするために保存するには、[Export] ボタンをクリックします。

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

このレポートでは、利用状況データベースで収集されたカウンターの重要なパフォーマンス カウンター データが時系列的に表示されます。

カスタム フィルター コントロールを使用して、特定のカテゴリ、カウンター、インスタンス、またはコンピューターでフィルター処理します。対象のカテゴリを選択すると、他の 3 つのフィルター コントロール (カウンター、インスタンス、コンピューター) は関連する結果で動的に設定されます。フィルターの選択を行ったの値、[Refresh] をクリックしてレポートを生成します。チャートの系列の上にポインターを移動すると、値に関連するカテゴリ、カウンター、インスタンス、またはコンピューターがわかります。

Windows PowerShell の Add-SPDiagnosticsPerformanceCounter コマンドレットを使用すると、SharePoint ファーム内のサーバーに他のパフォーマンス カウンターを追加できます。追加した新しいカウンターは、SharePoint Diagnostic Studio データセットに自動的に組み込まれます。

容量レポート グループ

容量レポート グループには、ファームの容量指標に関する情報を表示する複数のレポートが含まれます。

SQL Server Query IO Over Time

このレポートでは、負荷のかかるストアド プロシージャ入出力 (I/O) が時系列に表示されます。

上部のグラフには、SQL 動的管理ビューに基づいて、時系列的に最も負荷の大きかった上位 5 つのクエリまたはストアド プロシージャが表示されます。

下部の表には、選択した期間の合計 I/O、呼び出しごとの平均 I/O、実行回数、CPU コストなど、負荷のかかるクエリについての詳細な情報が表示されます。

スパイクまたはスパイクのグループと、それが発生した時刻に注目してください。そのようなスパイクは、負荷の大きいストアド プロシージャ呼び出しまたは不適切な実行計画を示している場合があります。

[Execution Count] および [Total IO] の値が高く、同時に [Average IO] 列の値が低いクエリを探します。そのようなクエリは、呼び出されている回数が多すぎる可能性があります。

もっと簡単に読み取ることのできるファイルに実行計画を保存するには、[Export] ボタンをクリックします。

CPU

このレポートでは、一定の期間に各ファーム サーバーの各プロセスによって消費されたプロセッサの使用状況が、合計プロセッサ容量のパーセンテージで表されて示されます。このグラフの作成に使用されるデータは、| Processor | % Processor Time | _Total パフォーマンス カウンターのものです。

注意

パフォーマンス カウンターのデータは、SPDiag プロジェクトが対象のファームに対して開かれていた日時のものだけを使用できます。

Process Memory (MB)

このレポートでは、一定の時間に各ファーム サーバーで使用できた物理メモリが、使用可能なメガバイト (MB) 数で示されます。このグラフの作成に使用されるデータは、| Process | Private Bytes | <プロセス名> パフォーマンス カウンターのものです。

パフォーマンス レポート グループ

パフォーマンス レポート グループには、待機時間と SQL Server に関係のある特定のファーム パフォーマンス指標に関する情報が表示される複数のレポートが含まれます。

SQL Read Intensive Traces

このレポートでは、50,000 ページ (1 ページ = 8 キロバイト) を超える読み取りを行った SQL Server クエリが示されます。

大量のデータを読み取るクエリが実行されると、役に立つデータが強制的にメモリから排除され、他のクエリは負荷の大きい物理読み取りを実行するようになるため、SQL Server の応答が遅くなる可能性があります。その結果、同じ SQL Server に存在するデータをクエリするユーザー操作のエンド ユーザー待機時間が影響を受ける場合があります。

相互関係 ID がクエリ テキストに含まれる場合は、それを使用して、クエリを生成した要求またはタイマー ジョブがわかります。相互関係 ID を HTTP 要求またはタイマー ジョブ レポートのフィルター フィールドにコピーします。

Latency Tier Breakdown

このレポートでは、一定期間のサーバー側 HTTP 要求ページ待機時間の移動平均が示されます。要求の処理にかかった時間が、標準的な HTTP 要求が処理の間に通過する 3 つの階層に分類されます。

  • SQL Server   SQL Server クエリが 250 ミリ秒より長くかかる場合は、SQL 概要レポートを使用して SQL Server のボトルネックを識別します。

  • アプリケーション サーバー   サービス呼び出しが 250 ミリ秒より長くかかる場合は、[HTTP Requests] レポートの [Service Call Duration] 列を使用して、サービス呼び出しによって最も影響を受けている要求を調べます。

  • Web サーバー   SQL Server またはアプリケーション サーバーの階層にボトルネックがなく、要求が Web サーバーで 250 ミリ秒より長くかかっている場合は、[HTTP Requests] レポートの [Duration] 列を使用して、全体として最も遅い要求を調べます。[Latency All Requests] レポートを使用して、問題が単一のコンピューターに分離されるかどうかを調べることができます。最後に、[CPU] レポートを使用して、1 つまたは複数の Web サーバーまたはアプリケーション サーバーが過剰なプロセッサ使用状況を示しているかどうかを調べることができます。

Changed Objects

このレポートでは、変更ログの情報に基づいて、一定の期間に変更されたすべてのオブジェクトの種類が表示されます。変更ログは、コンテンツ データベースで発生した変更の履歴です。前回のクロール以降に発生した変更のみをクエリするための検索クローラーおよび他の機能が提供されます。

データ要素は、"k" 分ごとに 1 回収集されます (k のデフォルト値は 5)。このレポートでは、すべてのコンテンツ データベースで収集されたデータが、積み上げ棒グラフとして表示されます。各棒は、異なる種類のオブジェクトを表します (対応する凡例を参照)。

データベースまたはオブジェクトの種類によって、これらの結果をフィルター処理できます。たとえば、contentdb1 がフィルター ドロップダウンに含まれていれば、contentdb1 という名前のデータベースで行われたオブジェクトの変更だけを表示するようにレポートをカスタマイズできます。同様に、オブジェクトの種類が List である変更のデータだけを表示して、リスト レベルのすべての変更がわかるようにレポートをカスタマイズできます。

このデータは、特定の時間帯に発生している変更の種類の概要を理解するのに役立ちます。このデータからさらに、[HTTP Requests] レポートを使用すると変更の原因になっている要求を特定でき、[Changed Objects Per Database] レポートを使用すると異なるピボットを使用して同じデータを調べることができます。さらに、[Change Types] レポートおよび [Change Types Per Database] レポートを使用すると、オブジェクトに対して行われた変更の種類をさらに詳しく調べることができます。

現在の結果セットを共有のために保存する場合は、[Export] ボタンをクリックします。

Changed Objects Per Database

このレポートでは、変更ログの情報に基づいて、一定の期間に特定のコンテンツ データベースで変更されたすべてのオブジェクトの種類が表示されます。変更ログは、コンテンツ データベースで発生した変更の履歴です。前回のクロール以降に発生した変更のみをクエリするための検索クローラーおよび他の機能が提供されます。

データ要素は、"k" 分ごとに 1 回収集されます (k のデフォルト値は 5)。このレポートでは、すべてのコンテンツ データベースで収集されたデータが、積み上げ棒グラフとして表示されます。各棒は、異なる種類のオブジェクトを表します (対応する凡例を参照)。

データベースまたはオブジェクトの種類によって、これらの結果をフィルター処理できます。たとえば、contentdb1 がフィルター ドロップダウンに含まれていれば、contentdb1 という名前のデータベースで行われたオブジェクトの変更だけを表示するようにレポートをカスタマイズできます。同様に、オブジェクトの種類が List である変更のデータだけを表示して、リスト レベルのすべての変更がわかるようにレポートをカスタマイズできます。

このデータは、特定の時間帯に発生している変更の種類の概要を理解するのに役立ちます。このデータからさらに、[HTTP Requests] レポートを使用すると変更の原因になっている要求を特定でき、[Changed Objects] レポートを使用すると異なるピボットを使用して同じデータを調べることができます。さらに、[Change Types] レポートおよび [Change Types Per Database] レポートを使用すると、オブジェクトに対して行われた変更の種類をさらに詳しく調べることができます。

現在の結果セットを共有のために保存する場合は、[Export] ボタンをクリックします。

Change Types

このレポートでは、変更ログの情報に基づいて、一定の期間に変更されたすべてのオブジェクトの種類が表示されます。変更ログは、コンテンツ データベースで発生した変更の履歴です。前回のクロール以降に発生した変更のみをクエリするための検索クローラーおよび他の機能が提供されます。

データ要素は、"k" 分ごとに 1 回収集されます (k のデフォルト値は 5)。このレポートでは、すべてのコンテンツ データベースで収集されたデータが、積み上げ棒グラフとして表示されます。各棒は、異なる種類のオブジェクトを表します (対応する凡例を参照)。

データベースまたはオブジェクトの種類によって、これらの結果をフィルター処理できます。たとえば、contentdb1 がフィルター ドロップダウンに含まれていれば、contentdb1 という名前のデータベースで行われたオブジェクトの変更だけを表示するようにレポートをカスタマイズできます。同様に、変更の種類が Rename である変更のデータだけを表示して、名前の変更に関するすべての変更がわかるようにレポートをカスタマイズできます。

このデータは、特定の時間帯に発生している変更の種類の概要を理解するのに役立ちます。このデータからさらに、[HTTP Requests] レポートを使用すると変更の原因になっている要求を特定でき、[Change Types Per Database] レポートを使用すると異なるピボットを使用して同じデータを調べることができます。さらに、[Changed Objects] レポートおよび [Changed Objects Per Database] レポートを使用すると、変更されたオブジェクトの種類をさらに詳しく調べることができます。

現在の結果セットを共有のために保存する場合は、[Export] ボタンをクリックします。

Change Types Per Database

このレポートでは、変更ログの情報に基づいて、一定の期間に変更されたすべてのオブジェクトの種類が表示されます。データ要素は、"k" 分ごとに 1 回収集されます (k のデフォルト値は 5)。このレポートでは、すべてのデータベースで収集されたデータが、積み上げ棒グラフとして表示されます。各棒は、異なる種類のオブジェクトを表します (対応する凡例を参照)。

データベースまたは変更の種類によって、これらの結果をフィルター処理できます。たとえば、contentdb1 がフィルター ドロップダウン リスト ボックスに含まれていれば、データベース contentdb1 で行われた変更の種類だけを表示するようにレポートをカスタマイズできます。同様に、変更の種類が Rename である変更のデータだけを表示して、名前の変更に関するすべての変更がわかるようにレポートをカスタマイズできます。

このデータは、特定の時間帯に発生している変更の種類、および各データベースでの変更の量の概要を理解するのに役立ちます。このデータからさらに、[HTTP Requests] レポートを使用すると変更の原因になっている要求を特定でき、[Change Types] レポートを使用すると異なるピボットを使用して同じデータを調べることができます。さらに、[Changed Objects] レポートおよび [Changed Objects Per Database] レポートを使用すると、変更されたオブジェクトの種類をさらに詳しく調べることができます。

現在の結果セットを共有のために保存する場合は、[Export] ボタンをクリックします。

Latency All Requests

このレポートでは、すべての要求 (最大 50,000 件) の継続時間がプロットされます。

このレポートを使用すると、使用状況での異常なパターンを識別できます。たとえば、パフォーマンスが悪く読み込みに一貫して 5 秒かかるサイトでは、5 秒の位置に水平の帯が表示されます。さらに詳細に調べるには、狭い領域を拡大し、[HTTP Requests] レポートに移動して、約 5 秒かかっている要求を探すことができます。

待機時間のスパイクは縦の棒として表示されます。スパイクに一定の間隔がある場合は、[Timer Jobs] レポートを調べて、特定のジョブが同じ時間に実行しているかどうかを確認できます。

Latency Percentiles

このレポートでは、一定の期間について複数の重要なパーセンタイルしきい値が表示され、特定の待機時間スパイクによって影響を受けた要求の数がわかります。

たとえば、すべての要求のうち最も速い 25 パーセントが 1 秒以上かかっている場合、一部の共有リソース (ネットワークや SQL Server コンピューターなど) の停止がすべての要求に影響している可能性があります。共有リソースでの問題を調べるには、[Latency Tier Breakdown] レポートを使用します。

一方、すべての要求の 75 パーセントはすぐに完了しているにもかかわらず、95 番目のパーセンタイルが非常に高い場合は、少数の要求に影響を与えている根本原因を調べることが必要な場合があります。たとえば、特定のデータベースでのブロックや、サイトのサブセットによってのみ使用されるカスタム コードなどの可能性があります。

最も遅い要求のログを確認するには、[HTTP Requests] レポートを表示し、[Duration] 列の見出しをクリックして一覧を並べ替えます。

また、[Requests Per User] レポートや [Application Workload] レポートを使用して、予想外の負荷をネットワークにかけているユーザーやアプリケーションを探すこともできます。

SQL Deadlocks

このレポートでは、一定期間の SQL Server のデッドロックが一覧表示されます。SQL Server はデッドロック検出機能を使用して、2 つの互換性のないクエリが実行されたときにサーバーがハングするのを防ぎます。デッドロックを解決するには、1 つ以上のクエリを取り消します。SharePoint Server はデッドロックから復元して、影響を受けたクエリを再試行できます。ただし、デッドロックによって一部の要求が失敗する場合があります。

SQL Blocking

このレポートでは、他の SQL クエリをブロックしている SQL クエリの一覧が表示されます。

ブロックによってファームのすべてのアクティビティが停止する可能性があります。影響を受けたデータベースがブロックされた要求を処理できない場合、Web サーバーの使用できるすべてのメモリが消費されて、影響を受けたサーバーは応答を停止したりクラッシュしたりします。

このレポートでは、可能な場合は、ブロックしているクエリを生成している要求またはタイマー ジョブと、関連するすべてのログが表示されます。これらは、ブロックが特定のエンド ユーザー トランザクションによって発生している場合に役に立ちます。そのような場合は、リストの再構築、またはカスタム クエリを使用しているアプリケーションの再設計が示される場合があります。

一部のブロックは回避できません。たとえば、夜間のデータベース メンテナンス タスクではデータベースの大きい部分をロックすることが避けられない場合があります。

利用可能性レポート グループ

利用可能性レポート グループには、ファームの利用可能性の傾向と問題についての情報を表示する複数のレポートが含まれます。

[Availability] レポート

このレポートでは、HTTP Web サービスの利用可能性のチャートが表示されます。利用可能性が低下している部分は、ユーザーが SharePoint サイトにアクセスできなかった可能性のある期間を示します。

このレポートでは、成功した Web 要求の数を、そのサーバーに送信された要求の総数で除算することによって、利用可能性を計算しています。検索クローラーのような自動エージェントからの要求はこの計算から除外されるようになっています。ただし、一部の不明な自動エージェントは除外されない場合があります。

マウスを使用して選択することで、利用可能性の低い期間を拡大します。狭い時間範囲を選択した場合、この調査でこの後に使用されるレポートが速く読み込まれるようになります。

時間範囲を絞り込んだ後、[Failed User Requests] レポートを使用して、選択した期間に失敗した要求についての詳細を調べることができます。

クラッシュが発生すると、プロセスが終了して要求は完了できないため、利用可能性が低下します。クラッシュの間はプロセスはログに書き込むことができないので、クラッシュ時に実行していた要求はこれらのレポートには表示されず、利用可能性に対する影響はグラフに表示されません。そうではあっても、常にクラッシュを調査する必要があります。

スケジュールされたワーカー プロセス リサイクルによって利用可能性が低下することはほとんどありません。サーバーは、あるプロセスからの要求を正常に完了させながら、同時に別のプロセスを開始して新しい要求を処理しようとします。トラフィックが平均より高い間にスケジュールされていないリサイクルが頻繁に発生すると、複数プロセスの同時実行に対する需要の増加にサーバーが応えられない場合、一部の要求が失敗する可能性があります。

[SQL Overview] レポート

このレポートでは、ファーム内の SQL Server コンピューターの全体的な正常性の把握に役立つ情報が表示されます。このレポートで注目されるのは次の 3 つの領域です。

[SQL Server Locking/Blocking]

SQL Server クエリのブロックにより一部の SQL Server クエリの継続時間の値が長くなり、利用可能性の問題や待機時間の増加の原因になる可能性があります。

  • [Average Lock Wait Time]   ロックは、トランザクションの間に読み取られたり変更されたりした行などの SQL Server リソースに対して保持され、別のトランザクションによるリソースの同時使用を防ぐために使用されます。たとえば、更新では XLOCK が保持され、共有読み取りロックをブロックします。ロック待機時間の値が高い場合、SQL Server 層にブロックの問題があるので、読み取りをブロックする遅い更新スレッドに注意を払う必要があります。

  • [Average Latch Wait Time]   ラッチは、主にデータベース ページを同期するために使用されます。各ラッチは、1 つの割り当て単位と関連付けられます。ラッチが別のスレッドによって競合するモードで保持されているために、ラッチ要求をすぐに許可できない場合、ラッチ待機が発生します。ロックとは異なり、ラッチは、書き込み操作であっても、操作の後ですぐに解放されます。ラッチ待機の値が高い場合は、特定のページをメモリに読み込むのに時間がかかりすぎている可能性があります。

ロック待機時間の値が高い場合は、[SQL Blocking] レポートを調べて、ロックを保持しているクエリを識別します。

[SQL Deadlocks] レポートを調べると、失敗した要求を生成した可能性のあるクエリがわかります。

[SQL Server Disk IO]

SQL Server でよく発生するパフォーマンスの問題は I/O ボトルネックです。SQL Server に受け取ったクエリを処理するのに十分な I/O 帯域幅がない場合、すべてのクエリのパフォーマンス低下し、さらにすべてのファーム Web サーバーのパフォーマンスが低下します。

  • [Average Disk Queue Length]   この測定基準はディスク I/O 全体に対するものです。この値が高くなると全体的な I/O 圧力が増加していることを意味し、10 を超えると、I/O ボトルネックが存在する可能性があります。

  • [Average Logical Reads / s]   この測定基準は読み取りディスク I/O に関するものです。この値が高くなると、読み取り I/O 圧力が増加しています。

  • [Average Logical Writes / s]   この測定基準は書き込みディスク I/O に関するものです。この値が高くなると、書き込み I/O 圧力が増加しています。

I/O ボトルネックがあるときは、[SQL Read-Intensive Traces] レポートを使用して、最もリソースを消費している特定のクエリを調べます。

[SQL Server CPU]

SQL Server コンピューターのプロセッサの使用量が非常に高い場合、SQL クエリはキューに入れられ、Web サーバーのパフォーマンスは低下します。プロセッサと I/O パフォーマンスの間には関係があります。したがって、SQL Server のプロセッサ使用量が高い場合、通常は I/O も高くなります。平均プロセッサ使用量が 80 パーセントになると、ボトルネックとみなされます。

CPU ボトルネックがあるときは、[SQL Read-Intensive Traces] レポートを使用し、[CPU] 列をクリックして、クエリを負荷の大きい順に並べ替えます。

[Worker Process Recycles]

通常、リサイクルは利用可能性に影響を与えません。インターネット インフォメーション サービス (IIS) 7.0 は新しいプロセスを作成し、それを使用して既存の要求を完了させた後、リサイクルされたプロセスを正常にシャットダウンします。 ただし、プロセスが初期化されている間、新しいプロセスの最初の参照は待たされる場合があります。

既定では、SharePoint Server はワーカー プロセス リサイクル ジョブが夜間に実行されるようにスケジュールします。勤務時間中にリサイクルを頻繁に行うと、エンド ユーザー要求の待機時間が長くなる場合があります。Web.config の設定が変更されていないかどうか、またはリサイクルの設定が IIS で変更されていないかどうかを確認してください。

[Failed User Requests]

これらのユーザー要求は、失敗したか、または遅いためにユーザーが失敗したと考える可能性があります。

失敗した要求を選択すると、トレース ログがフェッチされます。システムの何らかのコンポーネントでの失敗を示しているトレースを探します。原因がわからない場合は、[Windows Events] レポートを使用してサーバーまたは IIS でのシステム障害の兆候を調べます。

遅すぎるために要求が失敗した場合は、ログのギャップを探します。強調表示されている場合があります。ギャップの前の行において SQL Server で遅延が発生したことが示されている場合は、その要求が最も可能性の高いロックの原因です。問題の根本原因であるブロックしているクエリを探すには、[SQL Blocking] レポートを使用します。

大きいファイルのダウンロードなどの一部の要求は、遅いことが予想されます。

[Crashes]

このレポートでは、指定した時間範囲内に発生したすべての IIS ワーカー プロセスのクラッシュが表示されます。上部のレポートで行を選択すると、クラッシュしたプロセスからの最後の数秒間のトレースが下部のウィンドウに表示されます。このトレースでクラッシュの原因が示されている可能性があります。

クラッシュは利用可能性に大きく影響する可能性があります。クラッシュの時点で実行されている要求は記録されないので、利用可能性レポートではクラッシュの影響が過小評価される場合があります。クラッシュは、利用可能性に顕著な影響を与えない場合であっても、データ損失や他の問題を引き起こす可能性があるので、調査する必要があります。

使用状況レポート グループ

使用状況レポート グループには、ファームの使用状況の傾向と問題についての情報を表示する複数のレポートが含まれます。

[Requests Per URL]

このレポートには、最も頻繁に要求される URL が表示されます。このレポートを使用すると、頻繁にアクセスされるため、最適化の候補として優先度の高いページを識別できます。

[Requests Per User]

このレポートには、最も一般的なユーザー アカウントによって行われた要求の割合が表示されます。検索クローラー サービス アカウントなどの一部のシステム アカウントは、多くの要求を生成することが予想されます。特定の時点においては、個別のユーザーもリソース使用状況に予想外のピークを発生させる操作を実行する場合があります。

[Application Workload]

このレポートには、一定の期間にさまざまなクライアント アプリケーションからの要求の処理にかかった時間が表示されます。このレポートを見ると、クライアント要求によって使用されているリソースを推定できます。このレポートでは次の考慮事項が示されます。

  • 合計の継続時間が大きい場合、Web サーバーのメモリを追加する必要があります。

  • SQL Server プロセスの継続時間が大きい場合、SQL I/O またはプロセッサの使用量が高いこと、またはクライアント アプリケーションからの要求が他のクエリによってブロックされている可能性があることを示します。

  • Web サーバーの継続時間が大きい場合、ファーム Web サーバーでの高いプロセッサ使用量を示す場合があります。

[Requests Per Site]

このレポートには、ファーム内の各サイトに対して行われた要求の割合が表示されます。

既知の問題

ここでは、SPDiag 3.0 の既知の問題と、回避策がある場合はそれについて説明します。

SPDiag を使用するには、PowerShell で RemoteSigned 実行ポリシーを有効にする必要がある

SPDiag の接続先として構成されているファーム サーバーの PowerShell で RemoteSigned 実行ポリシーを有効にしないと、SPDiag の [New Project] ウィンドウでサーバー名を入力しようとすると、次のようなエラー メッセージが発生します。

問題イベント名: CLR20r3

問題の署名 01: spdiag.exe

問題の署名 09: System.ArgumentOutOfRange

この問題を解決するには、接続先のファーム サーバーの Windows PowerShell コマンド プロンプトで次のコマンドを実行します。

Set-ExecutionPolicy RemoteSigned

SQL Server の別名を使用していると、サーバー接続が失敗する

リモート クライアント コンピューターからファームに SPDiag を接続しようとして、SharePoint 2010 Productsファームが SQL Server の別名を使用してデータベース サーバーに接続するように構成されている場合、SPDiag で次のようなエラーが発生します。

The usage database was not found or was inaccessible.  Please make sure the TTFARM file has the right information and you have access to the server.

この問題を解決するには、SPDiag をインストールしたコンピューターに SQL Server クライアント ツールをインストールし、SQL Server の別名を SharePoint 2010 Products ファームで使用されている別名と一致するように構成します。

一部の SPDiag 診断タイマー ジョブで、sysadmin 権限または sqladmin 権限が必要である

SPDiag 3.0 の一部の診断ジョブでは、SharePoint 2010 Productsデータベースが存在する SQL Server インスタンスで、ファーム アカウントに sysadmin ロールまたは sqladmin ロールを割り当てる必要があります。ファーム アカウントにこれらのロールが割り当てられていないと、特定のレポートでデータを収集するために必要な診断ジョブを実行するのに十分な権限がありません。

OS のロケールが EN-US (1033) ではない場合、SPDiag レポートが動作しない

SPDiag をインストールしたコンピューターのオペレーティング システムのロケールが EN-US (1033) ではない場合、レポートのデータ範囲を設定できないため、SPDiag のレポートは動作しません。現時点での唯一の回避策は、クライアント コンピューターのロケールを EN-US に変更することです。

SharePoint 2010 Productsのファーム サーバーで EN-US 以外のロケールを使用している場合は、SPDiag をクライアント コンピューターにインストールすることをお勧めします。

See Also

Concepts

SharePoint 2010 Administration Toolkit (SharePoint Server 2010)