私はレコードを一度に一度作成したテーブルを持っていますが、毎にレコードが更新されます(更新される順序と更新のタイミングはランダムです)。アップデートはHOTアップデートではありません。これらの事実を考慮して、このテーブルのフィラーファクタを50、または50未満に設定することに利点はありますか?Postgres:fillfactorを50に設定しますか?
答えて
質問にお答えしたとおり、各トランザクションで1〜10kのレコードを更新するトランザクションを使用して、テーブルに変更を加えています。これは、オートバキュウムの仕事をするためにいくつかのチャンスを残す正しいアプローチです。しかし、テーブルのfillfactor
は私がチェック/変更する最初のものではありません。 Fillfactorはプロセスをスピードアップするのに役立ちますが、自動バキュームが十分に攻撃的でない場合は、すぐに非常に肥大したテーブルと悪いパフォーマンスが発生します。
最初に、私はあなたのテーブルのbloatingレベルを制御することをお勧めしたいと思います。あなたを助けることができるクエリの数があります:
- https://wiki.postgresql.org/wiki/Show_database_bloat
- http://blog.ioguix.net/postgresql/2014/09/10/Bloat-estimation-for-tables.html
- https://github.com/ioguix/pgsql-bloat-estimation/blob/master/table/table_bloat-82-84.sql
- https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat.sql (および索引の:
- https://github.com/dataegret/pg-utils/blob/master/sql/index_bloat.sql; これらのクエリはpgstattuple延長を必要とする)
次に、自動バキュームをデフォルトよりもはるかに積極的な状態に調整したいと思います(短時間でテーブル全体を処理する必要がなくてもよい)。
log_autovacuum_min_duration = 0
autovacuum_vacuum_scale_factor = 0.01
autovacuum_analyze_scale_factor = 0.05
autovacuum_naptime = 60
autovacuum_vacuum_cost_delay = 20
UPDATEとのトランザクションのかなりの数の後、bloatingレベルを確認します。
最後に、fillfactorを調整しますが、おそらく80または90のようなより高い(通常の)値に調整します。ここでは、予測を行う必要があります。ページ内の10%以上のタプル1回の取引で更新されますか?チャンスが非常に高い場合は、fillfactorを減らしてください。しかし、UPDATEの行の順序はランダムなので、80〜90%を使用すると述べました。 fillfactorを50に設定すると、テーブルに2倍のディスク容量が必要になり、すべての操作が自然に遅くなることに注意してください。この質問に深くいきたいのであれば、fillfactors 50..100で同じデータを持つ21個のテーブルを作成し、pgbenchを使ってUPDATE TPSをテストすることをお勧めします。
ありがとう、これは本当に思慮深い答えです。 fillfactorをどう考えるべきかについて私の根底にある疑問があり、私の根本的な問題に取り組む方法を提案します。 – carbocation
1回のトランザクションで「すべてのレコードが更新されますか?そうであれば、設定に関係なく、自動バキュームは満足できません。 – Nick
3,000万行のテーブルです。すべてのレコードは、約1,000〜10,000レコード(時)の間のトランザクションで更新され、1レコードのトランザクションサイズ(時には)で完全にランダムに更新されます。 – carbocation