log_autovacuum_min_duration = -1 # -1 disables, 0 logs all actions and # their durations, > 0 logs only # actions running at least this number # of milliseconds.
PHP/Perlをちょろっと書く程度しかできなかったウェブエンジニアの端くれの私が、経験したトラブルとそこで 4ヵ月もかかって身に着けたこと を紹介します。 PostgreSQLが重い！ とにかくWebサイトが重い。 .htmlのページはすぐ表示されるんだけど、.phpのページがやたらと重い。 目的 特定時間にサイトパフォーマンスが落ちてしまう事を防止したい 実際にはサイトレスポンスが異様に遅い事がありログを見たところ autovacuumが実施されていたケースが多いかと思います。 環境 EC2インスタンスより pgbenchを実行 RDS PostgreSQL 設定項目 値 DBインスタンス pgsql-test.xxxxx.ap-northeast-1.rds VACUUM/自動バキューム pg_stat_user_tables SELECT last_vacuum, last_autovacuum, n_dead_tup FROM pg_stat_user_tables; - last_vacuum, last_autovacuum でVACUUM, 自動VACUUMがいつ実行されたか、n_dead_tupで不要なタプルが何行削除されたか; pg_stat_user_tables PostgreSQLのDBで運用しているシステムで、特定のファイルのアクセスだけ極端に遅くなります。 select * from tbl where tbl_seri='1'; のような処理が、最初は3ms程度ですが、12時間 vacuum をなんとなくでするのはやめよう.
autovacuum_max_workers = 3 # max number of autovacuum subprocesses # (change requires restart) autovacuum_naptime = 1min # time between autovacuum runs autovacuum_vacuum_threshold = 50 … そうなる前に postgresql 好きの皆さんは vacuum を実行してパフォーマンスをあげたいなと思いますよね？ でも、ちょっと待って！ あなたが vacuum を実行するその時、それが vacuum のタイミングなのでしょうか？ vacuum 前にチェック！ 不要領域はどれぐらいあるの？ この状態で [postgres@db1 NewDB] $ time pgbench -c 10-t 10 hogehoge starting vacuum...end. PostgreSQLのチューニングには、postgres.confで設定値を変更する方法や、定期的にVACUUMする方法などがあるらしい。 今回作ったシステムは、参照よりも更新レコード数が多い場合なので、一日一回VACUUM、REINDEXするという方法が効果的だった。
PostgreSQLの運用において、比較的遭遇しやすいトラブルとその代表的な対策を表にまとめました。 ... また、遅い SQL ... 特に、VACUUM時に大量のアーカイブログが生成されることがあり、このような際はディスクフルになりやすいです。 vacuum fullでは不要領域回収後にデータファイルを縮小します。 vacuum fullでは実行時に排他ロックが取得されます。 そのため、実行が終了するまで対象テーブルの読み書きは待たされます。 また、vacuumと比較して実行に時間がかかります。 1テーブルのvacuum full transaction type: TPC-B (sort of) scaling factor: 1 number of clients: 10 number of transactions per client: 10 number of transactions actually processed: 100 / 100 tps = 57.874423 (including connections establishing) tps = 111.933324 (excluding connections establishing) real 0m1.798s user 0m0.012s sys 0m0.024s 追記型のRBDであるPostgreSQLにはautovacuum（オートバキューム）という便利な機能があり、updateやdeleteなどで不要な領域が一定の割合に達すると、自動で不要な領域を掃除してくれます。 その閾値はautovacuum_vacuum_scale_factorとautovacuum_vacuum postgresql.confの設定 log_statement = true. [postgres@db1 NewDB] $ time pgbench -c 10-t 10 hogehoge starting vacuum...end.
vacuumを全く実行しない場合、ファイルサイズが増え続け、パフォーマンスの低下、ディスクスペースの圧迫へとつながります。 auto vacuum機能. 'on' # requires track_counts to also be on. vacuum fullでは不要領域回収後にデータファイルを縮小します。 vacuum fullでは実行時に排他ロックが取得されます。 そのため、実行が終了するまで対象テーブルの読み書きは待たされます。 また、vacuumと比較して実行に時間がかかります。 1テーブルのvacuum full 如何でしたでしょうか？ 不要領域を回収するから、パフォーマンスが回復するからという理由で漫然と行なってきた vacuum。 これからは vacuum を実行する前に、デッドタプルがあるか確認してください。 postgresqlには「auto vacuum」機能が搭載されており、自動で随時vacuumが実行されるため、多くの場合問題となりません。