db2mon によるパフォーマンス・モニター・データの収集とレポート作成
db2mon は、特定の期間のモニター・データを収集するために Db2 軽量メモリー内モニター・インターフェース を使用する Db2® コマンド行プロセッサー (CLP) スクリプトのセットです。
db2mon.sh シェル・スクリプトは、データの収集と分析のサンプリングを提供します。 このスクリプトは、db2mon の前提条件が満たされているかどうかも検査します。
軽量のインメモリー・モニター・インターフェース とは、「MON_GET_DATABASE」などの、「MON_GET」で始まる名前の組み込みルーチンのことです。 このトピックでは、これ以降、これらのルーチンをまとめて MON_GET 関数と表記し、これらの関数が返すデータを MON_GET データと表記します。
MON_GET 関数が返すデータは、データベースが活動化された時点からの累積データです。 データベースのアクティビティーを判別するには、複数の時点の測定値を収集し、その差分を計算します。 db2mon スクリプトは、ストアード・プロシージャーを使用して情報の収集と計算処理を自動的に行います。
始める前に
db2mon CLP スクリプトを実行するには、データベースへの接続が必要です。 db2mon.sql では、データベースの USER TEMPORARY 表スペースも必要になります。 多くの場合、USER TEMPORARY 表スペースは既にシステムに存在します。 データベース内に USER TEMPORARY 表スペースが存在しない場合は、以下のように CREATE TABLESPACE ステートメントを使用して作成できます。
DB2 CREATE USER TEMPORARY TABLESPACE myTempTbspdb2mon.sql と db2mon_export.sql がモニター・データを正しく収集するには、以下のデータベース構成パラメーターを使用して、データベース・レベルでモニターを有効にする必要があります。
- MON_ACT_METRICS を BASE (デフォルト値) 以上に設定する必要があります。
- MON_REQ_METRICS を BASE 以上に設定する必要があります。 デフォルト値は EXTENDED です。表や索引に関するすべてのモニター情報が得られるので、db2mon を使用するために理想的な設定です。
db2mon をオフライン・モードで実行する場合は、永続的な表と索引を作成する権限が必要です。
このタスクについて
db2mon によるパフォーマンス・モニター・データの収集と分析は、以下の 2 つのモードから選択できます。
- オンライン
- db2mon の実行に最もよく使用されるモードはオンライン・モードです。オンライン・モードでは、db2mon の実行が完了すると、モニター対象システムの標準出力にレポートが生成されます。 このレポートには、メトリックの差分値の計算や出力のリスト生成に使用されたすべての SQL が含まれています。 db2mon.sh は、自動的にデータベースに接続し、USER TEMPORARY 表スペースと小さな専用バッファー・プールを作成し (目的はシステムへの影響を最小化すること)、db2mon.sql を実行してから、切断します。 オンライン・モードは、以下の 2 つの方法で実行できます。
- db2mon.sh を使用する
- 既存の接続を使用する
- オフライン
- エクスポート用、インポート用、レポート生成用に別々の SQL ファイルが用意されています。 パフォーマンス重視のシステムをモニターする場合は、エクスポート・スクリプトを使用してパフォーマンス・データを収集し、別のシステムに転送してインポートとレポート作成を行うことができます。
オフライン・モードで (db2mon_report.sql を実行して) 生成するレポートは、オンライン・モードで (db2mon.sql を実行して) 生成するレポートよりも短くなります。 オフライン・モードのレポートが短くなるのは、宣言済み一時表 (DGTT) の宣言と差分計算がないからです。
以下のファイルが db2mon の一部として用意されています。インスタンス・ディレクトリー内の ~/sqllib/samples/perf の下にあります。
- db2mon.sh
- db2mon.sql (db2monBefore.sql、db2monInterval.sql、db2monAfter.sql の連結形式)
- db2mon_import.sql
- db2mon_export.sql
- db2mon_report.sql
db2mon は、USER TEMPORARY 表スペースが存在するか、また、MON_ACT_METRICS および MON_REQ_METRICS に最低限必要な値が設定されているかを検査します。 この検査の結果は、レポートの前提条件セクションで報告されます。
プロシージャー
db2mon を使用してパフォーマンス・モニター・データを収集してレポートを生成するには、以下の手順に従います。
結果
レポートには有用な照会が多数含まれています。大まかには以下のセクションに分けられます。
- モニター期間の最初と最後に収集されたポイント・イン・タイム・データ (現在実行中の SQL、ユーティリティー、ロック待機など)。
- モニター期間にわたって測定された累積データ
- さまざまな階層レベル (データベース・レベル、表スペース・レベル、バッファー・プール・レベル、表レベル、照会レベル、接続レベルなど) で収集されたデータ。
- さまざまなデプロイメント・タイプについて収集されるデータ (例: 標準 Db2 ESE、 Db2 pureScale、および Db2 with BLU)。
- 環境情報 (データベースとインスタンスの構成、レジストリー変数、CPU の数と使用量、メモリー使用量など)。
例
この出力例は徐々に情報が詳しくなっていきます。まず概要セクションが表示され、その後により細かい詳細セクションが続きます。 概要セクションでデータベースのパフォーマンスを全体的に理解してから、その情報を基にして、さらに深く理解するにはどの詳細セクションを調べるべきかを判断します。
レポート内のほとんどの表は、以下の出力より広い幅になります。 ここでは、読みやすくするために表の一部を切り取っています。 出力行を分割して折り返している箇所もあります。
- 「Throughput metrics at database level」セクションを使用して、システムで実行されている処理を特定します。
====================================== Throughput metrics at database level ====================================== select min(ts_delta) ts_delta, member, decimal((sum(act_completed_total) / float(min(ts_delta))), 10, 1) as act TS_DELTA MEMBER ACT_PER_S CMT_PER_S RB_PER_S DDLCK_PER_S SEL_P_S UID_P_S ROWS_INS_P_S -------- ------ --------- --------- ---------- ------------ --------- ---------- ------------ 35 0 22629.7 2361.1 0.0 0.0 13089.6 9540.0 4364.0 35 1 24331.0 2525.0 0.0 0.0 14064.1 10266.8 4638.2 35 2 27331.5 2842.1 0.0 0.0 15804.4 11527.1 5204.6 35 3 25674.2 2682.0 0.0 0.0 14859.5 10814.6 4878.8 4 record(s) selected.上記の出力には、4 つのメンバーのそれぞれが約 2400 トランザクション/秒 (CMT_PER_S)、約 25,000 SQL ステートメント/秒 (ACT_PER_S) を実行していることが示されており、その他にも表中のメトリックが示されています。 これらのトランザクションとステートメントは、35 秒間 (TS_DELTA) にわたって測定されています。 データ収集のプロセスによって、予定した間隔が若干延長されることがあります。 この場合、予定した間隔は 30 秒でした。
一般に、レポートでは以下の省略名を使用しています。- ACT_PER_S: 1 秒あたりのアクティビティー数
- CMT_PER_S: 1 秒あたりのコミット数
- RB_PER_S: 1 秒あたりのロールバック数
- DDLCK_PER_S: 1 秒あたりのデッドロック数
- SEL_P_S: 1 秒あたりの SELECT ステートメント数
- UID_P_S: 1 秒あたりの UPDATE/INSERT/DELETE ステートメント数
- ROWS_INS_P_S: 1 秒あたりの挿入された行数
- 「Time breakdown at database level」セクションを使用して、データベースの処理時間を特定します。
===================================================== Time breakdown at database level (wait + processing) ===================================================== select member, integer(sum(total_rqst_time)) as total_rqst_tm, decimal(sum(total_compile_time) / float(sum MEMBER TOTAL_RQST_TM PCT_COMPILE PCT_SECTION PCT_SORT PCT_COL PCT_COL_SYNOP PCT_COMMIT PCT_RBACK PCT_CONN ------ ------------- ----------- ----------- -------- ------- ------------- ---------- --------- -------- 0 1035374 0.04 78.59 0.74 0.00 0.00 9.38 0.00 0.10 1 438810 0.01 75.85 1.02 0.00 0.00 15.15 0.00 0.12 2 492605 0.01 74.57 1.06 0.00 0.00 16.66 0.00 0.09 3 482646 0.01 76.32 1.04 0.00 0.00 14.73 0.00 0.11 4 record(s) selected.PCT_SECTION には、 SQL ステートメントの処理時間と待機時間が含まれています。
この例では、ほとんどの時間がセクション処理 (PCT_SECTION) に費やされ、次に費やされた時間の割合が大きいのはコミット処理です (PCT_COMMIT)。 このパターンは正常と見なされます。
トランザクション・システム上でコンパイル時間 (PCT_COMPILE) が 0.15 (つまり 15 %) を超えている場合は、アプリケーションがパラメーター・マーカーではなくリテラルを使用している可能性があります。
- 「Wait times at database level」セクションでは、データベースが待機に費やした時間が報告されます。 多くの場合、「Wait times at database level」セクションが、パフォーマンスの正常性を評価するうえで最も重要な最上位の情報です。
============================== Wait times at database level ============================== select w.member, integer(sum(total_rqst_time)) as total_rqst_tm, integer(sum(total_wait_time)) as total_wait MEMBER TOTAL_RQST_TM TOTAL_WAIT_TM PCT_RQST_WAIT PCT_LOCK PCT_GLB_LOCK PCT_LTCH PCT_LG_DSK PCT_RCLM PCT_CF ------ ------------- ------------- ------------- -------- ------------ -------- ---------- -------- ------ 0 1035374 732450 70.74 1.31 0.57 0.89 4.28 1.07 56.26 1 438810 291659 66.46 2.29 1.51 0.57 8.03 1.91 46.21 2 492605 320535 65.06 1.50 1.13 0.92 9.37 1.67 44.36 3 482646 319718 66.24 1.39 0.86 1.05 7.74 1.87 46.23 4 record(s) se1ected.この例では、各メンバーが各要求待機 (PCT_RQST_WAIT) に約 67% を費やしています。 この待機時間の大部分はクラスター・キャッシング・ファシリティー (CF) 通信 (PCT_CF) に費やされ、その次にログの書き込み (PCT_LG_DST) とロック待機 (PCT_LOCK) に費やされています。
- レポート内のさまざまなセクションを使用して、データベース処理時間が最も長いステートメントを特定できます。
レポートのさまざまなセクションに、パッケージ・キャッシュからのステートメント・データが示されます。そこに示されるのは、モニター期間中に実行が終了したステートメントです。 モニターが終了してもまだ実行されていたステートメントは、レポートの最初のポイント・イン・タイム・セクションに示されます。
合計アクティビティー時間での上位 100 個のステートメントがリストされます。また、基本メトリック、待機時間、ソート、入出力などの視点に焦点を当ててさまざまな表示が表に示されます。
「Wait times at database level」セクション (例 3) をこの例の「Top SQL statements by execution time」セクションと比較して、以下のいずれかが原因で待機時間が長くなるかどうかを判別します。- いくつかのステートメント
- すべてのステートメントに影響するシステム全体の問題
「Top SQL statements by execution time」セクションには、未加工の CPU 使用量が示されます。
レポートの出力 (続き):====================================== Top SQL statements by execution time ====================================== select member, integer(num_exec_with_metrics) as num_exec, coord_stmt_exec_time, decimal(coord_stmt_exec_time / double(num_exec_with_metrics), 10, 2) as avg_coord_exec_time, decimal( (coord_stmt_exec_time / double(... MEMBER NUM_EXEC COORD_STMT_EXEC_TIME AVG_COORD_EXEC_TIME PCT_COORD_STMT_EXEC_TIME TOTAL_CPU_TIME ... ------ -------- -------------------- ------------------- ------------------------ -------------- ... 0 61729 301979 4.89 15.09 29928189 ... 3 69026 150782 2.18 7.53 33255990 ... 2 72832 148618 2.04 7.42 34689087 ... 1 64562 137670 2.13 6.88 3121S907 ... 0 124839 112563 0.90 5.62 4468845 ... 0 124833 111863 0.89 5.59 3686860 ... 0 124836 58906 0.46 2.91 2807094 ... 0 11350 57011 5.02 2.84 1997313 ... 2 147141 46613 0.31 2.33 4830165 ... 3 138286 45568 0.32 2.27 4618735 ... 3 138285 40548 0.29 2.02 5767918 ... 2 147137 39975 0.27 1.99 6031554 ... 1 131525 39818 0.30 1.99 4457211 ...... AVG_CPU_TIME PCT_WAIT_TIME AVG_SECT_TIME AVG_COL_TIME STMT_TEXT ... ------------ ------------- ------------- ------------ ---------------------------------------------- ... 484 53.67 4.89 0.00 Se1ect Count(Distinct S_I_ID) from STOCK, ORDE ... 481 40.93 2.18 0.00 Se1ect Count(Distinct S_I_ID) from STOCK, ORDE ... 476 36.56 2.04 0.00 Se1ect Count(Distinct S_I_ID) from STOCK, ORDE ... 483 41.59 2.13 0.00 Se1ect Count(Distinct S_I_ID) from STOCK, ORDE ... 35 89.65 0.90 0.00 Update STOCK set S_QUANTITY = ?, S_YTD = ?, S_ ... 29 90.54 0.89 0.00 Se1ect S_QUANTITY, S_DIST_01, S_DIST_02, S_DIS ... 22 85.45 0.46 0.00 Insert into ORDER_LINE va1ues (?, ?, ?, ?, ?, ... 175 93.18 5.02 0.00 Update ORDER_LINE set OL_DELIVERY_D = ? where ... 32 84.75 0.31 0.00 Se1ect S_QUANTITY, S_DIST_01, S_DIST_02, S_DIS ... 33 85.28 0.32 0.00 Se1ect S_QUANTITY, S_DIST_01, S_DIST_02, S_DIS ... 41 83.84 0.29 0.00 Update STOCK set S_QUANTITY = ?, S_YTD = ?, S_ ... 40 82.78 0.27 0.00 Update STOCK set S_QUANTITY = ?, S_YTD = ?, S_ ... 33 86.20 0.30 0.00 Se1ect S_QUANTITY, S_DIST_01, S_DIST_02, S_DIS 13 record(s) selected.「Wait time breakdown」セクションには、ディスク、ラッチ、ロック (ただし、必ずしもこれらに限定されない) などのリソースを待機しているために実行されていないステートメントが示されます。
レポートの出力 (続き):============================================================== Wait time breakdown for top SQL statements by execution time ============================================================== select member, decimal((total_act_wait_time / double(total_act_time)) * 100, 5, 2) as pct_wait, decimal((log_disk_wait_time / double(total_act_time)) * 100, 5, 2) as pct_lg_dsk, decimal((log_buffer_wait... MEMBER PCT_WAIT PCT_LG_DSK PCT_LG_BUF PCT_LOCK PCT_GL_LK PCT_LTCH PCT_RCLM PCT_CF PCT_PFTCH PCT_DIAG ... ------ -------- ---------- ---------- -------- --------- -------- -------- ------- --------- -------- ... 0 53.67 0.00 0.00 2.37 0.36 2.34 0.00 47.55 0.00 0.00 ... 3 40.93 0.00 0.00 2.29 1.02 2.57 0.00 30.97 0.00 0.00 ... 2 36.56 0.00 0.00 1.42 0.65 1.88 0.00 29.37 0.00 0.00 ... 1 41.59 0.00 0.00 5.04 3.21 1.05 0.00 31.96 0.00 0.00 ... 0 89.65 0.16 0.00 0.00 0.00 0.07 0.35 89.06 0.00 0.00 ... 0 90.54 0.00 0.00 2.32 2.29 0.00 3.59 75.30 0.00 0.00 ... 0 85.45 4.61 0.00 0.00 0.00 0.71 3.77 75.19 0.00 0.00 ... 0 93.18 0.00 0.00 0.00 0.00 0.02 0.05 88.41 0.00 0.00 ... 2 84.75 0.00 0.00 5.16 5.12 0.00 4.94 63.97 0.00 0.00 ... 3 85.28 0.00 0.00 0.23 0.19 0.00 7.03 67.87 0.00 0.00 ... 3 83.84 0.19 0.00 0.00 0.00 0.01 1.50 82.12 0.00 0.00 ... 2 82.78 0.20 0.00 0.00 0.00 0.01 0.71 81.85 0.00 0.00 ... 1 86.20 0.00 0.00 0.00 0.33 0.00 4.85 70.23 0.00 0.00 ... 1 83.34 0.22 0.00 0.00 0.00 0.00 0.90 82.20 0.00 0.00 ...... PCT_POOL_RD PCT_DIR_WR PCT_DIR_RD STMT_TEXT ... ----------- ---------- ---------- ----------------------------------------------------------------- ... 1.40 0.00 0.00 Se1ect Count(Distinct S_I_ID) from STOCK, ORDER_LINE where (S_W_I ... 5.06 0.00 0.00 Se1ect Count(Distinct S_I_ID) from STOCK, ORDER_LINE where (S_W_I ... 3.87 0.00 0.00 Se1ect Count(Distinct S_I_ID) from STOCK, ORDER_LINE where (S_W_I ... 3.52 0.00 0.00 Se1ect Count(Distinct S_I_ID) from STOCK, ORDER_LINE where (S_W_I ... 0.00 0.00 0.00 Update STOCK set S_QUANTITY = ?, S_YTD = ?, S_ORDER_CNT = ?, S_RE ... 9.27 0.00 0.00 Se1ect S_QUANTITY, S_DIST_01, S_DIST_02, S_DIST_03, S_DIST_04, S_ ... 0.49 0.00 0.00 Insert into ORDER_LINE va1ues (?, ?, ?, ?, ?, ?, ?, ?, ?, ?) ... 4.67 0.00 0.00 Update ORDER_LINE set OL_DELIVERY_D = ? where OL_W_ID = ? and OL_ ... 10.32 0.00 0.00 Se1ect S_QUANTITY, S_DIST_01, S_DIST_02, S_DIST_03, S_DIST_04, S_ ... 10.12 0.00 0.00 Se1ect S_QUANTITY, S_DIST_01, S_DIST_02, S_DIST_03, S_DIST_04, S_ ... 0.00 0.00 0.00 Update STOCK set S_QUANTITY = ?, S_YTD = ?, S_ORDER_CNT = ?, S_RE ... 0.00 0.00 0.00 Update STOCK set S_QUANTITY = ?, S_YTD = ?, S_ORDER_CNT = ?, S_RE ... 10.76 0.00 0.00 Se1ect S_QUANTITY, S_DIST_01, S_DIST_02, S_DIST_03, S_DIST_04, S_ ... 0.00 0.00 0.00 Update STOCK set S_QUANTITY = ?, S_YTD = ?, S_ORDER_CNT = ?, S_RE 14 record(s) selected.ヒント: 「ステートメントおよびプラン ID (Statement and Plan Identifiers)」セクションには、上位 100 件の各ステートメントの EXECUTABLE_ID が表示されます。 EXECUTABLE_ID を MON_GET_PKG_CACHE_STMT 関数で使用して、これらのステートメントのアクセス・プランを取得できます。 EXECUTABLE_ID を以下のコマンドで使用して、Explain プランを判別することもできます。db2 "call explain_from_section(x'<executable id>','M',NULL,0,'<current user>',?,?,?,?,?)"「Top SQL statements by execution time, aggregated by PLANID」セクションは、「Top SQL statement by execution time」セクションに似ています。 リテラル値だけが異なる (PLANID ハッシュ値は同じ) すべてのステートメントが集約されて、合計コストが示されます。 この情報は、トランザクション・アプリケーションがリテラル値を含む多数の SQL ステートメントを実行している場合に役に立ちます。
「IO statistics per statement」セクションには、上位 100 個の SQL ステートメントのバッファー・プール・アクティビティーが示されます。
レポートの出力 (続き):========================================================== IO statistics per stmt - top statements by execution time ========================================================== select member, integer(num_exec_with_metrics) num_exec, decimal(pool_data_l_reads/double(num_exec_with_metrics), 16,1) as avg_d_lrd, decimal(pool_data_p_reads/double(num_exec_with_metrics), 10,1) ... MEMBER NUM_EXEC AVG_D_LRD AVG_D_PRD AVG_I_LRD AVG_I_PRD AVG_TD_PRD AVG_TI_PRD ... ------ ----------- ---------- ---------- ---------- ---------- ----------- ----------- ... 0 61729 0.0 0.0 607.4 0.1 0.0 0.0 ... 3 69026 0.0 0.0 607.4 0.4 0.0 0.0 ... 2 72832 0.0 0.0 607.3 0.2 0.0 0.0 ... 1 64562 0.0 0.0 607.3 0.2 0.0 0.0 ... 0 124839 2.0 0.0 4.0 0.0 0.0 0.0 ... 0 124833 1.1 0.1 3.0 0.0 0.0 0.0 ... 0 124836 1.0 0.0 4.1 0.0 0.0 0.0 ... 0 11350 20.3 0.4 4.1 0.0 0.0 0.0 ... 2 147141 1.1 0.1 3.0 0.0 0.0 0.0 ... 3 138286 1.1 0.1 3.0 0.0 0.0 0.0 ... 3 138285 2.0 0.0 4.0 0.0 0.0 0.0 ... 2 147137 2.0 0.0 4.0 0.0 0.0 0.0 ... 1 131525 1.1 0.1 3.0 0.0 0.0 0.0 ... 1 131523 2.0 0.0 4.0 0.0 0.0 0.0 ... 0 124837 0.0 0.0 2.0 0.0 0.0 0.0 ... 0 11343 0.0 0.0 4.1 0.0 0.0 0.0 ... 2 147135 1.0 0.0 4.1 0.0 0.0 0.0 ... 3 138285 1.0 0.0 4.1 0.0 0.0 0.0 ... 1 131522 1.0 0.0 4.1 0.0 0.0 0.0 ... 0 12533 1.0 0.0 6.0 0.0 0.0 0.0 ... 2 13568 20.4 0.4 4.1 0.0 0.0 0.0 ...... AVG_COL_LRD AVG_COL_PRD AVG_DIR_R_RQS AVG_DIR_W_RQS STMT_TEXT ... ------------ ------------ ------------- ------------- -------------------------- ... 0.0 0.0 0.0 0.0 Se1ect Count(Distinct S_I_] ... 0.0 0.0 0.0 0.0 Se1ect Count(Distinct S_I_] ... 0.0 0.0 0.0 0.0 Se1ect Count(Distinct S_I_] ... 0.0 0.0 0.0 0.0 Se1ect Count(Distinct S_I_] ... 0.0 0.0 0.0 0.0 Update STOCK set S_QUANTITY ... 0.0 0.0 0.0 0.0 Se1ect S_QUANTITY, S_DIST_0 ... 0.0 0.0 0.0 0.0 Insert into ORDER_LINE valu ... 0.0 0.0 0.0 0.0 Update ORDER_LINE set OL_DE ... 0.0 0.0 0.0 0.0 Se1ect S_QUANTITY, S_DIST_0 ... 0.0 0.0 0.0 0.0 Se1ect S_QUANTITY, S_DIST_0 ... 0.0 0.0 0.0 0.0 Update STOCK set S_QUANTITY ... 0.0 0.0 0.0 0.0 Update STOCK set S_QUANTITY ... 0.0 0.0 0.0 0.0 Se1ect S_QUANTITY, S_DIST_0 ... 0.0 0.0 0.0 0.0 Update STOCK set S_QUANTITY ... 0.0 0.0 0.0 0.0 Se1ect I_NAME, I_PRICE, I_D ... 0.0 0.0 0.0 0.0 Se1ect sum(OL_AMOUNT) from ... 0.0 0.0 0.0 0.0 Insert into ORDER_LINE valu ... 0.0 0.0 0.0 0.0 Insert into ORDER_LINE valu ... 0.0 0.0 0.0 0.0 Insert into ORDER_LINE valu ... 0.0 0.0 0.0 0.0 Insert into ORDERS va1ues ( ... 0.0 0.0 0.0 0.0 Update ORDER_LINE set OL_DE 21 record(s) selected.入出力情報から、ステートメントで索引が使用されているかどうかがわかる場合があります。 AVG_I_LRD は、1 回の実行で行われた索引論理読み取り数の平均を表します。 AVG_D_LRD は、データ論理読み取り数の平均を表します。 上記の出力の最初の 4 つのエントリーは、AVG_I_LRD 値が大きく AVG_D_LRD 値がゼロになっています。 この値の組み合わせは、索引ベースのプランであることを示しています。 ステートメントのデータ論理読み取り数が大きく、索引論理読み取り数が小さい場合は、索引を変更するとパフォーマンスが向上する可能性があります。
- 「Database log write times」セクションを使用して、ログ・ディスクのパフォーマンスを調べられます。
他のステートメントよりも実行時間が比較的長いステートメントは、アクセス・プランの最適化に問題がある可能性があります。 索引を追加しても解決されない場合は、データベース・レベルとステートメント・レベルの最長待機時間を比較してください。 その情報で待機時間の最大の要因を特定してから、より詳しい情報が得られる適切なレポート・セクションを参照してください。
db2mon では、個々の待機時間の割合 (ログ・ディスク待機時間など) を、合計待機時間の割合ではなく合計要求時間の割合として計算します。 合計待機時間 (すべてを足して 100% の待機時間にしたもの) は、monreport.dbsummary プロシージャーを使用して計算できます。
トランザクション・アプリケーションの場合は、「Wait times at database level」セクション (例 3) の PCT_LG_DSK 列に報告されるログ・ディスク待機時間の割合が高いことがよくあります。
レポートの出力 (続き):========================== Database log write times ========================== select member, num_log_write_io, case when ts_delta > 0 then decimal( double(num_log_write_io) / ts_delta, 10, 4 ) else null end as ... MEMBER NUM_LOG_WRITE_IO LOG_WRITE_IO_PER_S LOG_WRITE_MB_PER_S ... ------ ---------------- ------------------ ------------------ ... 0 57237 1788.6562 7.0000 ... 1 68286 2133.9375 8.3437 ... 2 69373 2167.9062 8.5312 ... 3 69286 2165.1875 8.4687 ...... LOG_WRITE_TIME LOG_WRITE_TIME_PER_IO_MS NUM_LOG_BUFFER_FULL ... -------------- ------------------------ -------------------- ... 25306 0.4421 0 ... 26345 0.3858 0 ... 26669 0.3894 0 ... 26741 0.3859 0 4 record(s) selected.上記の出力では、入出力あたりのログ書き込み時間 (LOG_WRITE_TIME_PER_IO_MS) は約 0.4 ミリ秒で、最適です。 値はシステムによって異なりますが、ログ書き込み時間の割合が 4.0 ミリ秒を超える場合は、ストレージ構成に対する変更が必要な可能性があります。 各ファイル・システムのキャッシュ、RAID、LUN 数を変更するなどの再構成を行います。
- 「Bufferpool read statistics」セクションと「Disk read and write I/O times」セクションを使用して、読み取り時間を調べられます。注: 「Bufferpool read statistics」セクションの出力には、以下の省略形が含まれます。
- POOL_DATA_L_READS: バッファー・プール・データ・ページの論理読み取り (ORGANIZE BY ROW 基本表のアクセス)
- POOL_DATA_P_READS: バッファー・プール・データ・ページの物理読み取り
- POOL_INDEX_L_READS: バッファー・プール索引ページの論理読み取り (索引のアクセス)
- POOL_INDEX_P_READS: バッファー・プール索引ページの物理読み取り
- POOL_COL_L_READS: バッファー・プール・カラム・オーガナイズ・データ・ページの論理読み取り (ORGANIZE BY COLUMN 基本表のアクセス)
- POOL_COL_P_READS: バッファー・プール・カラム・オーガナイズ・データ・ページの物理読み取り
レポートの出力 (続き):============================ Bufferpool read statistics ============================ select member, substr(bp_name,1,20) as bp_name, pool_data_l_reads, pool_data_p_reads, pool_index_l_reads, pool_index_p_reads, pool_col_l_reads, pool_col_p_reads, pool_read_time, case when ... MEMBER BP_NAME POOL_DATA_L_READS POOL_DATA_P_READS POOL_INDEX_L_READS ... ------ ------------- ------------------ ------------------ ------------------- ... 2 IBMDEFAULTBP 3037899 44159 45043859 ... 3 IBMDEFAULTBP 2841993 41020 42586533 ... 1 IBMDEFAULTBP 2696917 38268 40018451 ... 0 IBMDEFAULTBP 2518978 38610 37512769 ...... POOL_INDEX_P_READS POOL_COL_L_READS POOL_COL_P_READS POOL_READ_TIME AVG_READ_TIME ... ------------------- ----------------- ----------------- -------------- ------------- ... 27427 0 0 19619 0.27 ... 34728 0 0 21063 0.27 ... 23941 0 0 17030 0.27 ... 10298 0 0 28304 0.57 4 record(s) selected.プールの読み取り時間が長いという問題は、よく見られる問題です。 高いプール読み取り時間は、PCT_POOL_RD 列の「Wait time breakdown for top SQL statements by execution time」セクション (例 4から) で報告されます。 この問題は、システムがディスクからバッファー・プールに多数のページを読み取るときに特によく見られます。 一般には、このように高負荷のページ読み取りアクティビティーは、データベースの活動化の直後、または新たにアプリケーションが接続を開始したときに発生します。 プール読み取り時間の平均 (AVG_READ_TIME) は、バッファー・プール・レベルと表スペース・レベルで報告されます。 同様に、ラージ・オブジェクトの直接入出力時間の割合が高いかどうかを、AVG_DRCT_READ_TIME と AVG_DRCT_WRITE_TIME で追跡できます。
レポートの出力 (続き):=============================== Disk read and write I/O times =============================== select member, substr(tbsp_name,1,20) as tbsp_name, (pool_data_p_reads + pool_index_p_reads+ pool_col_p_reads) as num_reads, case when ((pool_data_p_reads + pool_index_p_reads+ pool ... MEMBER TBSP_NAME NUM_READS AVG_READ_TIME DIRECT_READ_REQS AVG_DRCT_READ_TIME ... ------ ---------- ---------- ------------- ---------------- ------------------ ... 3 TBS_OM 29235 0.27 0 - ... 2 TBS_OM 22195 0.26 0 - ... 2 TBS_CST 21312 0.27 0 - ... 3 TBS_CST 19700 0.28 0 - ... 1 TBS_OM 19201 0.26 0 - ... 1 TBS_CST 18485 0.27 0 - ... 0 TBS_CST 17705 0.56 0 - ... 2 TBS_STK 16568 0.27 0 - ... 0 TBS_STK 16127 0.59 0 - ... 3 TBS_STK 15559 0.27 0 - ...... NUM_WRITES AVG_WRITE_TIME DIRECT_WRITE_REQS AVG_DRCT_WRITE_TIME ... ----------- -------------- ------------------ ------------------- ... 0 - 0 - ... 0 - 0 - ... 0 - 0 - ... 0 - 0 - ... 0 - 0 - ... 0 - 0 - ... 0 - 0 - ... 0 - 0 - ... 0 - 0 - ... 0 - 0 - 10 record(s) selected. - 「Round-trip CF」セクションを使用して、メンバーと CF の間のメッセージの往復時間を調べられます。
CF 待機時間の割合 (%) は、PCT_CF で「Wait times at database level」(例 3) および「Wait time breakdown」(例 4) として報告されます。 レポートの PCT_CF 値が高い場合、「往復 CF」セクションには、 Db2 メンバーと CF の間で交換されるメッセージのパフォーマンス・データが表示されます。
=================================================================== Round-trip CF command execution counts and average response times =================================================================== select member, id, cast(substr(cf_cmd_name,1,30) as varchar(30)) as cf_cmd_name, total_cf_requests, decimal( doub... MEMBER ID CF_CMD_NAME TOTAL_CF_REQUESTS AVG_CF_REQUEST_TIME_MICRO ------ ------ --------------------- ------------------ ------------------------- 2 128 SetLockState 1016554 60.11 3 128 SetLockState 955295 65.82 1 128 SetLockState 905310 62.04 0 128 SetLockState 851689 223.05 3 128 ReadAndRegister 682169 88._8 2 128 ReadAndRegister 671832 83.39 1 128 ReadAndRegister 662450 84.51 0 128 ReadAndRegister 627922 282.94 2 128 SetLockStateMultiple 413551 70.50 3 128 SetLockStateMultiple 387168 77.93 1 128 SetLockStateMultiple 367427 73.74 0 128 SetLockStateMultiple 345954 252.11 12 record(s) selected. - 「Page reclaim metrics」セクションを使用して、索引ページとデータ・ページに関するページ再利用メトリックを調べられます。
再利用待機時間は、PCT_RCLM の「Wait times at database level」(例 3) および「Wait time breakdown」(例 4) で報告されます。 レポート内の PCT_RCLM 値がゼロより大きい場合、以下のセクションに、どの表の再利用アクティビティーが最大か、また表と表の索引のどちらが再利用されているかが示されます。
=============================================== Page reclaim metrics for index and data pages =============================================== select member, substr(tabschema,1,20) as tabschema, substr(tabname,1,40) as tabname, substr(objtype,1,10) as objtype, data_partition_id, iid, (page ... MEMBER TABSCHEMA TABNAME OBJTYPE DATA_PARTITION_ID IID PAGE_RECLAIMS RECLAIM_WAIT_TIME ------ ---------- --------------- -------- ----------------- ---- -------------- ------------------ 0 DTW ORDERS INDEX - - 4334 3357 2 DTW ORDER_LINE INDEX - - 3870 3096 2 DTW ORDERS INDEX - - 3652 2732 3 DTW ORDERS INDEX - - 3638 2724 1 DTW ORDER_LINE INDEX - - 3634 2666 3 DTW ORDER_LINE INDEX - - 3577 2391 1 DTW ORDERS INDEX - - 3502 2326 0 DTW ORDER_LINE INDEX - - 4169 2286 0 DTW STOCK_501_750 INDEX - - 165 983 0 DTW STOCK_751_1000 INDEX - - 199 952 1 DTW NEW_ORDER INDEX - - 441 880 11 record(s) selected.この出力例には、すべてのメンバーで ORDERS および ORDER_LINE の索引に対する再利用アクティビティーが最も多いことが示されています。 しかし、これらの RECLAIM_WAIT_TIME 値は大きくありません。これは、「Wait times at database level」セクションの PCT_RCLM (再利用待機時間のパーセント) を調べることで確認できます。 索引ページの再利用アクティビティーが多いのはよく見られることです。RANDOM 索引、CURRENT MEMBER のパーティション化、範囲パーティション化を使用して改善できます。
- 「Page reclaim metrics for SMP pages」セクションを使用して、スペース・マップ・ページ (SMP) の再利用アクティビティーを調べられます。 スペース・マップ・ページ再利用メトリックについて詳しくは、 spacemappage_reclaim_wait_time-スペース・マップ・ページ再利用の待機時間モニター・エレメント を参照してください。
以下の出力は、再利用された SMP ページを示しています。多くの場合、原因は、表スペースのエクステント・サイズが小さ過ぎる表に大量の挿入が行われたことです。
==================================== Page reclaim metrics for SMP pages ==================================== select member, substr(tabschema,1,20) as tabschema, substr(tabname,1,40) as tabname, substr(objtype,1,10) as objtype, data_partition_id, iid, (spacemapp ... MEMBER TABSCHEMA TABNAME OBJTYPE DATA_PARTITION_ID IID SMP_PAGE_RECLAIMS SMP_PAGE_RECLAIM_WAIT_TIME ------ --------- ---------- ------- ----------------- --- ----------------- -------------------------- 3 DTW ORDER_LINE TABLE - - 9 254 2 DTW ORDER_LINE INDEX - - 57 241 0 DTW ORDER_LINE INDEX - - 90 192 0 DTW ORDER_LINE TABLE - - 9 170 3 DTW ORDER_LINE INDEX - - 67 169 1 DTW ORDER_LINE INDEX - - 57 76 1 DTW ORDER_LINE TABLE - - 3 10 2 DTW ORDER_LINE TABLE - - 4 3 3 DTW NEW_ORDER TABLE - - 2 3 1 DTW NEW_ORDER TABLE - - 1 2 10 record(s) se1ected. - 「Latch wait metrics」セクションを使用して、ラッチ待機を調べられます。
ラッチ待機時間のパーセンテージは、「Wait times at database level」(例 3) および「Wait time breakdown」(例 4) の PCT_LTCH で報告されます。 ラッチ待機時間の割合 (PCT_LTCH) が 15% から 20% を超えると、高いと見なされます。 次のセクションに、ラッチ待機の詳細がタイプ別に示されます。
レポートの出力 (続き):==================== Latch wait metrics ==================== select member, substr(latch_name,1,60) as latch_name, total_extended_latch_wait_time as tot_ext_latch_wait_time_ms, total_extended_latch_waits ... MEMBER LATCH_NAME TOT_EXT_LATCH_WAIT_TIME_MS ... ------ ------------------------------------- -------------------------- ... 0 SQLO_LT_SQLB_BPD_bpdLatch_SX 7182 ... 3 SQLO_LT_SQLB_BPD_bpdLatch_SX 4085 ... 2 SQLO_LT_SQLB_BPD_bpdLatch_SX 3086 ... 1 SQLO_LT_SQLB_BPD_bpdLatch_SX 1764 ... 0 SQLO_LT_SQLB_BPD_WARLatch 1272 ... 2 SQLO_LT_SQLB_BPD_WARLatch 1168 ... 3 SQLO_LT_SQLB_BPD_WARLatch 706 ... 1 SQLO_LT_SQLB_BPD_WARLatch 509 ... 0 SQLO_LT_SQLP_LHSH_hshlatch 263 ... 3 SQLO_LT_SQLI_INX_PAGE_CACHE_ipcLatch 240 ... 2 SQLO_LT_SQLI_INX_PAGE_CACHE_ipcLatch 221 ... 1 SQLO_LT_SQLI_INX_PAGE_CACHE_ipcLatch 193 ... 0 SQLO_LT_SQLI_INX_PAGE_CACHE_ipcLatch 175 ...... TOT_EXT_LATCH_WAITS TIME_PER_LATCH_WAIT_MS ... -------------------- ---------------------- ... 4454 1.61 ... 1965 2.07 ... 2088 1.47 ... 1724 1.02 ... 1783 0.71 ... 2637 0.44 ... 2110 0.33 ... 1870 0.27 ... 758 0.34 ... 36 6.66 ... 45 4.91 ... 21 9.19 ... 25 7.00 13 record(s) selected.システム上で稼働しているすべてのエージェントの間で、30 秒の間に測定された TIME_PER_LATCH_WAIT_MS のほとんどの値が、数秒をはるかに下回っています。 したがって、このシステムには重大なラッチの問題は見られません。
ラッチ待機時間の割合が高くなる原因には、さまざまな原因があります。 ラッチ待機が非常に長いシナリオに対処するには、以下の手法を使用してください。- Db2 pureScaleでは、ラッチ待機時間とページ再利用時間の間に強い相関が存在します。 シナリオによっては、2% から 5% の再利用待機時間が原因で 20% から 40% のラッチ待機時間が発生する場合があります。 「索引およびデータ・ページのページ再利用メトリック (Page reclaim metrics for index and data pages)」セクション (例 8) を調べると、表または索引を変更する必要があることが示される場合があります。 この手法は、同じ SQL ステートメントでラッチ待機時間と再利用待機時間の両方が長い場合に特に当てはまります。
- Db2 バージョン 11.1でラッチが大幅に改善されました。
SQLO_LT_SQLB_HASH_BUCKET_GROUP_HEADER__groupLatchという名前のラッチの「Latch wait metrics」セクションでラッチ待機時間が最も長くなっている場合は、バージョン 11 にアップグレードすることで、そのラッチを保持するための消費時間が短縮される可能性があります。 - 処理集中型のバッファー・プール・ページには、
SQLB_BPD__bpdLatchタイプが関連付けられています。 ラッチ待機時間が長いステートメントを参照して、関係する表を特定してください。 ラッチ競合を減らす方法の 1 つは、表を範囲パーティション化してパーティション化索引を使用する方法です。