|
|
|
Настройки autovacuum под HighLoad
|
|||
|---|---|---|---|
|
#18+
Сергей Б, Ничем. Просто однажды особо активный пользователь так нагадит обновлениями/удалениями в таблице, что любая операция с ней будет клонить в сон. При этом размер таблицы будет измеряться сотнями мегабайт при сотнях тысяч живых записей. С последующим засыпанием всей БД. А так, да, ничего страшного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2016, 11:22 |
|
||
|
Настройки autovacuum под HighLoad
|
|||
|---|---|---|---|
|
#18+
Сергей БА чем все-таки плохо включать в крон ежедневный ночной vacuumdb --analyze <DB>, когда база данных наименее нагружена (autovacuum off), чем ждать когда автовакум сработает (autovacuum on) в самый неподходящий момент (наиболее высокая нагрузка) Чтобы избежать случаев, когда в таблице пару сотен живых записей и весит она при этом гигабайты. Если вакуум настроен агрессивно, то он будет приходить часто и по чуть-чуть, это повышает вероятность того, что он придёт на горячие буфера, ну т.е. работать будет только с памятью. При умолчательных настройках он приходит редко (чем больше таблица, тем реже) и потому приводит к дполнительному IO. Для очень активных/больших таблиц можно scale_factor поставить в ноль и повысить threshold, скажем до 100т. Обычно это делается для особых таблиц индивидуально, через storage_parameters. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2016, 11:28 |
|
||
|
Настройки autovacuum под HighLoad
|
|||
|---|---|---|---|
|
#18+
По поводу своей проблемы - 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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2016, 11:34 |
|
||
|
Настройки autovacuum под HighLoad
|
|||
|---|---|---|---|
|
#18+
Сергей Б, обычно в БД есть много разных таблиц с разным профилем использования. какие--то -- старые таблицы, которые анализировать каждую ночь просто бессмысленно. особенно если ночь эта должна быть полярной ---- чисто по суммарному объёму БД. т.к. приращение смылов там минимально . какие--то -- требуют чуть не ежеминутного вакуума -- т.к. в среднем не содержат данных, но пропускают через себя большой поток транзакций. (много мертвых записей/сек). какие -- то надо проанализировать в первые минуты после создания, через час, через 5, а потом -- по мере того, как. и , самое важное , vacuum freeze (==to prevent wraparound) -- это совсем не то же самое, что и vacuum analyze. Тут бы создателям озаботиться тем, чтобы стандартные воркеры этим служебным делом не занимались. а то фризы старых "биг--дата", которые приходят слипшимся "бунчем" (см. также "автомобильные пробки" == "простая волна в ур-ии с отрицательным нелинейным членом". вот это вот всё) напрочь лочат текущий факуум--analyze. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2016, 11:46 |
|
||
|
Настройки autovacuum под HighLoad
|
|||
|---|---|---|---|
|
#18+
Pavel Bobrovnikov, при размерах таблиц в 540ГБ -- то, что они будут фризится сутками , а то --неделями -- нормально. В постгресе, к тому же, это просто необходимая системная работа, иначе сервер остановится. По ходу -- все эти большие таблицы любят приходить на to prevent слипшимся комком, поскольку автовакуум не оценивает объём работы, а только возраст. т.ч. надо иногда бороться с этой тенденцией к собиранию кучек на to prevent. (анализируя кроме возраста, еще и суммарный объём постаревших данных). Комок, как и всякая пробка -- собирает за собой всю мелочь. и на следующий фриз они приходят "все вместе" уже в расширенном составе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2016, 11:55 |
|
||
|
Настройки autovacuum под HighLoad
|
|||
|---|---|---|---|
|
#18+
qwwq, Спасибо Вам и всем остальным за помощь и комментарии. Посмотрите еще одним глазом параметры, которые сейчас применены (чуть выше пост), спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2016, 11:57 |
|
||
|
Настройки autovacuum под HighLoad
|
|||
|---|---|---|---|
|
#18+
Pavel BobrovnikovПо поводу своей проблемы - autovacuum (to prevent wraparound) ушел на таблице, которая весит 540 Гб через 3 дня работы. Вот текущие параметры автовакуума/вакуума: Код: sql 1. 2. 3. Приведите вывод: Код: sql 1. Это пишущие транзакции в минуту. Поставьте значение такое, чтобы примерно через 8 часов vacuum пытался бы морозить записи (умножтье на ~500 для 8 часов). Он не будет специально читать все блоки, но те, которые всё равно в работе, заодно будут и морозиться. В следующий раз, когда надо будет морозить вашу 540-таблицу, это займёт меньше 3 дней. Скорее всего :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2016, 12:40 |
|
||
|
Настройки autovacuum под HighLoad
|
|||
|---|---|---|---|
|
#18+
vyegorov, поясните, плз. правильно ли я понимаю, что [постоянной] карты полностью замороженных блоков [a-la BRIN] нет. и ускорение будет лишь за счёт того, что из 2--х операций [чтение/запись] он не полезет править полностью отмороженный блок [xmin==2]. читать-то его всё равно придётся. т.е. "быстрее" тут не больше 2-х. (не более , чем в 2 раза). или всё [уже] обстоит несколько лучше ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2016, 13:58 |
|
||
|
Настройки autovacuum под HighLoad
|
|||
|---|---|---|---|
|
#18+
qwwq, Да, всё так. Карты нету и бонус в только-чтении всей таблицы, без генерации огромного кол-ва грязных блоков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2016, 14:57 |
|
||
|
Настройки autovacuum под HighLoad
|
|||
|---|---|---|---|
|
#18+
> обстоит несколько лучше всё хорошо, но карты (возможно, пока еще) нет 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 этот тред уже суть год ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2016, 15:01 |
|
||
|
Настройки autovacuum под HighLoad
|
|||
|---|---|---|---|
|
#18+
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 вот первый мессадж про фриз тут. но потом вышли на "карту" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2016, 15:25 |
|
||
|
Настройки autovacuum под HighLoad
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2016, 10:28 |
|
||
|
Настройки autovacuum под HighLoad
|
|||
|---|---|---|---|
|
#18+
vyegorov, i.e., т.к. оно в VM -- то будет актуализироваться только при VAACUUM, а все остальное время будет только деградировать ? Или есть более оперативные подходы к атуализации VM ? (например в huge таблу, архивного возраста, 10 записей вставили и тут же дропнули, но т.к. табла -- huge -- то ждать актуализации VM -- до второго пришествия ? нет ?) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2016, 15:47 |
|
||
|
Настройки autovacuum под HighLoad
|
|||
|---|---|---|---|
|
#18+
qwwq, Да, так и будет, карту только вакум меняет. Ёе наличие позволит не сканировать всю таблицу, а проверить только те блоки, которые были затронуты. Т.е. не нужно больше бояться, что при заморозке вся архивная таблица будет прочитана. Если есть архивные таблицы, которые вот так чутка "торгаются" переодически, то можно им индивидуально понизить пороги срабатывания автовакума. Например, поставить %_scale_factor в 0 и чуть повысить %_threshold, до 1000 или 10000. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2016, 16:56 |
|
||
|
Настройки autovacuum под HighLoad
|
|||
|---|---|---|---|
|
#18+
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 можно было бы отдельные пороги срабатывания ставить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2016, 04:55 |
|
||
|
Настройки autovacuum под HighLoad
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk<> PS: очень не хватает vacuum режима который бы читал только страницы без visibility map и НЕ ТРОГАЛ БЛИН 100Gb холодных индексов на этой таблице (тогда он был бы дешевым и быстрым даже на очень больших таблицах это как раз про "более оперативные подходы к актуализации VM"). апчом и речь. есть таблица, практически (за малым исключением) insert only (т.е. партиции такие), размером в среднем по 200Гиг, и индексами в сумме 150--200 , т.е. все индексы заведомо почти кошерные. Но вакуумить её всё время тяжко -- лишь бы планы были хороши -- автовакуума хватает, да пара--тройка аналайзов джобом в первые сутки от создания. (когда порядок числа записей быстро меняется) и вот по ней хочется IOS, а он, сцобако, все время -- пыва нет "Heap Fetches: XXX" и это при loops YYY(Y) и как быть ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2016, 14:31 |
|
||
|
Настройки autovacuum под HighLoad
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2016, 16:41 |
|
||
|
Настройки autovacuum под HighLoad
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, я кстати рассказал ребятам из PostgresPro о твоём замечательном скрипте неблокирующего сжатия таблиц. им идея понравилась.... надеюсь сделают в своём форке для автовакуума ну или как vacuum concurently эту идею. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 12:54 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=39173000&tid=1997373]: |
0ms |
get settings: |
9ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
47ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
68ms |
get tp. blocked users: |
1ms |
| others: | 244ms |
| total: | 409ms |

| 0 / 0 |
