Я использую программное обеспечение, которое создает большую базу данных 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временную таблицу после ее заполнения.
На это нет короткого ответа, так как это зависит от многих факторов. Система медленная? Автоматический вакуум действительно касается этого стола? и т.п.
Вот несколько хороших ссылок на эту тему:
Чтобы принять четкое решение, требуется понимание самой базы данных и больше подробностей о том, что происходит.
Я не думаю, что вам нужно вручную пылесосить, если вы не начинаете видеть снижение производительности. Тем не менее, я настоятельно рекомендую пересмотреть настройки вакуума и автоочистки и настроить их под свои нужды.
Чтобы увидеть текущие настройки, запустите этот запрос:
SELECT *
FROM pg_settings
WHERE name LIKE '%vacuum%'Большинство полей говорят сами за себя, но вот документация по ним: https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html
Я бы сказал, что ваша цель должна состоять в том, чтобы настроить автовакуум для последовательной очистки мусора, но не запускать автовакуум постоянно
Наиболее важные настройки:
Порог помогает предотвратить слишком частый запуск процесса очистки для небольших таблиц.
Настройки по умолчанию работают хорошо, если у вас нет очень больших таблиц. Проще говоря, если у вас есть таблица, которая занимает 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, которая будет выполнять полную очистку каждую ночь, когда к вашей БД не обращаются часто
Надеюсь, это поможет!