автовакуума? Есть таблица на 80М строк, раз в день в нее приходит ETL джоба и пачками по 300к-1М добавляет/обновляет 2-2.5М строк и удаляет тысяч 300-500. Плюс где-то 2-10 раз в минуту в таблу падают новые строки из приложения. Вот непонятно что лучше, настроить автовакуум чтобы точно срабатывал после окончания ETL, но тогда есть риск, что пачка мертвых строк останется висеть до следующих суток.
а просто руками вакуум запустить после комита?
Об этом надо помнить, что вот эти три строчки кода в джобе не просто так.
Ну что и? А на завтра сменится етл-движок или вообще вместо етл джобов база присядет на кафку
ну если на пальцах, то у вас примерно 3млн изменений / 80млн строк = 0.0375
Ну вот хочется с одной стороны чтобы автовакуум отработал как можно бОльшее число изменений, с другой стороны чтобы не спамился. То есть если поставить чтобы срабатывал на 3М, в какой-нибудь день будет меньше изменений и совсем не запустится, будет обидно
А что такого уж страшного в том, что он лишний раз запустится?
Он скорее всего запустится одновременно с работой етл. Насколько это чревато?
не особо страшно, просто диски будут лишний раз напрягаться Сколько таблица весит?
Я уверен, что почти у всех он таким образом всё время запускается, и почти никто не замечает. Т.е. там есть с ним какая-то реальная проблема?
Не думаю. Мы для себя текущую ситуацию открыли сравнительно недавно и вот думаем как лучше поступить
То есть сейчас есть проблема блоатинга, и ее заметно глазом
Както раз заметили, когда умудрились во время бекапа запустить огромную вргузку данных и на 90 гиговой таблице запустился вакуум, ssd встал колом =) и то что по отдельности занимало не более 30 мин, длилось 2 часа
Т.е. до этого не замечали, ммм? ;) > То есть сейчас есть проблема блоатинга, и ее заметно глазом Для начала — сделать autovacuum агрессивнее, как обычно. И лучше глобально, IMHO — в этих потабличных настройках потом легко запутаться, забыть о них и т.п.
Так этож SaaS, в нем пока жареный петух не того... :)
А там точно проблема была не в чём-то совсем другом (checkpoint, или блокировки, если "пришёл" anti-wraparound vacuum и т.п.)?
Научились собирать статистику постгреса и отливать ее в эластик, пару месяцев копили, посмотрели динамики, и узрели n_dead_tuples, взлетающие свечкой после отработки суточных етл в 2-3М. И так они и висят пока в ночи не приходит бэкапилка вендорская и не делает принудительный вакуум
Не думаю. Хотя честно признаюсь - не разбирались, просто увидели что io 100%, просто подождали, через 2 часа все успешно завершилось
А проблемы от них какие-то были? На таблицах существенных размеров 2-3М dead tuples — это ни о чём.
Обсуждают сегодня