postgresql关于auto vacuum
If autovacuum is set, then autovacuum will wake up every autovacuum_naptime seconds, and
decide whether to run VACUUM and/or ANALYZE commands.
There will never be more than autovacuum_max_workers maintenance processes running
at any one time. As these autovacuum slaves perform I/O, they accumulate cost points,
until they hit the autovacuum_vacuum_cost_limit, after which they sleep for autovacuum_
vacuum_cost_delay. This is designed to throttle the resource utilization of autovacuum to
prevent it from using all available disk performance, which it should never do. So, increasing
autovacuum_vacuum_cost_delay will slow down each VACUUM to reduce the impact on
user activity. Autovacuum will run an ANALYZE command when there have been at least
autovacuum_analyze_threshold changes, and a fraction of the table defined by autovacuum_
analyze_scale_factor has been inserted, updated, or deleted.
Autovacuum will run a VACUUM command when there have been at least autovacuum_vacuum_
threshold changes, and a fraction of the table defined by autovacuum_vacuum_scale_factor has
been updated or deleted.
If you set log_autovacuum_min_duration, then any autovacuum that runs for longer than this
value will be logged to the server log, like the following:
2010-04-29 01:33:55 BST (13130) LOG: automatic vacuum of table
"postgres.public.pgbench_accounts": index scans: 1
pages: 0 removed, 3279 remain
tuples: 100000 removed, 100000 remain
system usage: CPU 0.19s/0.36u sec elapsed 19.01 sec
2010-04-29 01:33:59 BST (13130) LOG: automatic analyze of table
"postgres.public.pgbench_accounts"
system usage: CPU 0.06s/0.18u sec elapsed 3.66 sec
Most of the preceding global parameters can also be set at the table level. For example, if you
think that you don't want a table to be autovacuumed, then you can set:
ALTER TABLE big_table SET (autovacuum_enabled = off);
It's also possible to set parameters for toast tables. The toast table is the location where
oversize column values get placed, which the documents refer to as "supplementary storage
tables". If there are no oversize values, then the toast table will occupy little space. Tables with
very wide values often have large toast tables. Toast (stands for the oversize attribute storage
technique) is optimized for UPDATE. If you have a heavily updated table, the toast table is
untouched, so it may makes sense to turn off autovacuuming of the toast table as follows:
ALTER TABLE pgbench_accounts
SET ( autovacuum_vacuum_cost_delay = 20
,toast.autovacuum_enabled = off);
which will turn off autovacuuming of the "toast" table.
Note that autovacuuming of the toast table is performed completely separately from the main
table, even though you can't ask for an explicit include/exclude of the toast table yourself
when running VACUUM.
Use the following query to display the reloptions for tables and their toast tables:
postgres=# SELECT n.nspname, c.relname,
pg_catalog.array_to_string(c.reloptions || array(
select 'toast.' ||
x from pg_catalog.unnest(tc.reloptions) x),', ')
as relopts
FROM pg_catalog.pg_class c
LEFT JOIN
pg_catalog.pg_class tc ON (c.reltoastrelid = tc.oid) JOIN
pg_namespace n ON c.relnamespace = n.oid
WHERE c.relkind = 'r'
AND nspname NOT IN ('pg_catalog', 'information_schema');
nspname | relname | relopts
---------+------------------+------------------------------
public | pgbench_accounts | fillfactor=100,
autovacuum_enabled=on,
autovacuum_vacuum_cost_delay=20
public | pgbench_tellers | fillfactor=100
public | pgbench_branches | fillfactor=100
public | pgbench_history |
public | text_archive | toast.autovacuum_enabled=off
VACUUM allows inserts, updates, and deletes while it runs, though it prevents actions such as
ALTER TABLE and CREATE INDEX. Autovacuum can detect if a user requests a conflicting
lock on the table while it runs, and will cancel itself if it is getting in the user's way.
Note that VACUUM does not shrink a table when it runs, unless there is a large run of space
at the end of a table, and nobody is accessing the table when we try to shrink it. To properly
shrink a table, you need VACUUM FULL. That locks up the whole table for a long time, and
should be avoided, if possible. VACUUM FULL will literally rewrite every row of the table, and
completely rebuild all indexes. That process is faster in 9.0 than it used to be, though it's still a
long time for larger tables.
Regular Maintenance
There's more...
postgresql.conf also allows "include directives", which look like the following:
include 'autovacuum.conf'
These specify another file that will be read at that point, just as if those parameters had been
included in the main file.
This can be used to maintain multiple sets of files for autovacuum configuration. Let's say
we have a website that is busy, mainly during the daytime, with some occasional night time
use. We decide to have two profiles, one for daytime, when we want only less aggressive
autovacuuming, and another at night, where we allow more aggressive vacuuming.
We add the following lines to postgresql.conf:
ff autovacuum = on
ff autovacuum_max_workers = 3
ff include 'autovacuum.conf'
and remove all other autovacuum parameters.
We then create one file named autovacuum.conf.day, containing the following parameters:
ff autovacuum_analyze_scale_factor = 0.1
ff autovacuum_analyze_threshold = 50
ff autovacuum_vacuum_cost_delay = 30
ff autovacuum_vacuum_cost_limit = -1
ff autovacuum_vacuum_scale_factor = 0.2
ff autovacuum_vacuum_threshold = 50
and another file named autovacuum.conf.night, that contains the following parameters:
ff autovacuum_analyze_scale_factor = 0.05
ff autovacuum_analyze_threshold = 50
ff autovacuum_vacuum_cost_delay = 10
ff autovacuum_vacuum_cost_limit = -1
ff autovacuum_vacuum_scale_factor = 0.1
ff autovacuum_vacuum_threshold = 50
To swap profiles, we would simply do the following actions:
$ ln -sf autovacuum.conf.night autovacuum.conf
$ pg_ctl -D datadir reload # server reload command
(customized depending upon your platform).
This then allows us to switch profiles twice per day without needing to edit the configuration
files. You can also tell easily which is the active profile simply by looking at the full details of
the linked file (using ls –l). The exact details of the schedule are up to you; night/day was just
an example, which is unlikely to suit everybody.
decide whether to run VACUUM and/or ANALYZE commands.
There will never be more than autovacuum_max_workers maintenance processes running
at any one time. As these autovacuum slaves perform I/O, they accumulate cost points,
until they hit the autovacuum_vacuum_cost_limit, after which they sleep for autovacuum_
vacuum_cost_delay. This is designed to throttle the resource utilization of autovacuum to
prevent it from using all available disk performance, which it should never do. So, increasing
autovacuum_vacuum_cost_delay will slow down each VACUUM to reduce the impact on
user activity. Autovacuum will run an ANALYZE command when there have been at least
autovacuum_analyze_threshold changes, and a fraction of the table defined by autovacuum_
analyze_scale_factor has been inserted, updated, or deleted.
Autovacuum will run a VACUUM command when there have been at least autovacuum_vacuum_
threshold changes, and a fraction of the table defined by autovacuum_vacuum_scale_factor has
been updated or deleted.
If you set log_autovacuum_min_duration, then any autovacuum that runs for longer than this
value will be logged to the server log, like the following:
2010-04-29 01:33:55 BST (13130) LOG: automatic vacuum of table
"postgres.public.pgbench_accounts": index scans: 1
pages: 0 removed, 3279 remain
tuples: 100000 removed, 100000 remain
system usage: CPU 0.19s/0.36u sec elapsed 19.01 sec
2010-04-29 01:33:59 BST (13130) LOG: automatic analyze of table
"postgres.public.pgbench_accounts"
system usage: CPU 0.06s/0.18u sec elapsed 3.66 sec
Most of the preceding global parameters can also be set at the table level. For example, if you
think that you don't want a table to be autovacuumed, then you can set:
ALTER TABLE big_table SET (autovacuum_enabled = off);
It's also possible to set parameters for toast tables. The toast table is the location where
oversize column values get placed, which the documents refer to as "supplementary storage
tables". If there are no oversize values, then the toast table will occupy little space. Tables with
very wide values often have large toast tables. Toast (stands for the oversize attribute storage
technique) is optimized for UPDATE. If you have a heavily updated table, the toast table is
untouched, so it may makes sense to turn off autovacuuming of the toast table as follows:
ALTER TABLE pgbench_accounts
SET ( autovacuum_vacuum_cost_delay = 20
,toast.autovacuum_enabled = off);
which will turn off autovacuuming of the "toast" table.
Note that autovacuuming of the toast table is performed completely separately from the main
table, even though you can't ask for an explicit include/exclude of the toast table yourself
when running VACUUM.
Use the following query to display the reloptions for tables and their toast tables:
postgres=# SELECT n.nspname, c.relname,
pg_catalog.array_to_string(c.reloptions || array(
select 'toast.' ||
x from pg_catalog.unnest(tc.reloptions) x),', ')
as relopts
FROM pg_catalog.pg_class c
LEFT JOIN
pg_catalog.pg_class tc ON (c.reltoastrelid = tc.oid) JOIN
pg_namespace n ON c.relnamespace = n.oid
WHERE c.relkind = 'r'
AND nspname NOT IN ('pg_catalog', 'information_schema');
nspname | relname | relopts
---------+------------------+------------------------------
public | pgbench_accounts | fillfactor=100,
autovacuum_enabled=on,
autovacuum_vacuum_cost_delay=20
public | pgbench_tellers | fillfactor=100
public | pgbench_branches | fillfactor=100
public | pgbench_history |
public | text_archive | toast.autovacuum_enabled=off
VACUUM allows inserts, updates, and deletes while it runs, though it prevents actions such as
ALTER TABLE and CREATE INDEX. Autovacuum can detect if a user requests a conflicting
lock on the table while it runs, and will cancel itself if it is getting in the user's way.
Note that VACUUM does not shrink a table when it runs, unless there is a large run of space
at the end of a table, and nobody is accessing the table when we try to shrink it. To properly
shrink a table, you need VACUUM FULL. That locks up the whole table for a long time, and
should be avoided, if possible. VACUUM FULL will literally rewrite every row of the table, and
completely rebuild all indexes. That process is faster in 9.0 than it used to be, though it's still a
long time for larger tables.
Regular Maintenance
There's more...
postgresql.conf also allows "include directives", which look like the following:
include 'autovacuum.conf'
These specify another file that will be read at that point, just as if those parameters had been
included in the main file.
This can be used to maintain multiple sets of files for autovacuum configuration. Let's say
we have a website that is busy, mainly during the daytime, with some occasional night time
use. We decide to have two profiles, one for daytime, when we want only less aggressive
autovacuuming, and another at night, where we allow more aggressive vacuuming.
We add the following lines to postgresql.conf:
ff autovacuum = on
ff autovacuum_max_workers = 3
ff include 'autovacuum.conf'
and remove all other autovacuum parameters.
We then create one file named autovacuum.conf.day, containing the following parameters:
ff autovacuum_analyze_scale_factor = 0.1
ff autovacuum_analyze_threshold = 50
ff autovacuum_vacuum_cost_delay = 30
ff autovacuum_vacuum_cost_limit = -1
ff autovacuum_vacuum_scale_factor = 0.2
ff autovacuum_vacuum_threshold = 50
and another file named autovacuum.conf.night, that contains the following parameters:
ff autovacuum_analyze_scale_factor = 0.05
ff autovacuum_analyze_threshold = 50
ff autovacuum_vacuum_cost_delay = 10
ff autovacuum_vacuum_cost_limit = -1
ff autovacuum_vacuum_scale_factor = 0.1
ff autovacuum_vacuum_threshold = 50
To swap profiles, we would simply do the following actions:
$ ln -sf autovacuum.conf.night autovacuum.conf
$ pg_ctl -D datadir reload # server reload command
(customized depending upon your platform).
This then allows us to switch profiles twice per day without needing to edit the configuration
files. You can also tell easily which is the active profile simply by looking at the full details of
the linked file (using ls –l). The exact details of the schedule are up to you; night/day was just
an example, which is unlikely to suit everybody.