Основы мониторинга PostgreSQL. Алексей Лесовский

[yosemity]

Спасибо за отличный доклад и расшифровку.
Вопрос такой — есть ли общие рекомендации по проведению регламентов, в частности для OLTP и VACUUM FULL ANALYZE? Слышал мнение, что достаточно частый VACUUM FULL может иметь больше негативных последствий, чем пользы. Допустим, есть регламентное окно ночью, когда в базу не ходят клиенты и за это время успевает проходить VACUUM FULL. Есть смысл гонять каждую ночь, при прочих равных?

[Vitaly2606]

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. Читаем документацию.

[yosemity]

Благодарю, я правильно понимаю, что стремиться нужно к тому, чтобы вообще обходиться без регулярного 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

[Vitaly2606]

Ответ коллег из 1С вполне обоснован, так как это стороннее расширение не входящее в состав основного пакета PostgreSQL.

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

С ув, Виталий

[DmitryKoterov]

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

[chemtech]

Поправил. Спасибо.