Help

 

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

IMSアプリケーションのパフォーマンスを分析するには、CPUを大量に消費しているのがユーザー コードであるかIMSタスク待ちであるかを判断する必要があります。

  • プログラムCPU使用レポートを検証して、.USERが大量のCPUを消費しているかどうか確認します。消費している場合には、ソース コードの検証のヒント（一般的な「アプリケーションのパフォーマンス分析」ページ）を参照してください。IMSメッセージ処理領域については、トランザクションCPU使用レポートを使用して、CPUを大量に使用した関数固有のトランザクションを特定します。

  • .SYSTEMのCPU消費量が多い場合には、展開して詳細を表示します。.IMSのCPU消費量が多い場合には、DL/Iコールを調べます。これらに該当しない場合には、その他のヒント情報（一般的な「アプリケーションのパフォーマンス分析」ページ）を参照してください。

測定セッション データ（MSD）レポートの[測定統計]セクションに全CPU時間または全待ち時間（つまり99%）が示されていない場合、両方の領域でパフォーマンスを改善できる可能性があります。IMSメッセージ処理領域環境では、少しの変化であっても、それが1日のトランザクション実行回数の倍数分になって現れるため、資源消費全体に大きく影響する場合があります。よって、トランザクション数が多い場合には、資源の消費が少ない項目も検証することをお勧めします。

DL/Iコールの検証

DL/I要求別活動レポートで、個々のDL/Iコールに顕著な活動が示されている場合には、アプリケーション コードを検証して、不要なコールを最低限に抑え、コール パターンが適切であることやコールが効率的であることを確認します。

DL/Iデータベース モジュール、DFSDLxxx、IMS DBまたはDCモニター、IMSコール トレースによるCPU使用が高い場合には、CPU実行時間属性レポートを表示してIMSコール パターンを調べます。パターンを調べることで、同じセグメントの読み取りが何回も実行されていたり、セグメントが存在しないにもかかわらず挿入前に検索されていたりするなど、削除可能なコールが見つかる場合があります。

IMSモジュールによるCPU使用のパーセンテージが高くても、それが必ずしも問題だとは限りません。ジョブやトランザクションの主な目的が多くのIMSセグメントを取得することで、それらのセグメントに対しほとんど処理をしない場合には、IMSが大半の作業を行い、CPUの大半を使用します。

IMSタスク待ちの検証

資源要求分布レポートを検証します。

  • IMSタスクの[資源]カラムに「CPU」という値がある場合には、モジュール別待ち時間レポートを検証します。

  • IMSシステム サービス内の待ち率が高い場合には、DL/I要求別活動レポートを検証して、待ちの原因となっているDL/Iコールを特定します。

  • CPU待ち時間属性レポートを検証して、どのDL/I要求がどのIMSシステムを呼び出したのか、またはIMSシステム内で待ちの原因となったのかを調べます。

ユーザーSVCの待ち時間が長いのは一般にIMS SVCです。IMSメッセージ処理領域では、モジュールDFSRRC10（MPP 領域コントローラー）はモジュールDFSRRC00（IMS領域コントローラー）とリンクされています。IMS領域コントローラーは、子タスク（DFSPCC20）の異常終了または終了を待つ親タスクです。親タスクが待機する間、子タスクの中でもっと有益な作業が行われていることがあります。

IMSバッチ環境では、IMSバッチ ディスパッチャーであるモジュールDFSKBDP0も、他の作業が実行されている間の待ち時間が長くなることがあります。DL/I要求別活動レポートを使用して、アプリケーション内のどこで待ちが発生しているかを調べます。

資源要求分布レポートで示されるSTEPLIBの待ち率が高い場合には、モジュール別待ち時間レポートを検証して、BLDL、Load、LinkなどのSVCが使用されているかどうか確認します。それらのCPU使用を減らすには、IMSプリロード、仮想フェッチ、LLA、OEM、モジュール管理ソフトウェア、IMS BLDLリストなどを使用します。また、頻繁にアクセスされるライブラリーをSTEPLIBとその他のファイルDSNリストの連結の最初に配置することで、ロード時間を削減できます。これらの考慮事項はIMSメッセージ処理領域において非常に重要ですが、一部のIMSバッチ ジョブとBMPジョブに該当するものもあります。