powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Настройки autovacuum под HighLoad
18 сообщений из 43, страница 2 из 2
Настройки autovacuum под HighLoad
    #39172958
ursido
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Сергей Б,

Ничем.
Просто однажды особо активный пользователь так нагадит обновлениями/удалениями в таблице, что любая операция с ней будет клонить в сон. При этом размер таблицы будет измеряться сотнями мегабайт при сотнях тысяч живых записей. С последующим засыпанием всей БД.

А так, да, ничего страшного.
...
Рейтинг: 0 / 0
Настройки autovacuum под HighLoad
    #39172968
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей БА чем все-таки плохо включать в крон ежедневный ночной vacuumdb --analyze <DB>, когда база данных наименее нагружена (autovacuum off), чем ждать когда автовакум сработает (autovacuum on) в самый неподходящий момент (наиболее высокая нагрузка)
Чтобы избежать случаев, когда в таблице пару сотен живых записей и весит она при этом гигабайты.

Если вакуум настроен агрессивно, то он будет приходить часто и по чуть-чуть, это повышает вероятность того, что он придёт на горячие буфера, ну т.е. работать будет только с памятью. При умолчательных настройках он приходит редко (чем больше таблица, тем реже) и потому приводит к дполнительному IO. Для очень активных/больших таблиц можно scale_factor поставить в ноль и повысить threshold, скажем до 100т. Обычно это делается для особых таблиц индивидуально, через storage_parameters.
...
Рейтинг: 0 / 0
Настройки autovacuum под HighLoad
    #39172987
Pavel Bobrovnikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
По поводу своей проблемы - autovacuum (to prevent wraparound) ушел на таблице, которая весит 540 Гб через 3 дня работы.

Вот текущие параметры автовакуума/вакуума:


autovacuum onautovacuum_analyze_scale_factor 0.05autovacuum_analyze_threshold 50autovacuum_freeze_max_age 300000000autovacuum_max_workers 10autovacuum_multixact_freeze_max_age 400000000autovacuum_naptime 60autovacuum_vacuum_cost_delay 10autovacuum_vacuum_cost_limit 200autovacuum_vacuum_scale_factor 0.2autovacuum_vacuum_threshold 50log_autovacuum_min_duration 0vacuum_cost_delay 50vacuum_cost_limit 200vacuum_cost_page_dirty 20vacuum_cost_page_hit 1vacuum_cost_page_miss 10vacuum_defer_cleanup_age 0vacuum_freeze_min_age 50000000vacuum_freeze_table_age 150000000vacuum_multixact_freeze_min_age 5000000vacuum_multixact_freeze_table_age 150000000
...
Рейтинг: 0 / 0
Настройки autovacuum под HighLoad
    #39173000
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей Б,

обычно в БД есть много разных таблиц с разным профилем использования.

какие--то -- старые таблицы, которые анализировать каждую ночь просто бессмысленно. особенно если ночь эта должна быть полярной ---- чисто по суммарному объёму БД. т.к. приращение смылов там минимально .

какие--то -- требуют чуть не ежеминутного вакуума -- т.к. в среднем не содержат данных, но пропускают через себя большой поток транзакций. (много мертвых записей/сек).

какие -- то надо проанализировать в первые минуты после создания, через час, через 5, а потом -- по мере того, как.

и , самое важное , vacuum freeze (==to prevent wraparound) -- это совсем не то же самое, что и vacuum analyze.

Тут бы создателям озаботиться тем, чтобы стандартные воркеры этим служебным делом не занимались. а то фризы старых "биг--дата", которые приходят слипшимся "бунчем" (см. также "автомобильные пробки" == "простая волна в ур-ии с отрицательным нелинейным членом". вот это вот всё) напрочь лочат текущий факуум--analyze.
...
Рейтинг: 0 / 0
Настройки autovacuum под HighLoad
    #39173007
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Pavel Bobrovnikov,

при размерах таблиц в 540ГБ -- то, что они будут фризится сутками , а то --неделями -- нормально. В постгресе, к тому же, это просто необходимая системная работа, иначе сервер остановится.

По ходу -- все эти большие таблицы любят приходить на to prevent слипшимся комком, поскольку автовакуум не оценивает объём работы, а только возраст. т.ч. надо иногда бороться с этой тенденцией к собиранию кучек на to prevent. (анализируя кроме возраста, еще и суммарный объём постаревших данных). Комок, как и всякая пробка -- собирает за собой всю мелочь. и на следующий фриз они приходят "все вместе" уже в расширенном составе.
...
Рейтинг: 0 / 0
Настройки autovacuum под HighLoad
    #39173010
Pavel Bobrovnikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
qwwq,

Спасибо Вам и всем остальным за помощь и комментарии.

Посмотрите еще одним глазом параметры, которые сейчас применены (чуть выше пост), спасибо!
...
Рейтинг: 0 / 0
Настройки autovacuum под HighLoad
    #39173061
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Pavel BobrovnikovПо поводу своей проблемы - autovacuum (to prevent wraparound) ушел на таблице, которая весит 540 Гб через 3 дня работы.

Вот текущие параметры автовакуума/вакуума:
Код: sql
1.
2.
3.
...
vacuum_freeze_min_age	50000000
...



Приведите вывод:
Код: sql
1.
A=$(psql -qAtXc "SELECT txid_current()"); sleep 300; B=$(psql -qAtXc "SELECT txid_current()"); echo $(( ($B-$A)/5 ))


Это пишущие транзакции в минуту. Поставьте значение такое, чтобы примерно через 8 часов vacuum пытался бы морозить записи (умножтье на ~500 для 8 часов).
Он не будет специально читать все блоки, но те, которые всё равно в работе, заодно будут и морозиться.

