Postgresql 9.3 Autovacuum не поспевает, несмотря на агрессивные настройки - PullRequest
0 голосов
/ 12 мая 2018

Попытка заставить Postgresql поддерживать чистоту таблиц, однако, даже после настройки ограничений ресурсов, кажется, что он почти не идет в ногу.

Даже после установки

ALTER TABLE veryactivetable SET (autovacuum_vacuum_threshold = 10000);

pg_stat_user_tables для очень активных таблиц возвращает 63356 n_dead_tup и last_autoanalyze & last_autovacuum более 24 часов

настройки posgresql.conf:

shared_buffers = 7680MB
work_mem = 39321kB

maintenance_work_mem = 1920MB

vacuum_cost_delay = 0
vacuum_cost_page_hit = 1000
vacuum_cost_page_miss = 1000
vacuum_cost_page_dirty = 2000
vacuum_cost_limit = 7000


autovacuum = on
log_autovacuum_min_duration = 0
autovacuum_max_workers = 10
autovacuum_naptime = 10s
autovacuum_vacuum_threshold = 50
autovacuum_analyze_threshold = 50
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.05
autovacuum_freeze_max_age = 200000000
autovacuum_vacuum_cost_delay = 50ms
autovacuum_vacuum_cost_limit = 7000

1 Ответ

0 голосов
/ 13 мая 2018

Установите autovacuum_vacuum_scale_factor и autovacuum_analyze_scale_factor на более высокое значение, вероятно, лучше вернуться к значению по умолчанию.Не нужно запускать автоочистку чаще, чем необходимо, особенно в вашей ситуации.Идея состоит в том, чтобы сделать его быстрым, как только он начнется.

Установите autovacuum_naptime выше, ближе к исходному значению по умолчанию на одну минуту.

Восстановите autovacuum_max_workers до 3, если у вас нет многобаз данных или множества таблиц.

Что нужно сделать для того, чтобы сделать автовакуум максимально быстрым (что и является целью), это установить autovacuum_vacuum_cost_delay в 0.

Если у вас естьвсего несколько очень занятых таблиц, лучше всего установить их на те таблицы, которые вы указали в своем вопросе.

...