版 |
改訂日 |
変更内容 |
---|---|---|
1.0 |
2023/03/31 |
新規作成 |
本作品はCC-BYライセンスによって許諾されています。 ライセンスの内容を知りたい方は こちら でご確認ください。 文書の内容、表記に関する誤り、ご要望、感想等につきましては、PGEConsのサイト を通じてお寄せいただきますようお願いいたします。
Eclipseは、Eclipse Foundation Incの米国、およびその他の国における商標もしくは登録商標です。
IBMおよびDb2は、世界の多くの国で登録されたInternational Business Machines Corporationの商標です。
Intel、インテルおよびXeonは、米国およびその他の国における Intel Corporation の商標です。
Javaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。 文中の社名、商品名等は各社の商標または登録商標である場合があります。
Linux は、Linus Torvalds 氏の日本およびその他の国における登録商標または商標です。
Red HatおよびShadowman logoは、米国およびその他の国におけるRed Hat,Inc.の商標または登録商標です。
Microsoft、Windows Server、SQL Server、米国 Microsoft Corporationの米国及びその他の国における登録商標または商標です。
MySQLは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。 文中の社名、商品名等は各社の商標または登録商標である場合があります。
Oracleは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。 文中の社名、商品名等は各社の商標または登録商標である場合があります。
PostgreSQLは、PostgreSQL Community Association of Canadaのカナダにおける登録商標およびその他の国における商標です。
Windows は米国 Microsoft Corporation の米国およびその他の国における登録商標です。
TPC, TPC Benchmark,TPC-C, TPC-E, tpmC, TPC-H, QphHは米国Transaction Processing Performance Councilの商標です
その他、本資料に記載されている社名及び商品名はそれぞれ各社が 商標または登録商標として使用している場合があります 。
WG1(新技術検証ワーキンググループ)
WG2(移行ワーキンググループ)
WG3(課題検討ワーキンググループ)
autovacuum のパラメータ検証
autovacuum_vacuum_cost_delay
autovacuum_vacuum_cost_limit
性能状態を把握するための監視
2018年度検証で整理されている性能に関連する情報 (以降、性能情報) に対し、Aurora PostgreSQLの機能 (Performance Insights等) で確認する方法があるか調査します。Performance Insights等を用いることで、一部確認項目を代替することが出来ることを確認しています。
ケーススタディ
3-1. ディスク性能の考慮漏れによる性能トラブル
2018年度検証の対応手順を基に、Aurora PostgreSQL において、ディスク性能の考慮漏れによる性能トラブルが発生するか、発生したトラブルがパラメータチューニングによって解決するかどうかを確認します。Aurora PostgreSQL においては対象パラメータが最適化されており、本トラブルが起こりにくいことを確認しました。3-2. 適切でない実行計画が選択されてしまうことによる性能トラブル
2018年度検証においてはヒント句の追加や統計情報の取得による実行計画の改善を行っていますが、新しい改善手法として、Aurora PostgreSQL の機能である Query Plan Management を用いた手順を整理します。不適切な実行計画が選択されてしまう性能トラブルに対するチューニングの1つの手法として、QPMを用いることが出来ることを確認しています。
本検証項目 |
2018年度検証項目 |
---|---|
4.autovacuumのパラメータ検証 |
4.6.1.autovacuumの処理時間とパラメータチューニング |
5.性能状態を把握するための監視 |
5.性能状態を把握するための監視 |
6-1.ディスク性能の考慮漏れによる性能トラブル |
6.2.ディスク性能の考慮漏れによる性能トラブル |
6-2.適切ではない実行計画が選択されてしまうことによる性能トラブル |
6.3.適切でない実行計画が選択されてしまうことによる性能トラブル |
NOTE :Aurora PostgreSQLのバージョンは検証当時の最新版である14.5を使用しましたが、その後登場した14.6が2023年4月現在においては長期サポートの対象バージョンとなっており、利用が推奨されています。
項目 |
本検証パラメータ |
2018年度検証 |
---|---|---|
マシンスペック |
db.r5.large (2vCPU, 16GB MEM) |
2vCPU, 8GB MEM |
Aurora(バージョン) |
14.5.1 |
‐ |
PostgreSQL |
14.5 |
11.1 |
pgbench |
PostgreSQL 14.1 付属 |
PostgreSQL 11.1 付属 |
項目 |
本検証パラメータ |
2018年度検証 |
---|---|---|
max_connections |
300 |
同左 |
shared_buffers |
2GB |
同左 |
effective_io_concurrency |
256 |
200 |
max_wal_size |
1GB |
4GB |
min_wal_size |
0.5GB |
2GB |
checkpoint_completion_target |
0.9 |
同左 |
random_page_cost |
1.1 |
同左 |
autovacuum_vacuum_cost_limit |
{200, 400, 600, 800, 1000} |
同左 |
autovacuum_vacuum_cost_delay |
{20, 15, 10, 5} |
同左 |
autovacuum_vacuum_scale_factor |
0.2 |
同左 |
1000万件のデータが格納されたテーブルを作成
各パラメータ (autovacuum_vacuum_cost_limit, autovacuum_vacuum_cost_delay) に値を設定
テーブルに UPDATE コマンドを実行し、テーブルの 25% (250万件) の不要領域を作成
PostgreSQL のログメッセージより、autovacuum の処理時間を確認
NOTE :Heap-only tuples (HOT) の効果を抑止するために更新対象の列にインデックスを作成します。
※ 下表は1秒間に autovacuum が処理できる平均行数、()内は autovacuum_vacuum_cost_limit=200、autovacuum_vacuum_cost_delay=20 を1とした場合との性能比率を示しています。
設定値 |
200 |
400 |
600 |
800 |
1000 |
---|---|---|---|---|---|
cost_delay=20 |
34261
(1.00)
|
61759
(1.80)
|
81081
(2.37)
|
101420
(2.96)
|
113139
(3.30)
|
cost_delay=15 |
44110
(1.29)
|
75980
(2.22)
|
100820
(2.94)
|
119218
(3.48)
|
133929
(3.91)
|
cost_delay=10 |
61200
(1.79)
|
101888
(2.97)
|
124008
(3.62)
|
148309
(4.33)
|
159473
(4.65)
|
cost_delay=5 |
101571
(2.96)
|
142884
(4.17)
|
170648
(4.98)
|
186706
(5.45)
|
193100
(5.64)
|
autovacuum_vacuum_cost_limit=200 autovacuum_vacuum_cost_delay=20
Aurora PostgreSQL の autovacuum の性能が高い結果となったのは、以下の要因が複合的に関連していると考えられます。
メジャーバージョンによる vacuum パフォーマンスの差異
HW 性能の不均一性
DB パラメータの差異
Aurora PostgreSQL のアーキテクチャーの優位性
ただし、Amazon Web Services Japan 社にも実施いただいた、オンプレミス想定のAmazon Relational Database Service(以下、RDS for PostgreSQL)とAurora PostgreSQL間のautovacuum性能差を確認する 追加検証結果 から、同一 HW、同一メジャーバージョンという前提において、Aurora PostgreSQL におけるアーキテクチャーの違いが autovacuum の性能差の大きな要因であると考えられます。 それに従い、今回の2018年度検証とAurora PostgreSQLのautovacuumの性能差の原因についても、アークテクチャの差が大きな要因となっていると考えられます。
項目 |
RDS for PostgreSQL |
Aurora PostgreSQL |
---|---|---|
マシンスペック |
db.r5.large (2vCPU, 16GB MEM) |
同左 |
Aurora |
-
|
11.16.3
12.11.5
13.7.3
14.5.0
|
PostgreSQL |
11.16
12.11
13.7
14.5
|
同左 |
autovacuum_vacuum_cost_limit |
1000 |
同左 |
autovacuum_vacuum_cost_delay |
5 |
同左 |
autovacuum_work_mem |
-1 (default)
-1 (default)
496191kB
496191kB
|
-1 (default)
-1 (default)
496191kB (default)
496191kB (default)
|
maintenance_work_mem |
260931kB (default)
260931kB (default)
254MB
254MB
|
254MB (default)
254MB (default)
254MB (default)
254MB (default)
|
各環境における autovacuum の処理時間は以下の結果となりました。
No. |
engine |
version |
elapsed[s] |
buffer usage |
read rate[MB/s] |
write rate[MB/s] |
||
---|---|---|---|---|---|---|---|---|
hits |
misses |
dirtied |
||||||
R-1 |
RDS for PostgreSQL |
11.16 |
77.70 |
667315 |
139654 |
529097 |
14.040 |
53.194 |
R-2 |
12.11 |
86.29 |
661441 |
140025 |
556627 |
12.677 |
50.392 |
|
R-3 |
13.7 |
41.63 |
630812 |
9673 |
110322 |
1.815 |
20.702 |
|
R-4 |
14.5 |
29.64 |
630922 |
9877 |
110700 |
2.603 |
29.170 |
|
A-1 |
Aurora PostgreSQL |
11.16.3 |
13.86 |
807658 |
0 |
0 |
0.000 |
0.000 |
A-2 |
12.11.5 |
14.02 |
802280 |
0 |
0 |
0.000 |
0.000 |
|
A-3 |
13.7.3 |
11.63 |
641298 |
0 |
0 |
0.000 |
0.000 |
|
A-4 |
14.5.0 |
10.91 |
641608 |
0 |
0 |
0.000 |
0.000 |
メジャーバージョンによる vacuum パフォーマンスの差異
バージョンの差異によるパフォーマンス変動の要素を排除するため、RDS for PostgreSQL と Aurora PostgreSQL において PostgreSQL の同一メジャーバージョンで測定を行いました。RDS for PostgreSQL と Aurora PostgreSQL において、メジャーバージョンの差異による autovacuum の性能差には同じ傾向が見られます (R-1 ~ R-4 と A-1 ~ A-4) が、同一メジャーバージョンでは Aurora PostgreSQL の方が autovacuum の性能が高い傾向 (R-1 と A-1、R-2 と A-2、R-3 と A-3、R-4 と A-4) がありました。そのため、PostgreSQL のバージョンによる性能差は考えられますが、それ以上に RDS for PostgreSQL と Aurora PostgreSQL のアーキテクチャの違いが大きく影響していると考えられます。
HW 性能の不均一性
ストレージのアーキテクチャーが RDS for PostgreSQL と Aurora PostgreSQL で異なるものの、コンピュート性能を合わせるために基本的にオンプレミスの PostgreSQL と同等を想定した RDS for PostgreSQL と Aurora PostgreSQL において同一インスタンスクラス (db.r5.large) で autovacuum の処理時間を測定しました。2018年度検証結果と比べ RDS for PostgreSQL の autovacuum の性能が高いため、2018年度検証環境と AWS での HW 性能が autovacuum の処理時間に影響していると考えられます。
DB パラメータの差異
DB パラメータの autovacuum_work_mem および maintenance_work_mem を RDS for PostgreSQL と Aurora PostgreSQL において基本的に同一に設定し、autovacuum の処理時間を計測しました。RDS for PostgreSQL 、Aurora PostgreSQL のバージョン12以下ではデフォルト値として変わりがなく、差異のあるバージョン13以上で RDS for PostgreSQL を Aurora に合わせましたが、特に両者の autovacuum 性能の傾向に差異はなく、パラメータの影響はない、もしくは小さいと考えられます。
Aurora PostgreSQL のアーキテクチャーの優位性
Community 版の PostgreSQL(2018年度検証相当) の場合、vacuum を実施する際に vacuum 自身がページを変更するため、ページを dirty とマークし、最終的にストレージに書き戻す必要があります。多くの dirty ページが発生する場合、vacuum のリングバッファが逼迫することが想定され、多くの dirty ページの書き戻しが発生していると考えられます。Aurora PostgreSQL の場合、チェックポイントを含め PostgreSQL のページイメージをストレージに書き込む処理が不要なアーキテクチャーのため dirty ページの書き戻しが不要です。autovacuum のログから書き込み量を比較すると RDS for PostgreSQL にはある程度の量の書き込みが確認できますが、Aurora PostgreSQL では書き込みが確認できません。そのため autovacuum の性能向上につながっていると考えられます。NOTE :また、Aurora PostgreSQL では visibility map を利用した vacuum の prefetch も Community 版の PostgreSQL より効率よく実施可能です。
項目 |
パラメータ |
関連する検証項目 |
---|---|---|
shared_preload_libraries |
auto_explain,pg_stat_statements |
No. 3 |
auto_explain.log_min_duration |
0 |
No. 3 |
log_lock_waits |
1 |
No. 26, 28 |
log_temp_files |
0 |
No. 30 |
Amazon RDS Performance Insights (以下、Performance Insights)
Amazon RDS 拡張モニタリング (以下、拡張モニタリング)
CloudWatch Logs (以下、CloudWatch Logs)
ただし、Performance Insights、拡張モニタリング、CloudWatch Logs へのログ出力には事前に以下の設定を行う必要があります。
Performance Insights の有効化
DBクラスターを作成時、または作成後に、Performance Insights を有効にすることができます。Performance Insights のデータ保持期間は、7日 (デフォルト)、1~24か月を指定することができます。Performance Insights を有効化または無効化した場合でも再起動は必要ありません。NOTE :暗号化方式は DB クラスター作成時のみ設定できます。
拡張モニタリングの有効化
DB クラスターを作成時、または作成後に、拡張モニタリングを有効にすることができます。モニタリング間隔は、1、5、10、15、30、60秒から選択でき、モニタリング用の IAM ロールを設定します。拡張モニタリングを有効化または無効化した場合でも再起動は必要ありません。
CloudWatch Logs へのログ出力
DBクラスターを作成時、または作成後に、CloudWatch Logs に PostgreSQL ログを定期的にエクスポートする設定を行います。CloudWatch Logs へのログ出力を有効化または無効化した場合でも再起動は必要ありません。
No |
性能情報 |
2018年度検証の確認事項 |
Aurora PostgreSQLでの確認方法 |
Aurora PostgreSQLでの確認方法詳細 |
メトリクス |
備考 |
---|---|---|---|---|---|---|
トランザクション数 |
確認用SQL :
pg_stat_databaseビューによる
トランザクションコミット数と
ロールバック数の確認
|
確認用SQL
(Performance Insights
でも一部確認可能)
|
2018年度検証のSQLを実行 |
- |
Performance Insightsではインスタンス全体の
トランザクション数は確認可能。
db.Transactions.xact_commit
db.Transactions.xact_rollback
|
|
SQLの統計情報 |
確認用SQL :
pg_stat_statmentによる
総実行時間と1回あたりの
実行時間が長いSQLの確認
|
Performance Insights |
Performance Insightsの
トップSQLで確認
|
- |
pg_stat_statementsのメトリクスは確認可能。
|
|
遅延SQL |
ログ確認 :
auto_explainによる
指定時間より遅延したSQLの
実行計画の確認
|
CloudWatch Logs |
shared_preload_librariesに
auto_explainを追加し、
auto_explain.log_min_durationで
閾値の処理時間を設定し、
CloudWatchのログから確認。
LOG、durationなどで検索。
|
- |
||
実行中のロング
トランザクションの確認
|
確認用SQL :
pg_stat_activityビューによる
実行中の長時間
トランザクションSQLの確認
|
確認用SQL
(Performance Insights
でも一部確認可能)
|
2018年度検証のSQLを実行 |
- |
・Performance Insightsでは以下のメトリクスが
確認可能。
db.Transactions.active_transactions:
アクティブなトランザクション数
db.Transactions.blocked_transactions:
行ロックの取得を待機しているトランザクション数
db.Transactions.duration_commits:
1分間の合計トランザクション時間
db.Transactions.commit_latency:
コミットの平均所要時間
db.State.idle_in_transaction_count:
トランザクション実行状態で
アイドル状態のセッション数
db.State.idle_in_transaction_aborted_count:
トランザクション 中止状態で
アイドル状態のセッション数
db.State.idle_in_transaction_max_time:
トランザクション実行状態で
アイドル状態にあるセッションの最大時間
・Performance Insightsにおいて
ある期間におけるAASやAAEの値から、
平均して長時間実行されている
クエリは確認可能。
|
|
VACUUMの実行状況 |
確認用SQL :
pg_stat_progress_vacuumビューによる
実行中の長時間VACUUMの確認
|
確認用SQL
(Performance Insights
でも一部確認可能)
|
2018年度検証のSQLを実行 |
- |
・Performance Insightsにおいて
ある期間におけるAASやAAEの値から、
平均して長時間実行されている
VACCUMに関連するクエリは確認可能。
|
|
CPU使用率 |
Linuxコマンド :
sarコマンドによる
CPU使用率の確認
|
Performance Insights |
Performance Insightsの
カウンターメトリクスで確認
|
os.cpuUtilization.user
os.cpuUtilization.nice
os.cpuUtilization.system
os.cpuUtilization.wait
os.cpuUtilization.total
|
||
メモリ使用率 |
Linuxコマンド :
sarコマンドによる
メモリ使用率の確認
|
Performance Insights |
Performance Insightsの
カウンターメトリクスで確認
|
os.memory.active
os.memory.inactive
os.memory.buffers
os.memory.cached
os.memory.free
os.memory.db.cache
|
||
スワップ発生率 |
Linuxコマンド :
sarコマンドによる
スワップ発生状況の確認
|
Performance Insights |
Performance Insightsの
カウンターメトリクスで確認
|
os.swap.in
os.swap.out
os.swap.free
os.swap.cached
|
||
ディスクI/O |
Linuxコマンド :
sarコマンドによる
ディスクI/O情報の確認
|
Performance Insights |
Performance Insightsの
カウンターメトリクスで確認
|
os.diskIO.auroraStorage.diskQueueDepth
os.diskIO.auroraStorage.readIOsPS
os.diskIO.auroraStorage.readLatency
os.diskIO.auroraStorage.readThroughput
os.diskIO.auroraStorage.writeIOsPS
os.diskIO.auroraStorage.writeLatency
os.diskIO.auroraStorage.writeThroughput
|
2018年度検証とは確認方法が異なるが、
I/O負荷は確認可能。
|
|
ネットワーク使用状況 |
Linuxコマンド :
sarコマンドによる
送受信データ量の確認
|
Performance Insights |
Performance Insightsの
カウンターメトリクスで確認
|
os.network.rx
os.network.tx
|
||
プロセスごとの
リソース使用率
|
Linuxコマンド :
topコマンドによる
プロセスのリソース状況の確認
|
拡張モニタリング
(Performance Insights
でも一部確認可能)
|
CloudWatch メトリクスで確認 |
processList.name
processList.cpuUsedPc
processList.memoryUsedPc
|
拡張モニタリングにおいて、プロセスごとの
disk I/Oは確認できない。
Performance InsightsではAAS/AAEが
確認できるため、リソースを
消費しているクエリは特定可能。
|
|
データベースサイズ |
確認用SQL :
pg_databaseカタログによる
データベースサイズの
顕著な増加の有無の確認
|
確認用SQL |
2018年度検証のSQLを実行 |
- |
||
テーブルサイズ |
確認用SQL :
pg_classカタログによる
インデックスサイズの
顕著な増加の有無の確認
|
確認用SQL |
2018年度検証のSQLを実行 |
- |
||
インデックスサイズ |
確認用SQL :
pg_classカタログによる
テーブルサイズの
顕著な増加の有無の確認
|
確認用SQL |
2018年度検証のSQLを実行 |
- |
||
テーブルスキャン時の
読み込み行数
|
確認用SQL :
pg_stat_user_tablesビューによる
シーケンシャルスキャンの
実行回数と平均行数の確認
|
確認用SQL |
2018年度検証のSQLを実行 |
- |
||
インデックススキャンの
割合
|
確認用SQL :
pg_stat_user_tablesビューによる
インデックススキャンの割合の確認
|
確認用SQL |
2018年度検証のSQLを実行 |
- |
||
テーブル毎の
不要領域確認
|
確認用SQL :
pg_stat_user_tablesビューによる
テーブル毎の不要行の割合の確認
|
確認用SQL |
2018年度検証のSQLを実行 |
- |
||
テーブル断片化 |
確認用SQL :
pgstattuple_approx関数による
無効タプルと空き領域の割合の確認
|
確認用SQL |
2018年度検証のSQLを実行 |
- |
CREATE EXTENSION pgstattuple;
の実行が必要。
|
|
インデックス断片化 |
確認用SQL :
pgstatindex関数による
リーフページの断片化の割合の確認
|
確認用SQL |
2018年度検証のSQLを実行 |
- |
||
データベース毎の
キャッシュヒット率
|
確認用SQL :
pg_stat_databaseビューによる
データベース毎の
キャッシュヒット率の確認
|
確認用SQL :
(Performance Insights
でも一部確認可能)
|
2018年度検証のSQLを実行 |
- |
Performance Insightsではインスタンス全体の
キャッシュヒット率は確認可能。
db.Cache.blks_hit
|
|
テーブル毎の
キャッシュヒット率
|
確認用SQL :
pg_statio_user_tablesビューによる
テーブル毎の
キャッシュヒット率の確認
|
確認用SQL |
2018年度検証のSQLを実行 |
- |
||
インデックス毎の
キャッシュヒット率
|
確認用SQL :
pg_statio_user_tablesビューによる
インデックス毎の
キャッシュヒット率の確認
|
確認用SQL |
2018年度検証のSQLを実行 |
- |
||
共有メモリ状況 |
確認用SQL :
pg_buffercacheビューによる
共有キャッシュ内の
バッファ数の確認
|
確認用SQL |
2018年度検証のSQLを実行 |
- |
CREATE EXTENSION pg_buffercache;
の実行が必要。
|
|
データベース毎の
同時接続数
|
確認用SQL :
pg_stat_activityビューによる
データベース毎の接続数の確認
|
確認用SQL :
(Performance Insights
でも一部確認可能)
|
2018年度検証のSQLを実行 |
- |
Performance Insightsではインスタンス全体の
同時接続数は確認可能。
db.User.numbackends
db.User.total_auth_attempts
|
|
ロック待ち状態 |
確認用SQL :
pg_locksビューによる
ロック待ち回数の確認
|
確認用SQL :
(Performance Insights
でも一部確認可能)
|
2018年度検証のSQLを実行 |
- |
Performance Insightsではインスタンス全体の
ロック待ちトランザクション数は確認可能。
db.Transactions.blocked_transactions
|
|
ロック待ちSQL |
ログ確認 :
log_lock_waitsによる
ロック待ちSQLの確認
|
Performance Insights
(CloudWatch Logs
でも確認可能)
|
Performance Insightsの
トップSQLで確認。
CloudWatch Logsで確認する場合
log_lock_waitsを有効化する必要がある。
|
- |
Performance Insightsでは、セッションの状態を
毎秒サンプリングしているため、
1秒未満の細かいロック状況を確認する場合は、
CloudWatchでのログ確認を検討してください。
|
|
デッドロック回数 |
確認用SQL :
pg_stat_databaseビューによる
デッドロック回数の確認
|
確認用SQL :
(Performance Insights
でも一部確認可能)
|
2018年度検証のSQLを実行 |
- |
Performance Insightsではインスタンス全体の
デッドロック回数は確認可能。
db.Concurrency.deadlocks
|
|
デッドロックSQL |
ログ確認 :
log_lock_waitsによる
デッドロックSQLの確認
|
Performance Insights
(CloudWatch Logs
でも確認可能)
|
Performance Insightsの
トップSQLで確認。
CloudWatch Logsで確認する場合
log_lock_waitsを有効化する必要がある。
|
- |
||
SQLによる
ディスクソートの処理回数
(work_memの不足回数)
|
確認用SQL :
pg_stat_databaseビューによる
SQLによって書き出された
一時ファイルの個数とデータ量の確認
|
確認用SQL :
(Performance Insights
でも一部確認可能)
|
2018年度検証のSQLを実行 |
- |
Performance Insightsではインスタンス全体の
一時ファイルへの書き込み回数と
データ量は確認可能。
db.Temp.temp_files
db.Temp.temp_bytes
|
|
ログメッセージの確認
(ディスクソート)
|
ログ確認 :
log_temp_filesによる
一時ファイルを作成したSQLの確認
|
CloudWatch Logs |
log_temp_filesで閾値の
一時ファイルサイズを設定し、
CloudWatch Logsで確認
|
- |
||
待機イベントの発生回数 |
確認用SQL :
pg_wait_sampling_profileビューによる
発生回数の多い待機イベントの確認
|
Performance Insights |
Performance Insightsの
トップSQLで確認
|
- |
Performance Insightsでは各待機イベントの
AAS/AAEを確認できるため、
各待機イベントの負荷状況が確認可能。
|
確認用SQL による確認方法
確認用SQL と同じ SQL を実行することで、データベース毎にトランザクションコミット数とロールバック数を確認できます。
Performance Insights による確認方法
Performance Insights による確認方法
Performance Insights から該当の DB インスタンスを選択後、負荷 (AAS) の高いクエリを表示するトップ SQL を確認することで、DB 負荷の高い SQL の統計情報を取得できます。NOTE :DB負荷指標のAASについては、 データベース負荷 を参照してください。
CloudWatch Logs による確認方法
確認用SQL による確認方法
確認用SQL と同じ SQL を実行することで、実行中の SQL を確認できます。
Performance Insights による確認方法
SQL の統計情報 の確認手順と同様、トップ SQL を確認することで、任意の期間に実行された SQL を確認できます。
確認用SQL による確認方法
確認用SQL と同じ SQL を実行することで、実行中の VACUUM に関する情報を確認できます。
Performance Insights による確認方法
SQL の統計情報 の確認手順と同様、トップ SQL を確認することで、任意の期間に実行された VACUUM に関する情報を確認できます。
Performance Insights による確認方法
トランザクション数 の確認手順と同様、以下のカウンターメトリクスを選択することで、CPU 使用率を確認できます。
os.cpuUtilization.user os.cpuUtilization.nice os.cpuUtilization.system os.cpuUtilization.wait os.cpuUtilization.total
Performance Insights による確認方法
トランザクション数 の確認手順と同様、以下のカウンターメトリクスを選択することで、メモリ使用率を確認できます。
os.memory.active os.memory.inactive os.memory.buffers os.memory.cached os.memory.free os.memory.db.cache
Performance Insights による確認方法
トランザクション数 の確認手順と同様、以下のカウンターメトリクスを選択することで、スワップ発生状況を確認できます。
os.swap.in os.swap.out os.swap.free os.swap.cached
Performance Insights による確認方法
トランザクション数 の確認手順と同様、以下のカウンターメトリクスを選択することで、ディスク I/O 情報を確認できます。
os.diskIO.auroraStorage.diskQueueDepth os.diskIO.auroraStorage.readIOsPS os.diskIO.auroraStorage.readLatency os.diskIO.auroraStorage.readThroughput os.diskIO.auroraStorage.writeIOsPS os.diskIO.auroraStorage.writeLatency os.diskIO.auroraStorage.writeThroughput
Performance Insights による確認方法
トランザクション数 の確認手順と同様、以下のカウンターメトリクスを選択することで、ネットワーク使用状況を確認できます。
os.network.rx os.network.tx
拡張モニタリングによる確認方法
Performance Insights による確認方法
SQL の統計情報 の確認手順と同様、トップ SQL を確認することで、リソースを消費しているクエリを特定することができます。
確認用SQL による確認方法
確認用SQL と同じ SQL を実行することで、データベース毎のサイズを確認できます。
確認用SQL による確認方法
確認用SQL と同じ SQL を実行することで、テーブル毎のサイズを確認できます。
確認用SQL による確認方法
確認用SQL と同じ SQL を実行することで、インデックス毎のサイズを確認できます。
確認用SQL による確認方法
確認用SQL と同じ SQL を実行することで、テーブルスキャン時の読み込み行数を確認できます。
確認用SQL による確認方法
確認用SQL と同じ SQL を実行することで、インデックススキャンの割合を確認できます。
確認用SQL による確認方法
確認用SQL と同じ SQL を実行することで、テーブル毎の不要領域を確認できます。
確認用SQL による確認方法
確認用SQL と同じ SQL を実行することで、テーブルの断片化情報を確認できます。
確認用SQL による確認方法
確認用SQL と同じ SQL を実行することで、インデックスの断片化情報を確認できます。
確認用SQL による確認方法
確認用SQL と同じ SQL を実行することで、データベース毎のキャッシュヒット率を確認できます。
Performance Insights による確認方法
トランザクション数 の確認手順と同様、以下のカウンターメトリクスを選択することで、DB インスタンス全体でのキャッシュヒット率を確認できます。
db.Cache.blks_hit
確認用SQL による確認方法
確認用SQL と同じ SQL を実行することで、テーブル毎のキャッシュヒット率を確認できます。
確認用SQL による確認方法
確認用SQL と同じ SQL を実行することで、インデックス毎のキャッシュヒット率を確認できます。
確認用SQL による確認方法
確認用SQL と同じ SQL を実行することで、共有バッファの状態を確認できます。
確認用SQL による確認方法
確認用SQL と同じ SQL を実行することで、データベース毎の同時接続数を確認できます。
Performance Insights による確認方法
トランザクション数 の確認手順と同様、以下のカウンターメトリクスを選択することで、DB インスタンス全体での同時接続数を確認できます。
db.User.numbackends db.User.total_auth_attempts
確認用SQL による確認方法
確認用SQL と同じ SQL を実行することで、ロック待ち状態を確認できます。
Performance Insights による確認方法
トランザクション数 の確認手順と同様、以下のカウンターメトリクスを選択することで、DB インスタンス全体でのロック待ちトランザクション数を確認できます。
db.Transactions.blocked_transactions
Performance Insights による確認方法
SQL の統計情報 の確認手順と同様、トップSQLを確認することで、ロック待ち SQL を特定することができます。
CloudWatch Logsによる確認方法
log_lock_waitsを有効化した場合、遅延 SQL の確認手順と同様、ログからロック待ち SQL の確認ができます。
確認用SQL による確認方法
確認用SQL と同じ SQL を実行することで、デッドロックの発生回数を確認できます。
Performance Insights による確認方法
トランザクション数 の確認手順と同様、以下のカウンターメトリクスを選択することで、DB インスタンス全体でのデッドロック回数を確認できます。
db.Concurrency.deadlocks
Performance Insights による確認方法
SQL の統計情報 の確認手順と同様、トップ SQL を確認することで、デッドロックが発生した SQL を特定することができます。
CloudWatch Logs による確認方法
log_lock_waits を有効化した場合、遅延 SQL の確認手順と同様、ログからデッドロックが発生した SQL の確認ができます。
確認用SQL による確認方法
確認用SQL と同じ SQL を実行することで、ディスクソートの発生情報を確認できます。
Performance Insights による確認方法
トランザクション数 の確認手順と同様、以下のカウンターメトリクスを選択することで、DB インスタンス全体の一時ファイルへの書き込み回数と書き込みデータ量を確認できます。
db.Temp.temp_files db.Temp.temp_bytes
CloudWatch Logs による確認方法
log_temp_files で閾値の一時ファイルサイズを設定した場合、遅延 SQL の確認手順と同様、ログから閾値以上のサイズの一時ファイルを作成した SQL の確認ができます。
Performance Insights による確認方法
SQL の統計情報 の確認手順と同様、トップ SQL を確認することで、待機イベント毎の負荷 (AAS) 状況と高負荷 SQL の確認ができます。
seq_page_cost (シーケンシャルスキャンアクセスのコスト) random_page_cost (ランダムアクセスのコスト)
従来のチューニング方法と比べた際に、QPM を用いたチューニング方法には以下の違いがあります。
アプリケーション (SQL 文) の修正を伴わない。
実行計画のバージョンを管理できる。 (アプリケーションが実行したクエリを全てキャプチャして管理することが可能)
統計情報変更等により生成された効率の良い実行計画の自動検出、確認、の固定化ができる。
実行計画の変更をすぐさま DB 全体に適用できる。
性能改善に関する実行計画の変更のみ適用できる。 (実行計画のコストのみで判断)
実行計画の取り込みと QPM の有効化は DB 再起動を伴わない。
RDS for PostgreSQLでは使用できない。
特定の SQL の実行計画が取得されない。
pg_class など、システムカタログを参照する SQL はキャプチャされない。
内部で使用される多数のシステカタログで生成される実行計画がキャプチャされないための仕様である。
システムカタログの内部ビューも当てはまる。
ワークロードによっては、より大きな DB インスタンスクラスが必要になる場合がある。
パラメータによっては DB 再起動を伴う。
QPM を使用できるデータベースの最大数
apg_plan_mgmt.dba_plans ビューで保持できる SQL の最大数
Aurora PostgreSQL のすべてのバージョンにおいて、パラメータを10000以上に設定することが推奨されている。
apg_plan_mgmt.plan_retention_period
apg_plan_mgmt.dba_plans ビューで実行計画を保持する日数
QPM のバージョン管理
QPMで利用する拡張機能のバージョンを、使用している Aurora PostgreSQL のバージョンの最新リリースに アップグレード することが推奨されている。
長期間使用されていない、または有用ではない 実行計画の削除 が推奨されている。
QPM による実行計画の管理を行っている対象クエリの整理が必要となる。
アプリケーション (SQL 文) の修正を伴わない利点がある反面、QPMから管理対象の SQL は確認できるが、アプリケーション (SQL 文) 側からはQPMの対象か判断できない。
QPMによる実行計画の固定化を行っていることを開発/保守担当者が把握していない場合、アプリケーション (SQL 文) 側でHINT句による実行計画の固定化を実施しても、実行計画が更新されない問題が発生する可能性がある。
QPM の管理対象を整理し、実行計画の更新などの運用を行う必要がある。
QPM の実施手順は以下になります。
DBパラメータを設定し、QPMを有効化します。
DBパラメータを設定し、実行計画の自動取得、または、手動取得の設定を行います。
DBパラメータを設定し、2. で取得した実行計画をオプティマイザが使用する設定を行います。
取得した実行計画の履歴を確認します。
実行計画の追加、維持、および改善を行います。
QPM の各種詳細な実施手順は以下を参照してください。
Aurora PostgreSQL のクエリ計画管理をオンにする を参照してください。
Aurora PostgreSQL 実行計画のキャプチャ を参照してください。
Aurora PostgreSQL 管理計画を使用する を参照してください。
dba_plans ビューで Aurora PostgreSQL クエリ計画を検証する を参照してください。
Aurora PostgreSQL 実行計画の管理 を参照してください。
項目 |
パラメータ |
---|---|
rds.enable_plan_management |
1 |
apg_plan_mgmt.capture_plan_baseline |
manual |
apg_plan_mgmt.use_plan_baselines |
true |
shared_preload_libraries |
pg_stat_statements,pg_hint_plan |
pg_hint_plan.debug_print |
on |
pg_hint_plan.enable_hint |
1 |
pg_hint_plan.enable_hint_table |
1 |
Amazon Aurora PostgreSQL でのクエリ計画管理のユースケース のユースケース#1, 2のシナリオで確認しました。
実行計画の固定化
1. クエリ実行計画を取り込みます。
db01=> SET apg_plan_mgmt.capture_plan_baselines = manual;
SET
2. EXPLAINによりクエリ実行を実行し、実行計画を確認します。
db01=> explain (hashes true)
db01-> SELECT Sum(delta),
db01-> Sum(bbalance)
db01-> FROM pgbench_history h,
db01-> pgbench_branches b
db01-> WHERE b.bid = h.bid
db01-> AND b.bid IN ( 1, 2, 3 )
db01-> AND mtime BETWEEN (SELECT Min(mtime)
db01(> FROM pgbench_history mn) AND (SELECT Max(mtime)
db01(> FROM pgbench_history mx);
QUERY PLAN
------------------------------------------------------------------------------------
Aggregate (cost=164.17..164.18 rows=1 width=16)
InitPlan 1 (returns $0)
-> Aggregate (cost=53.00..53.01 rows=1 width=8)
-> Seq Scan on pgbench_history mn (cost=0.00..49.00 rows=1600 width=8)
InitPlan 2 (returns $1)
-> Aggregate (cost=53.00..53.01 rows=1 width=8)
-> Seq Scan on pgbench_history mx (cost=0.00..49.00 rows=1600 width=8)
-> Nested Loop (cost=0.00..58.11 rows=8 width=8)
Join Filter: (h.bid = b.bid)
-> Seq Scan on pgbench_branches b (cost=0.00..1.01 rows=1 width=8)
Filter: (bid = ANY ('{1,2,3}'::integer[]))
-> Seq Scan on pgbench_history h (cost=0.00..57.00 rows=8 width=8)
Filter: ((mtime >= $0) AND (mtime <= $1))
SQL Hash: 1561242727, Plan Hash: 764058456
3. 実行計画取り込み後にクエリ実行計画の取り込みをOFFにします。
db01=> SET apg_plan_mgmt.capture_plan_baselines = off;
SET
4. 取得した実行計画を表示します。
db01=> SELECT sql_hash,
db01-> plan_hash,
db01-> status,
db01-> estimated_total_cost "cost",
db01-> sql_text
db01-> FROM apg_plan_mgmt.dba_plans;
sql_hash | plan_hash | status | cost | sql_text
------------+-----------+----------+-----------+--------------------------------------------------------------------------------------
1561242727 | 764058456 | Approved | 164.18375 | SELECT Sum(delta), +
| | | | Sum(bbalance) +
| | | | FROM pgbench_history h, +
| | | | pgbench_branches b +
| | | | WHERE b.bid = h.bid +
| | | | AND b.bid IN ( 1, 2, 3 ) +
| | | | AND mtime BETWEEN (SELECT Min(mtime) +
| | | | FROM pgbench_history mn) AND (SELECT Max(mtime) +
| | | | FROM pgbench_history mx);
5. QPMで取り込んだ承認済み実行計画を使用する設定に変更します。
db01=> SET apg_plan_mgmt.use_plan_baselines = true;
SET
6. EXPLAINによりクエリ実行を実行し、QPMで固定化した実行計画が採用されていることを確認します。
db01=> explain (hashes true)
db01-> SELECT Sum(delta),
db01-> Sum(bbalance)
db01-> FROM pgbench_history h,
db01-> pgbench_branches b
db01-> WHERE b.bid = h.bid
db01-> AND b.bid IN ( 1, 2, 3 )
db01-> AND mtime BETWEEN (SELECT Min(mtime)
db01(> FROM pgbench_history mn) AND (SELECT Max(mtime)
db01(> FROM pgbench_history mx);
QUERY PLAN
------------------------------------------------------------------------------------
Aggregate (cost=164.17..164.18 rows=1 width=16)
InitPlan 1 (returns $0)
-> Aggregate (cost=53.00..53.01 rows=1 width=8)
-> Seq Scan on pgbench_history mn (cost=0.00..49.00 rows=1600 width=8)
InitPlan 2 (returns $1)
-> Aggregate (cost=53.00..53.01 rows=1 width=8)
-> Seq Scan on pgbench_history mx (cost=0.00..49.00 rows=1600 width=8)
-> Nested Loop (cost=0.00..58.11 rows=8 width=8)
Join Filter: (h.bid = b.bid)
-> Seq Scan on pgbench_branches b (cost=0.00..1.01 rows=1 width=8)
Filter: (bid = ANY ('{1,2,3}'::integer[]))
-> Seq Scan on pgbench_history h (cost=0.00..57.00 rows=8 width=8)
Filter: ((mtime >= $0) AND (mtime <= $1))
SQL Hash: 1561242727, Plan Hash: 764058456
7. 新しい計画を生成するために、pgbench_historyテーブルの「mtime」列に新しいインデックスを作成します。
db01=> create index pgbench_hist_mtime on pgbench_history(mtime);
CREATE INDEX
8. EXPLAINによりクエリ実行を実行し、QPM が新しい計画を検出した場合でも、承認した実行計画を維持していることを確認します。
db01=> explain (hashes true)
db01-> SELECT Sum(delta),
db01-> Sum(bbalance)
db01-> FROM pgbench_history h,
db01-> pgbench_branches b
db01-> WHERE b.bid = h.bid
db01-> AND b.bid IN ( 1, 2, 3 )
db01-> AND mtime BETWEEN (SELECT Min(mtime)
db01(> FROM pgbench_history mn) AND (SELECT Max(mtime)
db01(> FROM pgbench_history mx);
QUERY PLAN
------------------------------------------------------------------------------------
Aggregate (cost=164.17..164.18 rows=1 width=16)
InitPlan 1 (returns $0)
-> Aggregate (cost=53.00..53.01 rows=1 width=8)
-> Seq Scan on pgbench_history mn (cost=0.00..49.00 rows=1600 width=8)
InitPlan 2 (returns $1)
-> Aggregate (cost=53.00..53.01 rows=1 width=8)
-> Seq Scan on pgbench_history mx (cost=0.00..49.00 rows=1600 width=8)
-> Nested Loop (cost=0.00..58.11 rows=8 width=8)
Join Filter: (h.bid = b.bid)
-> Seq Scan on pgbench_branches b (cost=0.00..1.01 rows=1 width=8)
Filter: (bid = ANY ('{1,2,3}'::integer[]))
-> Seq Scan on pgbench_history h (cost=0.00..57.00 rows=8 width=8)
Filter: ((mtime >= $0) AND (mtime <= $1))
Note: An Approved plan was used instead of the minimum cost plan.
SQL Hash: 1561242727, Plan Hash: 764058456, Minimum Cost Plan Hash: -433405076
9. 取得した実行計画を表示し、コストの低い実行計画が作成されているが、8. において承認された実行計画が採用されていることを確認します。
db01=> SELECT sql_hash,
db01-> plan_hash,
db01-> status,
db01-> estimated_total_cost "cost",
db01-> sql_text
db01-> FROM apg_plan_mgmt.dba_plans;
sql_hash | plan_hash | status | cost | sql_text
------------+------------+------------+------------------+--------------------------------------------------------------------------------------
1561242727 | 764058456 | Approved | 164.18375 | SELECT Sum(delta), +
| | | | Sum(bbalance) +
| | | | FROM pgbench_history h, +
| | | | pgbench_branches b +
| | | | WHERE b.bid = h.bid +
| | | | AND b.bid IN ( 1, 2, 3 ) +
| | | | AND mtime BETWEEN (SELECT Min(mtime) +
| | | | FROM pgbench_history mn) AND (SELECT Max(mtime) +
| | | | FROM pgbench_history mx);
1561242727 | -433405076 | Unapproved | 6.37206636451638 | SELECT Sum(delta), +
| | | | Sum(bbalance) +
| | | | FROM pgbench_history h, +
| | | | pgbench_branches b +
| | | | WHERE b.bid = h.bid +
| | | | AND b.bid IN ( 1, 2, 3 ) +
| | | | AND mtime BETWEEN (SELECT Min(mtime) +
| | | | FROM pgbench_history mn) AND (SELECT Max(mtime) +
| | | | FROM pgbench_history mx);
10. コストの低い実行計画を承認
db01=> SELECT apg_plan_mgmt.set_plan_status (1561242727, '-433405076', 'Approved');
set_plan_status
-----------------
0
(1 row)
11. 確認
db01=> SELECT sql_hash,
plan_hash,
status,
estimated_total_cost "cost",
sql_text
FROM apg_plan_mgmt.dba_plans;
sql_hash | plan_hash | status | cost | sql_text
------------+------------+----------+-----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------
1561242727 | 764058456 | Approved | 164.18375 | SELECT Sum(delta), +
| | | | Sum(bbalance) +
| | | | FROM pgbench_history h, +
| | | | pgbench_branches b +
| | | | WHERE b.bid = h.bid +
| | | | AND b.bid IN ( 1, 2, 3 ) +
| | | | AND mtime BETWEEN (SELECT Min(mtime) +
| | | | FROM pgbench_history mn) AND (SELECT Max(mtime) +
| | | | FROM pgbench_history mx);
1561242727 | -433405076 | Approved | 6.37 | SELECT Sum(delta), +
| | | | Sum(bbalance) +
| | | | FROM pgbench_history h, +
| | | | pgbench_branches b +
| | | | WHERE b.bid = h.bid +
| | | | AND b.bid IN ( 1, 2, 3 ) +
| | | | AND mtime BETWEEN (SELECT Min(mtime) +
| | | | FROM pgbench_history mn) AND (SELECT Max(mtime) +
| | | | FROM pgbench_history mx);
(2 rows)
12. クエリ実行
db01=> explain (hashes true)
db01-> SELECT Sum(delta),
db01-> Sum(bbalance)
db01-> FROM pgbench_history h,
db01-> pgbench_branches b
db01-> WHERE b.bid = h.bid
db01-> AND b.bid IN ( 1, 2, 3 )
db01-> AND mtime BETWEEN (SELECT Min(mtime)
db01(> FROM pgbench_history mn) AND (SELECT Max(mtime)
db01(> FROM pgbench_history mx);
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=6.36..6.37 rows=1 width=16)
InitPlan 2 (returns $1)
-> Result (cost=0.30..0.31 rows=1 width=8)
InitPlan 1 (returns $0)
-> Limit (cost=0.28..0.30 rows=1 width=8)
-> Index Only Scan using pgbench_hist_mtime on pgbench_history mn (cost=0.28..35.98 rows=1600 width=8)
Index Cond: (mtime IS NOT NULL)
InitPlan 4 (returns $3)
-> Result (cost=0.30..0.31 rows=1 width=8)
InitPlan 3 (returns $2)
-> Limit (cost=0.28..0.30 rows=1 width=8)
-> Index Only Scan Backward using pgbench_hist_mtime on pgbench_history mx (cost=0.28..35.98 rows=1600 width=8)
Index Cond: (mtime IS NOT NULL)
-> Nested Loop (cost=0.28..5.70 rows=8 width=8)
Join Filter: (h.bid = b.bid)
-> Seq Scan on pgbench_branches b (cost=0.00..1.01 rows=1 width=8)
Filter: (bid = ANY ('{1,2,3}'::integer[]))
-> Index Scan using pgbench_hist_mtime on pgbench_history h (cost=0.28..4.59 rows=8 width=8)
Index Cond: ((mtime >= $1) AND (mtime <= $3))
SQL Hash: 1561242727, Plan Hash: -433405076
(20 rows)
pg_hint_plan を使用した QPM による実行計画の修正
1. クエリ実行計画の取り込みをOFFにします。
db01=> SET apg_plan_mgmt.capture_plan_baselines = off;
SET
2. クエリを実行します。
db01=> EXPLAIN (hashes true)
db01-> SELECT
db01-> *
db01-> FROM
db01-> pgbench_branches b
db01-> JOIN
db01-> pgbench_accounts a
db01-> ON b.bid = a.bid
db01-> ORDER BY
db01-> a.aid;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------
Nested Loop (cost=0.59..785331.41 rows=9964671 width=461)
-> Index Scan using pgbench_accounts_pkey on pgbench_accounts a (cost=0.43..537663.60 rows=9964671 width=97)
-> Memoize (cost=0.15..0.17 rows=1 width=364)
Cache Key: a.bid
Cache Mode: logical
-> Index Scan using pgbench_branches_pkey on pgbench_branches b (cost=0.14..0.16 rows=1 width=364)
Index Cond: (bid = a.bid)
SQL Hash: 356104612, Plan Hash: 2119829930
3. 実行計画の取り込みむ設定に変更します。
db01=> SET apg_plan_mgmt.capture_plan_baselines = manual;
SET
4. ヒント句による実行計画の固定を行います。
db01=> /*+ HashJoin(a b) */ EXPLAIN (hashes true)
db01-> SELECT
db01-> *
db01-> FROM
db01-> pgbench_branches b
db01-> JOIN
db01-> pgbench_accounts a
db01-> ON b.bid = a.bid
db01-> ORDER BY
db01-> a.aid;
WARNING: transaction left non-empty SPI stack
HINT: Check for missing "SPI_finish" calls.
QUERY PLAN
---------------------------------------------------------------------------------------------------------
Gather Merge (cost=2359260.50..3328115.55 rows=8303892 width=461)
Workers Planned: 2
-> Sort (cost=2358260.48..2368640.34 rows=4151946 width=461)
Sort Key: a.aid
-> Hash Join (cost=3.25..380752.47 rows=4151946 width=461)
Hash Cond: (a.bid = b.bid)
-> Parallel Seq Scan on pgbench_accounts a (cost=0.00..369388.46 rows=4151946 width=97)
-> Hash (cost=2.00..2.00 rows=100 width=364)
-> Seq Scan on pgbench_branches b (cost=0.00..2.00 rows=100 width=364)
Note: This is not an Approved plan. No usable Approved plan was found.
SQL Hash: 356104612, Plan Hash: -58126597
5. 取得した実行計画を表示します。
db01=> SELECT sql_hash,
plan_hash,
status,
enabled,
sql_text
FROM apg_plan_mgmt.dba_plans
Where plan_hash='-58126597';
sql_hash | plan_hash | status | enabled | sql_text
-----------+-----------+------------+---------+---------------------------
356104612 | -58126597 | Unapproved | t | SELECT +
| | | | * +
| | | | FROM +
| | | | pgbench_branches b +
| | | | JOIN +
| | | | pgbench_accounts a +
| | | | ON b.bid = a.bid +
| | | | ORDER BY +
| | | | a.aid;
6. 同じSQL HASHの別の実行計画を除外し、ヒント句を用いた実行計画を承認します。
db01=> SELECT apg_plan_mgmt.set_plan_status (sql_hash, plan_hash, 'Rejected') from apg_plan_mgmt.dba_plans where sql_hash = 356104612;
set_plan_status
-----------------
0
0
db01=> SELECT apg_plan_mgmt.set_plan_status (356104612, '-58126597', 'Approved');
set_plan_status
-----------------
0
7. 実行計画の取り込みをOFFにし、QPMで取り込んだ承認済み実行計画を使用する設定に変更します。
db01=> SET apg_plan_mgmt.capture_plan_baselines = off;
SET
db01=> SET apg_plan_mgmt.use_plan_baselines = true;
SET
8. ヒント句なしでクエリを実行しても、ヒント句で指定した実行計画が採用されていることを確認します。
db01=> EXPLAIN (hashes true)
db01-> SELECT
db01-> *
db01-> FROM
db01-> pgbench_branches b
db01-> JOIN
db01-> pgbench_accounts a
db01-> ON b.bid = a.bid
db01-> ORDER BY
db01-> a.aid;
QUERY PLAN
---------------------------------------------------------------------------------------------------------
Gather Merge (cost=2359260.50..3328115.55 rows=8303892 width=461)
Workers Planned: 2
-> Sort (cost=2358260.48..2368640.34 rows=4151946 width=461)
Sort Key: a.aid
-> Hash Join (cost=3.25..380752.47 rows=4151946 width=461)
Hash Cond: (a.bid = b.bid)
-> Parallel Seq Scan on pgbench_accounts a (cost=0.00..369388.46 rows=4151946 width=97)
-> Hash (cost=2.00..2.00 rows=100 width=364)
-> Seq Scan on pgbench_branches b (cost=0.00..2.00 rows=100 width=364)
Note: An Approved plan was used instead of the minimum cost plan.
SQL Hash: 356104612, Plan Hash: -58126597, Minimum Cost Plan Hash: 2119829930
9. もともと取り込まれていた実行計画が採用されず、ヒント句で指定した実行計画が承認されています。
db01=> SELECT sql_hash,
plan_hash,
status,
enabled,
sql_text
FROM apg_plan_mgmt.dba_plans
Where sql_hash=356104612;
sql_hash | plan_hash | status | enabled | sql_text
-----------+------------+----------+---------+---------------------------
356104612 | -58126597 | Approved | t | SELECT +
| | | | * +
| | | | FROM +
| | | | pgbench_branches b +
| | | | JOIN +
| | | | pgbench_accounts a +
| | | | ON b.bid = a.bid +
| | | | ORDER BY +
| | | | a.aid;
356104612 | 2119829930 | Rejected | t | SELECT +
| | | | * +
| | | | FROM +
| | | | pgbench_branches b +
| | | | JOIN +
| | | | pgbench_accounts a +
| | | | ON b.bid = a.bid +
| | | | ORDER BY +
| | | | a.aid;
版 |
所属企業・団体名 |
部署名 |
氏名 |
---|---|---|---|
1.0 |
日鉄ソリューションズ株式会社 |
アドバンストテクノロジー部 |
永井 光
秋山 暉佳
|