Про агрессивный автовакуум PostgreSQL

По агрессивному автовакууму , предварительно , чудес не бывает - за повышение производительности при средней нагрузке придётся платить снижением производительности при нагрузке близкой к максимальной.
Если autovacuum worker работает постоянно(а при высокой нагрузке иначе нет смысла), ресурсы CPU кончаются раньше .
Обслуживание СУБД требует ресурсов .
Но , конечно можно и не обслуживать , работает же. А +/- 5-10% изменения производительности СУБД современные приложения и не заметят.

После анализа результатов экспериментов , будут данные по ожиданиям . И в общем-то, тему можно закрывать , хотя с академической точки - интересно будет протестировать параметр autovacuum_cost_delay.


P.S. Так выглядит агрессивный автовакуум PostgreSQL - по мнению нейросети 🤪

Про агрессивный автовакуум PostgreSQL

Postgres DBA

158 постов27 подписчиков

Правила сообщества

Пока действуют стандартные правила Пикабу.

0
Автор поста оценил этот комментарий

Тогда партиционирование, если не юзаете. Может даже прирост скорости работы дать.

раскрыть ветку (1)
0
Автор поста оценил этот комментарий
Влияние партиционирования это тема совсем других экспериментов . Это больше к разработчиками тема , не к DBA.
0
Автор поста оценил этот комментарий

Кстати, один из вариантов https://habr.com/ru/companies/selectel/articles/920826/#4

Создание новой таблицы и переключение на нее

Не факт, что с любыми размерами сработает быстрее, но как идея

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Для таблицы в десятки терабайт ? Вы это серьезно ?

показать ответы
Автор поста оценил этот комментарий

Окаркл, мс-скуль, можно даже кликхаус или сливу, зависит от того, для чего система.

Мы работали с МС, база под полтора терабайта

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Окаркл, мс-скуль, можно даже кликхаус или сливу

Для обсуждения этого , наверное есть другие сообщества.

0
Автор поста оценил этот комментарий

Зачем? Скриптом

раскрыть ветку (1)
0
Автор поста оценил этот комментарий
Ну понятно , не в psql.
Просто целесообразность дублирования/замены встроенного механизма СУБД непонятна.
А может правильнее настроить параметры автовакуума для каждой таблицы отдельно ?
показать ответы
0
Автор поста оценил этот комментарий

Чистить таблицы надо по "грязноте", каждый раз формируя список в нужном порядке. А для систем 24/7, как я написал, не используют голое пг, и уж тем более однин сервер - репликация, базы только на чтение наше все

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

для систем 24/7, как я написал, не используют голое пг
А , что используют ? Ну, просто любопытно , может чего посоветовать нашим архитекторам .

показать ответы
0
Автор поста оценил этот комментарий

Чистить таблицы надо по "грязноте", каждый раз формируя список в нужном порядке. А для систем 24/7, как я написал, не используют голое пг, и уж тем более однин сервер - репликация, базы только на чтение наше все

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Чистить таблицы надо по "грязноте", каждый раз формируя список в нужном порядке.
Т.е. вручную ?

показать ответы
1
Автор поста оценил этот комментарий

Да просто надо в регламентные часы его делать. Тут от системы, конечно, зависит, но найти в сутках/неделе несколько часов всегда можно. А где нельзя там вряд ли пг крутится

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Смысл делать в регламентные часы , если в рабочее время огромная нагрузка и в окно просто не успевает пройти очистка всех таблиц? В результате , это реальный кейс, объем мертвых строк 4TB и порядка 40-45 таблиц по которым автовакуум вообще никогда не приходил .

найти в сутках/неделе несколько часов всегда можно.
а для систем 24/7 ?

показать ответы