Должен ли я вручную VACUUM свою базу данных PostgreSQL, если автовакуум включен?

Я использую программное обеспечение, которое создает большую базу данных PostgreSQL (там есть таблица с миллионом строк), и разработчики говорят, что я должен VACUUMи ANALYZEпериодически. Но база данных PostgreSQL по умолчанию autovacuumвключена.

Должен ли я пылесосить / анализировать вообще? Каковы преимущества? В чем разница между автоматическим и ручным вакуумом

Например, в Pgadmin3 у меня есть это:

Я согласен с ETL, что нет короткого ответа. Размер - это не единственное, что имеет значение - мы запускаем довольно большие базы данных PostgreSQL OLTP (с некоторыми таблицами> 100 000 000 строк) под большой нагрузкой, и в настоящее время мы полагаемся только на автовакуум.

Тем не менее, две вещи кажутся мне важными:

• Кажется, существует консенсус, что автоочистку никогда не следует отключать, если только у вас нет четко определенной рабочей нагрузки в базе данных и вы точно не знаете, что делаете. Но, естественно, вы могли бы сделать дополнительные VACUUMи / или ANALYZEпробежки.

• Прежде чем рассмотреть дополнительные VACUUMпрогоны, я бы проверил, как идет автовакуум. Вы можете проверить, находятся ли какие-либо таблицы за порогом автоочистки, запросив pg_stat_user_tablesи pg_class. Я разместил такой запрос в другой ветке, которая может представлять интерес: Aggressive Autovacuum на PostgreSQL .

  К сожалению, подобная проверка порогов автоанализа сделать не так просто (т. Е. Сейчас невозможно). Тем не менее, автоанализ анализируется задолго до автовакуума по умолчанию, и это намного дешевле. Таким образом, в принципе, если ваша база данных будет работать с автовакуумом, то, вероятно, будет хорошо и с автоматическим анализом. Последние даты автоанализ также могут быть запрошены из pg_stat_user_tables.

Некоторые части (самой превосходной) документации PostgreSQL, которые я нашел полезными:

• Рутинный пылесос
• Сборщик статистики

Автовакуум должен хорошо покрыть это, если вы что-то не настроили. Другие ответы уже охватывают это.

Существует один четко определенный случай для ручного VACUUM (и, что более важно: ручного ANALYZE), хотя: временные таблицы , они не рассматриваются демоном autovacuum. Я цитирую руководство CREATE TABLEздесь :

Автовакууминг демон не может получить доступ и , следовательно , не может пылесосить или анализировать временные таблицы. По этой причине соответствующие операции вакуума и анализа должны выполняться с помощью команд сеанса SQL. Например, если временная таблица будет использоваться в сложных запросах, целесообразно запускать ANALYZEвременную таблицу после ее заполнения.

На это нет короткого ответа, так как это зависит от многих факторов. Система медленная? Автоматический вакуум действительно касается этого стола? и т.п.

Вот несколько хороших ссылок на эту тему:

• Особенности производительности PostgreSQL
• Оптимизация производительности (PostgreSQL wiki)
• Введение в VACUUM, ANALYZE, EXPLAIN и COUNT (тот же источник)
• Интерпретация представлений pg_stat, понимание представлений pg_stat

Чтобы принять четкое решение, требуется понимание самой базы данных и больше подробностей о том, что происходит.

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

Чтобы увидеть текущие настройки, запустите этот запрос:

SELECT *
FROM pg_settings 
WHERE name LIKE '%vacuum%'

Большинство полей говорят сами за себя, но вот документация по ним: https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html

Я бы сказал, что ваша цель должна состоять в том, чтобы настроить автовакуум для последовательной очистки мусора, но не запускать автовакуум постоянно

Наиболее важные настройки:

• autovacuum_vacuum_scale_factor - определяет процент кортежей, которые могут быть отключены до начала очистки. Значение по умолчанию = 0,2
• autovacuum_vacuum_threshold - минимальное количество мертвых кортежей перед началом очистки. Значение по умолчанию = 50

Порог помогает предотвратить слишком частый запуск процесса очистки для небольших таблиц.

Настройки по умолчанию работают хорошо, если у вас нет очень больших таблиц. Проще говоря, если у вас есть таблица, которая занимает 100 ГБ, вы собираетесь накапливать 20 ГБ мусора, прежде чем будет запущен автовакуум. Поэтому я обычно рекомендую устанавливать низкий коэффициент масштабирования. Как низко вы должны определить для себя. Я использую 0,05 на моем текущем проекте

Пороги тоже можно увеличить. Во многих приложениях есть пара таблиц, которые часто обновляются, и 50 кортежей не так уж много. Увеличение этого значения до 1000 не должно привести к каким-либо проблемам, но, конечно, вы должны рассмотреть свой собственный случай

Вы также можете отрегулировать автоочистку и иметь различные настройки для некоторых из ваших столов.

ALTER TABLE your_table SET (autovacuum_vacuum_scale_factor = 0.05);

Если вы настраиваете scale_factor и пороговые значения, все будет в порядке. Вы также можете увеличить значение autovacuum_vacuum_cost_limit, которое по умолчанию равно vacuum_cost_limit200. Это очень важная особенность вакуума, которая не позволяет ему поглощать все ресурсы и позволяет вашему приложению работать с данными даже во время процесса очистки. , но значение по умолчанию слишком низкое. Увеличение его до 1000 не должно привести к каким-либо значительным задержкам, но позволит вакуумному процессу завершиться намного быстрее.

Конечно, вы также можете запустить вакуум вручную. В самом простом случае вы можете выполнить простую задачу cron, которая будет выполнять полную очистку каждую ночь, когда к вашей БД не обращаются часто

Надеюсь, это поможет!