はじめに
Oracle Databaseのパフォーマンス調査に有用なStatspack、
名前の通りに様々なタイプの統計情報をまとめて確認することができ、とても便利です。
この記事では、Amazon Aurora PostgreSQLで
同様の情報を確認できるようにするための機能をまとめてみます。
Statspackの内容
Statspackは取得レベルがあり、例えばレベル6だと以下の情報を取得できます。
レベル | 取得内容 |
---|---|
0 | 全体的なパフォーマンス統計 |
5 | SQL ステートメント |
6 | SQL 実行計画および SQL 実行計画の使用率 |
Statspackの代替手段
- 全体的なパフォーマンス統計 -> Performance Insights
- SQL ステートメント -> Performance Insights
- SQL 実行計画および SQL 実行計画の使用率 -> Query Plan Managementまたはauto_explain
上記のように内容に応じて、それぞれ対応機能があります。
Performance Insightsについて
以下の3つをダッシュボード上でまとめて確認することができます。
- データベース全体のメトリクス
- 負荷に関するメトリクス
- SQLステートメント
ダッシュボード上で自由に表示時間範囲を切り替えられるのが便利です。
Query Plan Managementについて
設定方法
機能の概要・使い方はリンク先にまとまっていますが、
StatspackのSQL実行計画レポートの取得に絞ると、必要な設定パラメータは以下の2つです。
設定先 | パラメータ名 | 設定値 |
---|---|---|
クラスター | rds.enable_plan_management | 1 |
データベース | apg_plan_mgmt.capture_plan_baselines | automatic |
パラメータ設定後にCREATE EXTENSION apg_plan_mgmt
を実行すれば設定完了です。
利用方法
実行したSQLの実行計画を確認するには以下2ステップが必要です。
Statspackで、まずSQLの一意情報を把握してから実行計画レポートを取得するのと同じ流れです。
- 調査したいSQLのsql_hash,plan_hashを以下SQLで取得する
select sql_hash,plan_hash from apg_plan_mgmt.dba_plans where sql_text like '調査したいSQL';
- 実行計画取得関数の引数にsql_hash,plan_hashを渡して実行計画を取得する
apg_plan_mgmt.get_explain_plan(sql_hash,plan_hash,null)
*get_explain_planリファレンス
取得結果例
Aggregate (cost=16300.12..16300.13 rows=1 width=8) (actual time=0.013..0.014 rows=1 loops=1)
-> Nested Loop (cost=1.23..16300.12 rows=1 width=8) (actual time=0.011..0.012 rows=0 loops=1)
Join Filter: (sj.emp_id = jr.emp_id)
-> Nested Loop (cost=0.80..23.51 rows=1 width=40) (actual time=0.011..0.011 rows=0 loops=1)
-> Nested Loop (cost=0.43..18.90 rows=1 width=32) (actual time=0.011..0.011 rows=0 loops=1)
Join Filter: (sj.emp_id = ps.emp_id)
-> Index Only Scan using pk_jlnk_emp on jlnk_emp ps (cost=0.43..8.46 rows=1 width=24) (actual time=0.011..0.011 rows=0 loops=1)
Index Cond: ((subsystem_id = 0) AND (pay_id = 298) AND (trn_id = 0) AND (yyyymm = 202210) AND (act_id = 2))
Heap Fetches: 0
-> Seq Scan on person sj (cost=0.00..10.20 rows=20 width=8) (never executed)
-> Index Only Scan using emp_idx on emp id (cost=0.38..4.60 rows=1 width=8) (never executed)
Index Cond: ((hire_date <= '2382-12-31 00:00:00'::timestamp without time zone) AND (end_date >= '2382-12-31 00:00:00'::timestamp without time zone) AND (emp_id = sj.emp_id))
Heap Fetches: 0
-> Index Scan using pk_jlnktrn on jlnktrn jr (cost=0.42..16276.59 rows=1 width=32) (never executed)
Index Cond: ((seq_no >= 0) AND (seq_no <= '9999999999'::bigint) AND (sub_id = 0) AND (pay_id = 298) AND (trn_id = 0) AND (yyyymm = 202210) AND (act_id >= 2) AND (act_id <= 3))
Filter: ((act_flag = 0) AND (ptn_no = '-1'::integer) AND (table_no = 52000) AND ((field_id)::text = 'kn_cd'::text))
Planning Time: 1.347 ms
Execution Time: 0.063 ms
auto_explainについて
実行時間の閾値を指定して、あらかじめ指定した取得レベルで実行計画をログに出力することができます。
まとめ
Statspackの情報は以下の機能で同様のことが出来ると思います。
- 全体的なパフォーマンス統計 -> Performance Insights
- SQL ステートメント -> Performance Insights
- SQL 実行計画および SQL 実行計画の使用率 -> Query Plan Managementまたはauto_explain
ここでは触れませんでしたが、pg_stat_activityやpg_stat_statementsなど
PostgreSQLの統計情報ビューもパフォーマンス調査に便利です。
参考リンク
Amazon RDS または Amazon Aurora PostgreSQL の高い CPU 使用率をトラブルシューティングするにはどうすればよいですか?
- Performance Insigths
Amazon Aurora での Performance Insights の概要
【レポート】パフォーマンスチューニングの強い味方!Aurora PostgreSQL Performance Insightsのご紹介 - Query Plan Management
Aurora PostgreSQL のクエリ計画管理を理解する - 統計情報ビュー
PostgreSQLの統計情報コレクタ