はじめに

AuroraやRDSはマネージド・サービスなので、パラメータチューニングが不要だが、要件や性能問題次第ではチューニングの必要があるのでそれをまとめたい。

変更を検討するパラメータ一覧

気付いたら都度追加していく。現在のパラメータ(setting列)は、Aurora、RDS共にr5.largeのインスタンスタイプから抽出

変更を検討するパラメータと書きつつ、AuroraとRDSで変更可能なパラメータも異なり、変更できないものもあるので注意。checkpoint_timeout等はチェックポイントチューニングでいじるところではあるが、RDSは変更出来て、Auroraでは変更出来ない模様。

RDSとAurora PostgreSQLで変更不可なパラメータ一覧 | my opinion is my own https://zatoima.github.io/aws-aurora-rds-postgresql-parameter-modifiable.html

抽出用SQL

SELECT
    name,
    setting,
    boot_val,
    unit,
    context
FROM
    pg_settings
WHERE
    name IN ('max_connections','superuser_reserved_connections','lc_messages','archive_timeout','log_filename','log_rotation_age','log_rotation_size','log_min_duration_statement','log_hostname','log_timezone','shared_buffers','effective_io_concurrency','max_worker_processes','max_parallel_maintenance_workers','max_parallel_workers_per_gather','max_parallel_workers','wal_buffers','checkpoint_timeout','checkpoint_completion_target','random_page_cost','autovacuum_max_workers','deadlock_timeout')
ORDER BY 1;

パラメータ個別メモ

deadlock_timeout

デッドロックの検査は負荷が高いので、デフォルトの1000ms(1秒)より上げても良い。

checkpoint_completion_target

checkpoint_timeout

AuroraとRDSでデフォルトの設定値が異なる。パフォーマンス問題が発生した場合に変更する方向。

※Auroraはチェックポイント自体の概念が無く、log_bufferに入ってきたメモリは都度ストレージ側に流れていくはずなので、変更の意味があるかは不明。

PostgreSQLのcheckpoint_completion_targetについてメモ | my opinion is my own https://zatoima.github.io/postgresql-about-checkpoint_completion_target.html

log_filename

log_hostname

log_min_duration_statement

log_rotation_age

log_rotation_size

log_timezone

ログ要件に応じて変更

max_connections

OSS版のPostgreSQLの100と比較するとパラメータは調整されているが、コネクション数自体は要件次第。インスタンスタイプをスケールアップするとmax_connectionsも一緒に上がっていく。

autovacuum_max_workers

max_parallel_maintenance_workers

max_parallel_workers

max_parallel_workers_per_gather

max_worker_processes

VacuumやAnalyzeのチューニング時に微調整

shared_buffers

Auroraの場合は、DB パラメータグループでのデフォルト値は全メモリの75%に設定される。これは、Aurora PostgreSQLがダブルバッファリングを使用しておらず、OS側のファイルシステムキャッシュが必要ないため。他のメモリ系パラメータに振った方が良ければ微調整。

Shared_Buffers DB パラメータのデフォルト値と Amazon RDS PostgreSQL および Aurora PostgreSQL の間に差がある理由を理解する https://aws.amazon.com/jp/premiumsupport/knowledge-center/rds-aurora-postgresql-shared-buffers/

wal_buffers

未だディスクに書き込まれていないWALデータに対して使用される共有メモリ容量。commit時にこのバッファからディスクに書き込まれる。書き込みが多く、CPUが多い場合は数MBに拡張することで効果は得られるが、Aurora、RDS共に基本的にはデフォルト値で問題無さそう。

random_page_cost

非シーケンシャル的に取り出されるディスクページのコストに対するプランナの推測を設定。この値を小さくすることで相対的にインデックススキャンを行うことになる。一般的にランダムリードに関してはHDDよりSDDの方が早いので、SSDの場合は1.0等に設定することもある。場合によってはデフォルトの4.0より下げても良いかも。

インスタンスタイプのスケールアップで変わるパラメータは？

上記のパラメータを対象に何が変わるのか調べてみた。max_connectionsやshared_buffersは変更される。一方でCPU、メモリが増えているにも関わらず、パラレル度の指定やwal_buffers等には変更がない。

参考

PostgresqlCO.NF：人間のためのPostgreSQLの設定 https://postgresqlco.nf/doc/ja/param/

PostgreSQL11 設定パラメーター解体新書 / PostgreSQL 11 parameter - Speaker Deck https://speakerdeck.com/ester41/postgresql-11-parameter?slide=2

PostgreSQL安定運用のための障害予防と検知 https://www.ospn.jp/osc2014.enterprise/pdf/OSC2014_Enterprise_hp.pdf

PostgreSQL のパフォーマンスチューニング - Qiita https://qiita.com/cuzic/items/f9b846e6171a54079d77

Oracle データベースを Amazon RDS PostgreSQL または Amazon Aurora PostgreSQL に移行する上でのベスト プラクティス: PostgreSQL 環境のターゲット データベースに関する考慮事項 | Amazon Web Services ブログ https://aws.amazon.com/jp/blogs/news/best-practices-for-migrating-an-oracle-database-to-amazon-rds-postgresql-or-amazon-aurora-postgresql-target-database-considerations-for-the-postgresql-environment/