Pull to refresh

Comments 6

Спасибо за отличный доклад и расшифровку.
Вопрос такой — есть ли общие рекомендации по проведению регламентов, в частности для OLTP и VACUUM FULL ANALYZE? Слышал мнение, что достаточно частый VACUUM FULL может иметь больше негативных последствий, чем пользы. Допустим, есть регламентное окно ночью, когда в базу не ходят клиенты и за это время успевает проходить VACUUM FULL. Есть смысл гонять каждую ночь, при прочих равных?
1. Начните с настройки более агрессивной работы autovacuum:
autovacuum_analyze_scale_factor = 0.02 (либо 0.002)
autovacuum_vacuum_scale_factor = 0.01 (либо 0.001)
2. Выставляйте индивидуальные параметры для очень больших таблиц, так как даже 1% scale_factor это может быть много. Пример (не в % а в кол.):
alter table table_name set (autovacuum_vacuum_scale_factor = 0);
alter table table_name set (autovacuum_vacuum_threshold = 1000);
alter table table_name set (autovacuum_analyze_scale_factor = 0);
alter table table_name set (autovacuum_analyze_threshold = 1000);

3. Настройте мониторинг, отслеживайте количество и время выполнения работы процесса autovacuum, если у вас default — autovacuum_max_workers = 3, и все эти 3 воркера постоянно в работе, это может говорить о необходимости увеличения кол. воркеров, и/или увеличения autovacuum_vacuum_cost_limit
4. VACUUM FULL — это эксклюзивный лок таблиц, ознакомьтесь с pg_repack (позволяет избежать длительной блокировки)
5. Читаем документацию.
Благодарю, я правильно понимаю, что стремиться нужно к тому, чтобы вообще обходиться без регулярного VACUUM FULL?
C pg_repack знаком, по нему есть вопрос — могут ли быть подводные камни при работе с 1с? Смутил вот такой ответ на форуме 1с:
pg_repack не входит в состав расширений, публикуемых нами в сборке postgres.
postgres не тестируется с pg_repack у нас, не обеспечивается или конктролируется его совместимость.
Другими словами, мы не учитываем особенности pg_repack в разработке.
В списке наших планов есть вопрос рассмотрения поддержки pg_repack или каких-то аналогов, но до этой задачи пока не добрались.
Использовать pg_repack можно только на свое усмотрение, осознавая риск, что это может привести к проблемам, которые не будут воспроизводиться без использования pg_repack. У нас рекомендации использовать pg_repack нет.
Не понятно, что там может быть особенного, но ответ сотрудника насторожил.

По п.5 изучаю The Internals of PostgreSQL
Ответ коллег из 1С вполне обоснован, так как это стороннее расширение не входящее в состав основного пакета PostgreSQL.

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

С ув, Виталий

Память-то не «шардированная», а shared. Большая разница.

Sign up to leave a comment.

Articles