CPU パフォーマンスの低下の調査

新規リリースへのマイグレーション時に CPU パフォーマンスが低下したと考えられる場合は、まず、CPU のパフォーマンスが実際に低下したかどうかを確認し、関連する特定の接続タイプ、プラン、およびパッケージを識別します。

このタスクについて

この作業を行うには、新規リリースへのマイグレーションの前と後の両方で、実稼働環境における有効な比較ポイントを見つける必要があります。 バッチ処理は運用ビジネス・カレンダーに基づいて大きく変動するため、除外するのが最善です。

これにより、前のDb2リリースの期間のパフォーマンス・データを、新しいDb2リリースを対応する期間と比較することができます。 開始点として、統計トレース・データ、アカウンティング・トレース・データ、およびワークロードのインディケーターを組み合わせて使用し、比較が有効であることを確認し、問題の性質を特定することができます。

プロシージャー

マイグレーション時に CPU のパフォーマンスが低下したかどうかを判断するには、次のようにします。

  1. Db2 リリース全体で、同等のSQLプロファイルを持つ数日間の期間を見つけます。
    有効な比較には、SQL 要求の総数が類似しており、また SELECT、INSERT、UPDATE, DELETE などのさまざまなタイプの SQL ステートメントにおける分散が類似している対応する間隔が必要になります。

    SQL プロファイルが大幅に変更されていることが判明した場合、アプリケーション・ワークロードが変更されているため、CPU パフォーマンスの低下に関する有効な比較を行うことはできません。

  2. 以前のリリースの指定期間と新規リリースの対応する期間におけるパフォーマンス・データを比較します。
    統計およびアカウンティング・トレースの組み合わせを使用して、Db2のリリース間で同じパターンが存在することを確認することができます。
    1. 統計トレース・データでは、まず、以下のコンテキストの CPU 時間を比較します。
      • システムサービスアドレス空間(ssnmMSTR 用のタスク制御ブロック(TCB)およびサービスリクエストブロック(SRB)。
      • タスク制御ブロック(TCB)、サービスリクエストブロック(SRB)、およびデータベースサービスアドレス空間(ssnmDBM1 )用の特殊エンジンサービスリクエストブロック。
      • IRLM アドレス・スペースのタスク制御ブロック (TCB) およびサービス要求ブロック (SRB)。
    2. アカウンティング・トレース・データでは、各接続タイプ、中央処理装置および専用エンジンのクラス 2 CPU 時間を比較し、以下のワークロード・インディケーターを含む、SQL 要求の数を確認します。
      • ステートメント・タイプ (SELECT、INSERT、UPDATE、FETCH など) 別の、データ操作用 SQL ステートメントの数。
      • コミット操作、ロールバック操作、ページ取得操作、およびバッファー・プール更新の数。
      • 入出力操作とページに関する読み取りおよび書き込みアクティビティーの量。
    3. 統計トレース・データとアカウンティング・トレース・データを以下のようにして結合させます。
      1. CPU 時間の値をコミットおよびロールバック操作の数で除算して、値を正規化します。 結果の値は、平均トランザクション当たりのCPUミリ秒を表します。
      2. CPU リソース使用量のさまざまなコンポーネントをスタックし、それらをグラフにします。
      以下に例を示します。
      MSTR TCB cpu-time / (commits + rollbacks)
      MSTR SRB cpu-time / (commits + rollbacks)
      DBM1 TCB cpu-time / (commits + rollbacks)
      DBM1 SRB cpu-time / (commits + rollbacks)
      DBM1 IIP SRB cpu-time / (commits + rollbacks)
      IRLM TCB cpu-time / (commits + rollbacks)
      IRLM SRB cpu-time / (commits + rollbacks)
      Average Class 2 CP CPU * occurrences / (commits + rollbacks)
      Average Class 2 SE CPU * occurrences / (commits + rollbacks)
  3. 対応する間隔のページ取得操作の数を比較します。
    リリース間でページ取得操作数が大幅に変更されていることが判明した場合 (比較可能なアプリケーション・ワークロードで)、アクセス・パスの変更が CPU パフォーマンスの低下の最も考えられる原因となります。

次の作業

アカウンティング・データの詳細を分析することで、問題の原因である特定のプランまたはパッケージを見つけることができます。