Pavel BobrovnikovРебья, привет.

Подскажите, пожалуйста, как правильно выставить параметры autovacuum на базе 24/7, с интенсивной записью, размером 1,1 Тб.

Текущие:
autovacuum = on .
autovacuum_max_workers = 10
autovacuum_naptime = 5min
autovacuum_vacuum_threshold = 50
autovacuum_analyze_threshold = 50
autovacuum_vacuum_scale_factor = 0.2
autovacuum_analyze_scale_factor = 0.05
autovacuum_freeze_max_age = 200000000
autovacuum_multixact_freeze_max_age = 400000000
autovacuum_vacuum_cost_delay = 60ms
autovacuum_vacuum_cost_limit = -1
autovacuum_vacuum_threshold = 50

Плюс:
каждую ночь su - postgres -c "vacuumdb --all --analyze"

Вывод интересный:
SELECT relname, age(relfrozenxid) as xid_age,
pg_size_pretty(pg_table_size(oid)) as table_size
FROM pg_class
WHERE relkind = 'r' and pg_table_size(oid) > 1073741824
ORDER BY age(relfrozenxid) DESC LIMIT 10;

table1 159237556 1038 MB
table2 158878128 1343 MB
table3 158815533 1374 MB
table4 158723489 1479 MB
table5 141564968 9660 MB
table6 138502077 4992 MB
table7 138485230 10 GB
table8 135262562 32 GB
table9 135262154 21 GB
table10 118373215 48 GB

Настройки autovacuum выставляются на основе графиков использования autovacuum процессов (обычных и antiwraparound) и графиков загрузки дисковой подсистемы. А не из абстрактных соображений.
Учитывая размер базы 1.1Tb я бы сказал что vacuumdb --all --analyze - оно лишнее а вот autovacuum_vacuum_cost_delay = 60ms наоборот высоковат причем сильно. Но более конкретно - нужны графики за неделю. Без них ничего умного сказать нельзя.

--
Maxim Boguk
www.postgresql-consulting.ru

Pavel Bobrovnikov,

Знакомые картинки с Okmeter. :)
Пока у вас график autovacuum workers не упирается в потолок - у вас все более менее разумно настроено и ничего трогать не надо.
Я бы еще наверное уменьшил бы autovacuum_naptime до 1 секунды (вреда от этого обычно не бывает).

А ночной ручной vacuum отключил бы за ненужностью и насилованием дисков.

--
Maxim Boguk
www.postgresql-consulting.ru

qwwqvyegorov,
i.e., т.к. оно в VM -- то будет актуализироваться только при VAACUUM, а все остальное время будет только деградировать ?

Или есть более оперативные подходы к атуализации VM ?

(например в huge таблу, архивного возраста, 10 записей вставили и тут же дропнули, но т.к. табла -- huge -- то ждать актуализации VM -- до второго пришествия ? нет ?)

А зачем вам актуальность VM/freeze map до последней страницы?
Ну будут у вас 10 странниц в худшем случае без all visible/freezed так следующий vacuum freeze эти 10 страниц то и зафризит и будет вам и VM и freezemap свежий.

PS: очень не хватает vacuum режима который бы читал только страницы без visibility map и НЕ ТРОГАЛ БЛИН 100Gb холодных индексов на этой таблице (тогда он был бы дешевым и быстрым даже на очень больших таблицах это как раз про "более оперативные подходы к актуализации VM"). И для такого vacuum можно было бы отдельные пороги срабатывания ставить.

qwwqMaxim Boguk<>
PS: очень не хватает vacuum режима который бы читал только страницы без visibility map и НЕ ТРОГАЛ БЛИН 100Gb холодных индексов на этой таблице (тогда он был бы дешевым и быстрым даже на очень больших таблицах это как раз про "более оперативные подходы к актуализации VM"). апчом и речь. есть таблица, практически (за малым исключением) insert only (т.е. партиции такие), размером в среднем по 200Гиг, и индексами в сумме 150--200 , т.е. все индексы заведомо почти кошерные. Но вакуумить её всё время тяжко -- лишь бы планы были хороши -- автовакуума хватает, да пара--тройка аналайзов джобом в первые сутки от создания. (когда порядок числа записей быстро меняется)

и вот по ней хочется IOS, а он, сцобако, все время -- пыва нет "Heap Fetches: XXX"
и это при loops YYY(Y)
и как быть ?

Я попробую http://2016.pgday.asia/ поднять этот вопрос с разработчиками под пиво.
Что надо - понятно: light vacuum со своими настройками который только vm/freeze map/hint bits обновляет и все (и со своим независимым scale_factor).
Т.е. просто добавить vacuum lite к vacuum и vacuum full (и главное почти ничего писать не надо а взять код vacuum и за IF ать 90% логики).
Но даже если я смогу убедить - это вряд ли будет раньше чем 9.7 (разве что pgpro свой форк сделает ;)).

--
Maxim Boguk
www.postgresql-consulting.ru