アプリケーションのパフォーマンス分析

ここではiStrobeを使用してパフォーマンス プロファイルを分析する際の、基本的な分析のワークフローについて説明します。

パフォーマンス プロファイルを分析する前に、そのプロファイルがアプリケーションの通常の実行状況とパフォーマンスを正確に表しているかどうかを確認する必要があります。例外的な測定セッションや、エラー マージンの高いプロファイルからの情報に基づいてアプリケーションを変更すると、パフォーマンス向上を目的とした計画を正しく立案できません。

以下の点を考慮しながら、測定セッション データ(MSD)レポートを検証してください。

  • [ジョブ]、[ステップ]、[セッション開始日]、[セッション開始時間]フィールドを参照して、検証中のパフォーマンス プロファイルが正しいものであることを確認します。[サブシステム]フィールドでは、IMSなど、アプリケーションに対して適切なサブシステムが識別されていることを確認します。

  • [実行時のエラー マージン](%)を検証して、レポートが有効であることを確認します。実行時のエラー マージンが2%未満である場合、十分なサンプルが採取され、レポートが有効であることを示しています。2%を超える場合で、関心のある領域のパーセンテージが小さい場合には、より正確なデータを得るため、測定し直してより多くのサンプルを採取することをお勧めします。パーセンテージの高い領域を分析したい場合は、マージンが高いレポートでも有効な場合があります。レポートが有効であるかどうかは、[収集されたサンプルの合計数]フィールドでも検証できます。このフィールドの値が10,000未満の場合は、測定し直して、より多くのサンプルを採取することをお勧めします。

  • [ページ レート/秒]フィールドを検証します。システム プログラマーは、低いページング率(1~10/秒)を維持する必要があります。過剰なページングを避けるためには、アプリケーション プログラマーが不要な分岐ルーチンを回避する必要があります。

CPU時間と待ち時間のどちらにフォーカスするか

パフォーマンス プロファイルを分析する際に、CPU時間と待ち時間のどちらにフォーカスするかは、主にパフォーマンス改善の目的と、待ち時間に対する実行時間の比率によって判断します。通常、パフォーマンス プロファイル内のすべてのレポートを検証する必要はありません。

パフォーマンス プロファイルでCPU実行レポートと待ちレポートのどちらを検証すべきかを判断するには、測定セッション データ(MSD)レポートの中央カラムの上部にあるパーセント時間セクションを調べます。通常は、[実行時間]の値(1つまたは複数のCPUが活動していた時間のパーセンテージ)と[待ち時間]の値から判断します。

  • 待ち時間に焦点をおく場合には、以下の「待ちの分析」を参照してください。待ち時間の活動が顕著でない場合、待ち時間レポートは生成されません。

  • CPU使用に関心がある場合には、以下の「CPU使用の分析」を参照してください。

メモ:資源最多使用レポートでは、資源を最も多く使用しているプログラムとモジュールを簡単に識別できます。このレポートには資源を最も多く消費しているユーザー(プログラムやモジュール)が一覧表示され、その詳細を示すレポートに直接移動できます。

CPU使用の分析

システム オーバーヘッドまたはユーザー コードのどちらがCPUを多く使用しているかを判別するには、プログラムCPU使用を検証します。

  • .SYSTEM(SVCなどのシステム ルーチン、サブシステム ルーチン、ライブラリ ルーチン)がCPUを最も多く使用している場合は、オーバーヘッドを分析します。
  • .SYSTEMを展開(疑似モジュール名の左側のをクリック)し、どのMVSサブシステムおよび疑似モジュールがCPUを大量に消費しているかを調べ、該当するサブシステムのレポートを検証します。言語ルーチンまたはMVSスーパーバイザー コール(SVC)の場合は、CPU使用属性レポートを検証して、これらのルーチンの呼び出し元を識別します。ルーチンを呼び出したコードのプロシージャー名とソース コード行番号を調べるためには、ソース コードにインデックスを付けてからパフォーマンス プロファイルを作成し直します。
  • .USERがCPUを大量に消費している場合には、ソース コードを検証します。

ソース コードの検証

プログラムCPU使用レポートで.USERを展開し、CPUを大量に消費しているMVSやサブシステムを調べます。

  • 言語ルーチンやMVSスーパーバイザー コール(SVC)の実行時間が長い場合には、CPU実行時間属性レポートを検証し、これらのルーチンの呼び出し元を特定します。またプロファイルがインデックス付けされている場合には、呼び出し元のコード行も調べます。

  • 過剰なCPU使用がユーザー コードに起因している場合には、データ タイプ変換や不適切なループ構造によって発生するCPU使用を削減できないかどうか調べます。レポートを詳細レベルにまで展開して、CPU資源を使用している特定のオフセットを識別します。

  • 合計CPUと合計属性CPUに違いがある場合には、そのコード行ではなく、呼び出されたシステム ルーチンを調べます。属性CPUのパーセンテージが大きい場合には、[行番号]または[開始ロケーション]を展開し、そのステートメントの代わりに呼び出されたシステム サービスを調べます。

これらのレポートにプロシージャ名とソース コード行番号を表示するためには、ソース コードにインデックスを付けてからパフォーマンス プロファイルを作成し直します。

待ちの分析

資源要求分布レポートを検証し、待ちの原因を判別します。

  • [タスクまたはDD名]カラムで、待ちの大半がDD名を示している場合は、物理アクセスを検証します。待ちの大半が疑似活動.FILEMGTに起因する場合は、.FILEMGTを検証します。

  • [資源]カラムの値がCPUである場合には、モジュール別待ち時間レポートを表示し、待ちが発生しているモジュールを調べます。待ちの原因を特定するには、CPU待ち時間属性レポートを使用します。サブシステム上の待ちタスクの詳細については、Db2、IMS、またはCICSのパフォーマンス分析を参照してください。

物理アクセスの検証

アプリケーションの物理アクセスは以下の方法で検証します。

  • データセット特性レポートを検証します。EXCPカウント値の高いファイルについて、ブロッキング、バッファー、分割を検証します。

  • 資源要求分布レポートの実行時の活動の分布状況グラフを検証して、複数のファイルが並行して使用されているかどうかを調べます。

  • 入出力装置使用レポートを検証して、ファイルの常駐場所を確認します。レポートを詳細レベルまで展開して、シリンダ アクセスを検証します。

  • VSAM LSRプール統計レポートを検証して、LSRプールがどのように定義、使用されているかを確認します。

.FILEMGTの検証

資源要求分布レポートで、待ちが.FILEMGTに起因している場合は、以下の方法で検証します。

  • モジュール別待ち時間レポートを使用して、MVSスーパーバイザー コール(SVC)によって発生した待ちを検証します。

  • CPU待ち時間属性レポートを使用して、待ちに関連する機能を呼び出したトランザクションまたはモジュール(つまり、プログラム内でファイルをオープン/クローズする場所)を識別します。

  • 資源要求分布レポートの実行時の活動の分布状況グラフを検証して、待ちの発生場所を識別します。

  • 入出力装置使用レポートを検証して、ファイル管理のオーバーヘッドに関連する装置を識別します。

その他のパフォーマンス分析のヒント

測定データの解釈方法に関するその他の情報については、以下を参照してください。

  • 各レポートのオンライン ヘルプ。そこで、ほとんどのレポート ヘルプ パネルの下部にある[分析のヒント]セクションを参照します。

  • サブシステムのオンライン ヘルプ トピック。ヘルプの目次から、アプリケーション パフォーマンスの分析を選択し、Db2、CICS、またはIMSを選びます。