В следующий раз, когда надо будет морозить вашу 540-таблицу, это займёт меньше 3 дней. Скорее всего :)
...
Рейтинг: 0 / 0
Настройки autovacuum под HighLoad
    #39173160
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vyegorov,

поясните, плз. правильно ли я понимаю, что [постоянной] карты полностью замороженных блоков [a-la BRIN] нет. и ускорение будет лишь за счёт того, что из 2--х операций [чтение/запись] он не полезет править полностью отмороженный блок [xmin==2]. читать-то его всё равно придётся.
т.е. "быстрее" тут не больше 2-х. (не более , чем в 2 раза).

или всё [уже] обстоит несколько лучше ?
...
Рейтинг: 0 / 0
Настройки autovacuum под HighLoad
    #39173242
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwwq,

Да, всё так. Карты нету и бонус в только-чтении всей таблицы, без генерации огромного кол-ва грязных блоков.
...
Рейтинг: 0 / 0
Настройки autovacuum под HighLoad
    #39173243
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> обстоит несколько лучше

всё хорошо, но карты (возможно, пока еще) нет

http://www.postgresql.org/message-id/flat/5522BD63.80808@BlueTreble.com#5522BD63.80808@BlueTreble.com]http://www.postgresql.org/message-id/flat/5522BD63.80808@BlueTreble.com#5522BD63.80808@BlueTreble.com

этот тред уже суть год
...
Рейтинг: 0 / 0
Настройки autovacuum под HighLoad
    #39173264
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
http://www.postgresql.org/message-id/flat/CAD21AoA9wRAynBnzuMm219wdHCgFY0aQ2iargVTGvJvpn_pODw@mail.gmail.com#CAD21AoA9wRAynBnzuMm219wdHCgFY0aQ2iargVTGvJvpn_pODw@mail.gmail.com]http://www.postgresql.org/message-id/flat/CAD21AoA9wRAynBnzuMm219wdHCgFY0aQ2iargVTGvJvpn_pODw@mail.gmail.com#CAD21AoA9wRAynBnzuMm219wdHCgFY0aQ2iargVTGvJvpn_pODw@mail.gmail.com

вот первый мессадж про фриз тут. но потом вышли на "карту"
...
Рейтинг: 0 / 0
Настройки autovacuum под HighLoad
    #39183326
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwwq...
или всё [уже] обстоит несколько лучше ?
Уже лучше!

Сегодня Robert Haas закоммитил карту для заморозки, в 9.6 ждём: http://www.postgresql.org/message-id/flat/E1aawtF-0000Tn-G0@gemulon.postgresql.org]http://www.postgresql.org/message-id/flat/E1aawtF-0000Tn-G0@gemulon.postgresql.org
...
Рейтинг: 0 / 0
Настройки autovacuum под HighLoad
    #39183905
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vyegorov,
i.e., т.к. оно в VM -- то будет актуализироваться только при VAACUUM, а все остальное время будет только деградировать ?

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

(например в huge таблу, архивного возраста, 10 записей вставили и тут же дропнули, но т.к. табла -- huge -- то ждать актуализации VM -- до второго пришествия ? нет ?)
...
Рейтинг: 0 / 0
Настройки autovacuum под HighLoad
    #39184065
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwwq,

Да, так и будет, карту только вакум меняет.
Ёе наличие позволит не сканировать всю таблицу, а проверить только те блоки, которые были затронуты.
Т.е. не нужно больше бояться, что при заморозке вся архивная таблица будет прочитана.

Если есть архивные таблицы, которые вот так чутка "торгаются" переодически, то можно им индивидуально понизить пороги срабатывания автовакума. Например, поставить %_scale_factor в 0 и чуть повысить %_threshold, до 1000 или 10000.
...
Рейтинг: 0 / 0
Настройки autovacuum под HighLoad
    #39184405
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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 можно было бы отдельные пороги срабатывания ставить.
...
Рейтинг: 0 / 0
Настройки autovacuum под HighLoad
    #39188129
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Boguk<>
PS: очень не хватает vacuum режима который бы читал только страницы без visibility map и НЕ ТРОГАЛ БЛИН 100Gb холодных индексов на этой таблице (тогда он был бы дешевым и быстрым даже на очень больших таблицах это как раз про "более оперативные подходы к актуализации VM"). апчом и речь. есть таблица, практически (за малым исключением) insert only (т.е. партиции такие), размером в среднем по 200Гиг, и индексами в сумме 150--200 , т.е. все индексы заведомо почти кошерные. Но вакуумить её всё время тяжко -- лишь бы планы были хороши -- автовакуума хватает, да пара--тройка аналайзов джобом в первые сутки от создания. (когда порядок числа записей быстро меняется)

и вот по ней хочется IOS, а он, сцобако, все время -- пыва нет "Heap Fetches: XXX"
и это при loops YYY(Y)
и как быть ?
...
Рейтинг: 0 / 0
Настройки autovacuum под HighLoad
    #39188375
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
...
Рейтинг: 0 / 0
Настройки autovacuum под HighLoad
    #39188979
Фотография grufos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Boguk,

я кстати рассказал ребятам из PostgresPro о твоём замечательном скрипте неблокирующего сжатия таблиц.
им идея понравилась.... надеюсь сделают в своём форке для автовакуума ну или как vacuum concurently эту идею.
...
Рейтинг: 0 / 0
18 сообщений из 43, страница 2 из 2
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Настройки autovacuum под HighLoad
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]