Комментарии 14
Очень полезная статья! Спасибо!
С postgres работаю очень давно, но вот вопрос настройки автовакуума постоянно возникает и вызывает прогблемы.
С postgres работаю очень давно, но вот вопрос настройки автовакуума постоянно возникает и вызывает прогблемы.
А можно перечислить причины, почему нужно отключать автовакуум? Просто все статьи, упоминающие Постгре серьёзно настаивают и предупреждают, что ни в коем случае, никогда, ни при каких условиях не отключайте вакуум. Данная не исключение.
Соответственно, я никак не могу понять, откуда берутся люди, которые это делают? Это специальные вредители среди разработчиков и админов? Или классический гипотетический сотрудник, который только в рекламе и сериалах попадается?
Соответственно, я никак не могу понять, откуда берутся люди, которые это делают? Это специальные вредители среди разработчиков и админов? Или классический гипотетический сотрудник, который только в рекламе и сериалах попадается?
Ну, например, если с базой работается в одно лицо.
И/или человек абсолютно точно знает, когда и как база используется:
1. тотально эксклюзивно вставляет данные (и здесь автовакум ни разу не нужен вообще)
2. и потом тотально эксклюзивно меняет данные (и именно сейчас тоже не нужен)
3. и потом тотально эксклюзивно запускает вакуум вручную (и здесь тоже не нужен)
4. и потом только читает (тоже не нужен в плане чистки)
И/или человек абсолютно точно знает, когда и как база используется:
1. тотально эксклюзивно вставляет данные (и здесь автовакум ни разу не нужен вообще)
2. и потом тотально эксклюзивно меняет данные (и именно сейчас тоже не нужен)
3. и потом тотально эксклюзивно запускает вакуум вручную (и здесь тоже не нужен)
4. и потом только читает (тоже не нужен в плане чистки)
А стоят ли такие сложности выигрыша в сколько-то % производительности, даже не могу представить сколько 1? 2? (с учётом статьи, вакуум даже работать не будет на этих таблицах, т.к. по критериям очистки не подойдут).
Стоят.
Речь не о «1? 2?», а о в разы.
Например отключение индексов при импорте моих данных ускоряет это дело в 2-3 раза (речь о миллионах записей).
А автовакуум прекрасно сработал после п.1, индексирования и п.2 — и уложил машину.
Так что в некоторых случаях «скрипач не нужен» ©
Речь не о «1? 2?», а о в разы.
Например отключение индексов при импорте моих данных ускоряет это дело в 2-3 раза (речь о миллионах записей).
А автовакуум прекрасно сработал после п.1, индексирования и п.2 — и уложил машину.
Так что в некоторых случаях «скрипач не нужен» ©
Не очень понял ваш ответ. В качестве примера отключения вакуума вы приводите отключение индексов. Что совершенно другое.
1. Отключаются индексы
2. Импорт данных
3. Включаются индексы (это к вопросу «зачем такие сложности», хотя я теперь не понял какие сложности имелись ввиду)
4. Кое-что меняется в данных
Во время всех этих операций автовакуум не только не нужен, но и мешает.
2. Импорт данных
3. Включаются индексы (это к вопросу «зачем такие сложности», хотя я теперь не понял какие сложности имелись ввиду)
4. Кое-что меняется в данных
Во время всех этих операций автовакуум не только не нужен, но и мешает.
Так опять же. Насколько он мешает? У нас идёт только вставка, т.е. мёртвых записей не должно быть, вакуум просто пропустит эту таблицу.
А вот пункт «4 — кое что меняется в данных», выглядит как объяснение всего что может быть. В общем-то это смысл существования базы данных — кое-что менять в данных :)
А вот пункт «4 — кое что меняется в данных», выглядит как объяснение всего что может быть. В общем-то это смысл существования базы данных — кое-что менять в данных :)
Во время восстановления базы из дампа можно его выключить временно. Встречал такие рекомендации, якобы процесс восстановления пройдет быстрее.
Вопрос-система сильно нагружена в опеделённые часы, соответственно есть часы простоя. Есть ли смысл отключить AUTOVACUUM и запускать его вручную по расписанию?
Автоваккум нельзя выключить. Можно изменить его настройки, чтобы он меньше работал.
Для сильнонагруженных БД можно делать вакуум в часты простоя либо использовать https://github.com/dataegret/pgcompacttable.
Если делать ваккум часы простоя, то у вас будет плохая статистика, а из-за плохой статистики у вас будут плохие планы запросов.
Pgcompacttable более бережно относится к ресурсам, потому что работает немного по другим принципам. Основная суть у pgcompacttable в том, что она апдейтами в таблице переносит все живые строки в начало таблицы. И потом запускает вакуум по этой таблице, потому что мы знаем, что у нас в начале живые, а в конце мертвые строки. И вакуум уже сам отрезает этот хвостик, т. е. дополнительного дискового пространства он не сильно требует.
del
autovacuum запускается не когда ему хочется, а при достижении определенных условий от заданных (для сервера/таблицы) показателей:
postgrespro.ru/docs/postgresql/12/runtime-config-autovacuum
Поэтому если вы будете запускать VACUUM/ANALYZE вручную (например, по ночам), то условия в течение «активной фазы» не будут успевать достигаться, и autovacuum не запустится.
Мы примерно таким образом (+ pg_repack, + VACUUM FREEZE) «утаптываем» заполнившиеся секции «за вчера»:
habr.com/ru/post/497008
postgrespro.ru/docs/postgresql/12/runtime-config-autovacuum
Поэтому если вы будете запускать VACUUM/ANALYZE вручную (например, по ночам), то условия в течение «активной фазы» не будут успевать достигаться, и autovacuum не запустится.
Мы примерно таким образом (+ pg_repack, + VACUUM FREEZE) «утаптываем» заполнившиеся секции «за вчера»:
habr.com/ru/post/497008
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Давайте отключим vacuum?! Алексей Лесовский