Обслуживание
Тема дорожной карты · PostgreSQL
Обслуживание с помощью VACUUM в PostgreSQL — непрерывный процесс выполнения VACUUM, VACUUM ANALYZE и VACUUM FULL для управления раздуванием мёртвых кортежей, поддержания актуальности статистики планировщика и предотвращения переполнения идентификаторов транзакций — критически важный аспект администрирования баз данных для любой долго работающей системы PostgreSQL. Фоновый демон autovacuum выполняет обслуживание автоматически, запускаясь на основе настраиваемых порогов в postgresql.conf (autovacuum_vacuum_threshold, autovacuum_vacuum_scale_factor) и параметров хранения на уровне таблиц; однако мониторинг активности autovacuum через pg_stat_user_tables и pg_stat_activity необходим для подтверждения того, что он справляется с интенсивностью записи. Переполнение идентификаторов транзакций — уникальная особенность PostgreSQL: каждая строка помечается идентификатором транзакции, и после примерно 2 миллиардов транзакций идентификаторы переполняются; поэтому PostgreSQL принудительно запускает агрессивную процедуру autovacuum «против переполнения» и в конечном счёте откажет в записи, если проблема не устранена. Администраторы баз данных должны отслеживать age(datfrozenxid) в pg_database и age(relfrozenxid) в pg_class для мониторинга близости каждой базы данных и таблицы к лимиту переполнения. Правильно настроенное обслуживание VACUUM — балансировка интенсивности autovacuum и его влияния на ввод-вывод с помощью параметров autovacuum_vacuum_cost_delay и autovacuum_vacuum_cost_limit — является одной из наиболее результативных долгосрочных задач настройки производительности PostgreSQL.
Как это работает
Обслуживание — цена MVCC. UPDATE и DELETE не удаляют строки — помечают dead; VACUUM возвращает место, ANALYZE обновляет статистику планировщика, REINDEX перестраивает раздутые индексы. autovacuum работает непрерывно по дефолту, но его триггеры консервативны для больших таблиц — тюньте autovacuum_vacuum_scale_factor, autovacuum_analyze_scale_factor per-table. VACUUM FULL переписывает таблицу (лочит записи!); pg_repack делает online. Смотрите pg_stat_user_tables.n_dead_tup для bloat.
Когда применять
Тюньте autovacuum агрессивно на горячих таблицах (например autovacuum_vacuum_scale_factor = 0.01 для миллион-строчных). Мониторьте bloat через pgstattuple или pgstatindex из pg_repack. pg_repack еженедельно на самых больших таблицах. Всегда ANALYZE после большой загрузки/миграции — старая статистика даёт плохие планы. Никогда VACUUM FULL под трафиком — лочит всю таблицу.
Типичные ошибки
Ловушки Обслуживание: игнор autovacuum до 100GB таблицы с 50GB dead-строк; transaction wraparound — миф 200-летней давности, реальный (SELECT datname, age(datfrozenxid) FROM pg_database); неконтролируемый index bloat (запросы медленнее со временем при том же row count); VACUUM FULL в пик (CEO позвонит). Мониторьте + alerts на bloat-метрики с первого дня.