Re: Ineffective autovacuum
От | Marti Raudsepp |
---|---|
Тема | Re: Ineffective autovacuum |
Дата | |
Msg-id | CABRT9RC2BB6Y8QO9O7PwPYrbjCB6EsK4F-uh-uJ=vArwC=j8MA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Ineffective autovacuum (Royce Ausburn <royce.ml@inomial.com>) |
Ответы |
Re: Ineffective autovacuum
|
Список | pgsql-performance |
1. First things first: vacuum cannot delete tuples that are still visible to any old running transactions. You might have some very long queries or transactions that prevent it from cleaning properly: select * from pg_stat_activity where xact_start < now()-interval '10 minutes'; 2. On 8.3 and earlier servers with large tables, it's critical that your max_fsm_pages and max_fsm_relations are tuned properly. Failing that, autovacuum will permanently leak space that can only be fixed with a VACUUM FULL (which will take an exclusive lock and run for a very long time) PostgreSQL version 8.4 addressed this problem, but for the unfortunate, you have to follow the tuning advice here: https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server#autovacuum_max_fsm_pages.2C_max_fsm_relations On Tue, Sep 27, 2011 at 08:08, Royce Ausburn <royce.ml@inomial.com> wrote: > I've noticed that the same tables seem to be auto vacuum'd over and over again… Some of the tables are a bit surprisingin that they're updated semi-regularly, but not enough (I'd think) to warrant an autovacuum every few minutes…Is this unusual? Maybe they're just auto-analyze processes? Those get triggered on insert-only tables too, when vacuum normally wouldn't run. > Perhaps unrelated: I've done some digging around and happened across a nightly task doing: > select pg_stat_reset() AFAIK (but I could be wrong), vacuum uses a separate set of statistics not affected by pg_stat_reset. Regards, Marti
В списке pgsql-performance по дате отправления: