Регулярный ВАКУУМНЫЙ АНАЛИЗ все еще рекомендуется под 9.1?

38

Я использую PostgreSQL 9.1 в Ubuntu. Запланировано ли это по- VACUUM ANALYZEпрежнему, или этого достаточно для того, чтобы позаботиться обо всех потребностях?

Если ответ «это зависит», то:

  • У меня большая база данных (размер сжатого дампа 30 ГиБ, каталог данных 200 ГиБ)
  • Я делаю ETL в базу данных, импортируя около 3 миллионов строк в неделю
  • Все таблицы с наиболее частыми изменениями унаследованы от основной таблицы, в основной таблице нет данных (данные разбиты по неделям)
  • Я создаю почасовые сводки, а оттуда - ежедневные, еженедельные и ежемесячные отчеты.

Я спрашиваю, потому что график VACUUM ANALYZEвлияет на мою отчетность. Он работает более 5 часов, и мне пришлось убить его дважды на этой неделе, потому что это влияло на регулярный импорт базы данных. check_postgresне сообщает о значительном скоплении в базе данных, так что это не проблема.

Из документов autovacuum также должен позаботиться о переносе идентификатора транзакции. Вопрос стоит: мне все еще нужно VACUUM ANALYZE?

Франсуа Босолей
источник
Что ж, я бы сказал «нет», но для разработки этого ответа (например, настройки параметров автовакуума) потребуются некоторые эксперименты с репликой БД.
Дезсо

Ответы:

32

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

Эти операции могут быть отслежены с pg_stat_all_tablesучетом, в частности, n_tup_updи n_tup_delстолбцы. Кроме того, даже более конкретно, есть n_dead_tupстолбец, который сообщает, для каждой таблицы, сколько строк необходимо очистить пылесосом. (см. Контроль статистики в документе, чтобы узнать о функциях и представлениях, связанных со сбором статистики).

Возможной стратегией в вашем случае будет подавление запланированного VACUUM, отслеживание этого вида и проверка того, какие таблицы n_dead_tupзначительно повышаются. Затем примените агрессивный ВАКУУМ только к этим таблицам. Это будет победой, если есть большие таблицы, строки которых никогда не удаляются и не обновляются, а агрессивный VACUUM действительно необходим только для небольших таблиц.

Но продолжайте запуск ANALYZE, чтобы оптимизатор всегда имел свежую статистику.

Даниэль Верите
источник
4
Autovacuum также заботится о анализе. По-прежнему рекомендуется запускать АНАЛИЗ вручную между массовым обновлением / вставкой / удалением и сразу после больших запросов. +1 за добрый совет.
Эрвин Брандштеттер
Спасибо за указатель на n_dead_tup и друзей. У меня есть сводные таблицы, в которых я часто (ежечасно) уничтожаю и воссоздаю тысячи строк. Я проверю значения и составлю соответствующий график. Ответ всегда таков: «Контролируй, думай, действуй» в любом случае :)
Франсуа Босолей
25

Я не вижу в вашем вопросе ничего, о чем autovacuumбы не позаботились. Это во многом зависит от характера вашей письменной деятельности . Вы упоминаете 3 миллиона новых строк в неделю, но INSERT(или COPY), как правило, не создают раздувание таблиц и индекса. ( autovacuumнужно только следить за статистикой столбцов , картой видимости и некоторыми второстепенными заданиями). UPDATEи DELETEявляются основной причиной раздувания таблиц и индексов, особенно при нацеливании на случайные строки. Я не вижу ничего подобного в вашем вопросе.

autovacuumпрошел долгий путь и отлично работает в Postgres 9.1 или новее. Я бы посмотрел на autovacuumнастройки . Если пылесос имеет тенденцию мешать вашей рабочей нагрузке, взгляните также на «Вакуумная задержка на основе затрат» . Ручная уборка должна быть редким исключением.

Если у вас много случайных UPDATEs, вы можете установить значение FILLFACTORниже 100, чтобы сразу же разрешить горячие обновления и уменьшить потребность в них VACUUM. Подробнее о горячих обновлениях:

Также обратите внимание, что временные таблицы требуют ручного VACUUM& ANALYZE. Я цитирую руководство поCREATE TABLE :

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

Эрвин Брандштеттер
источник
6

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

Я не совсем согласен с выбором дизайна postgres для объединения вакуума и анализа. Я видел несколько случаев, когда базы данных, которые выполняют много вставок / обновлений, но мало удаляют, никогда не завершают анализ и начинают работать плохо.

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

Вы можете перейти к настройкам таблицы в графическом интерфейсе на вкладке автоматического вакуума, и вы увидите там параметры анализа, которые вы можете установить независимо от вакуума.

Настройки попадают в таблицу повторных настроек и отображаются в запросе

SELECT c.relname, c.reloptions FROM pg_class c where reloptions is not null

и значение выборки там агрессивного анализа может быть

{autovacuum_enabled=true,autovacuum_analyze_threshold=10,autovacuum_analyze_scale_factor=.01}

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

select 
    relname, 
    n_dead_tup, 
    n_tup_ins, 
    n_tup_upd, 
    n_tup_del, 
    last_autoanalyze, 
    autoanalyze_count 
from pg_stat_user_tables 
where last_autoanalyze is not null 
order by last_autoanalyze desc;
MvcCmsJon
источник
2
Если вы этого не сделаете ANALYZE, как PostgreSQL узнает, что статистика изменилась? И как вы можете определить, что это ANALYZEзанимает много времени? В то же время, хотя не совсем ясно, какой графический интерфейс вы упомянули выше, вы правы в том, что конкретные настройки для каждой таблицы могут оказаться полезными.
Дезсо