Amazon Aurora PostgreSQLでOracle Statspackの代替をするには

はじめに

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の統計情報コレクタ