Автоочистка и раздувание

Раздувание (bloat) - это место, занятое мёртвыми версиями и пустотами, которое уже не несёт полезных данных. Оно появляется естественно: каждый UPDATE и DELETE оставляет мёртвую версию, и пока VACUUM её не уберёт, она занимает страницу.

Немного раздувания - норма и даже польза: в освободившееся место ложатся новые версии (вспомним fillfactor). Проблема начинается, когда мусора становится больше, чем живых данных. Тогда:

• таблица занимает на диске вдвое-втрое больше, чем нужно;
• последовательное сканирование читает кучу мёртвых страниц;
• индексы тоже раздуваются и хуже помещаются в кеш;
• резервные копии и репликация тащат лишние гигабайты.

Раздувание - не болезнь, а симптом: VACUUM не поспевает за темпом изменений. Лечится не разовой уборкой, а настройкой автоматики.

Autovacuum не чистит таблицу непрерывно - это было бы расточительно. Он ждёт, пока мёртвых версий накопится достаточно. «Достаточно» - это порог, который считается по формуле:

порог = autovacuum_vacuum_threshold

      + autovacuum_vacuum_scale_factor × reltuples

По умолчанию threshold = 50, scale_factor = 0.2. То есть таблица попадает под уборку, когда число мёртвых версий превысит 50 плюс 20% от числа живых строк. Для таблицы в миллион строк это 200 050 мёртвых версий - довольно много.

SELECT relname, n_live_tup, n_dead_tup,

       current_setting('autovacuum_vacuum_threshold')::int

         + current_setting('autovacuum_vacuum_scale_factor')::float

         * n_live_tup AS av_threshold

FROM pg_stat_all_tables

WHERE relname = 'bloat_demo';

Сравнивая n_dead_tup с av_threshold, можно заранее сказать, сорвётся ли autovacuum. Логика и подбор значений - в autovacuum.

Здесь скрыта типичная ловушка. scale_factor = 0.2 отлично работает для маленьких таблиц, но плохо масштабируется. Чем больше таблица, тем больше мусора нужно накопить до срабатывания - и тем дольше она живёт раздутой между уборками.

Для таблицы в 100 миллионов строк 20% - это 20 миллионов мёртвых версий, которые будут лежать мёртвым грузом, пока порог не возьмётся. Поэтому для крупных и горячих таблиц scale_factor снижают индивидуально:

ALTER TABLE big_events SET (

  autovacuum_vacuum_scale_factor = 0.02,   -- 2% вместо 20%

  autovacuum_vacuum_threshold = 1000

);

Настройка на уровне таблицы переопределяет глобальную. Это нормальный приём: горячим таблицам - агрессивный autovacuum, спокойным - дефолтный. Один общий scale_factor на всю базу почти никогда не оптимален.

Долгое время autovacuum реагировал только на мёртвые версии. Таблица, в которую только вставляют (логи, события), мёртвых версий не создаёт - и autovacuum её не трогал. А зря: её страницы не попадали в карту видимости, index-only сканы по ней не работали, и заморозка откладывалась до анти-wraparound аврала.

В PostgreSQL 13 добавили отдельный порог по вставкам:

порог = autovacuum_vacuum_insert_threshold

      + autovacuum_vacuum_insert_scale_factor × reltuples

По умолчанию insert_threshold = 1000, insert_scale_factor = 0.2. Теперь append-only таблица тоже регулярно проходит VACUUM: её страницы попадают в карту видимости и постепенно замораживаются, не дожидаясь аврала. Это одно из тех изменений, которое тихо избавило многих от периодических wraparound-страхов.

«Кажется, таблица раздулась» - не диагноз. Раздувание измеряют. Точный способ - расширение pgstattuple, которое сканирует таблицу и считает долю живых, мёртвых и свободных байт:

CREATE EXTENSION IF NOT EXISTS pgstattuple;

SELECT * FROM pgstattuple('bloat_demo');

table_len     | 1810432

tuple_count   | 2000

tuple_percent | 22.1     -- живых данных всего 22%

dead_tuple_count   | 2000

dead_tuple_percent | 22.1

free_percent  | 51.3     -- больше половины — пустота

tuple_percent около 20% при free_percent за 50% - таблица раздута вдвое-втрое. После VACUUM свободный процент вырастет (место освободилось под вставки), но table_len не уменьшится. Чтобы вернуть место ОС, нужен VACUUM FULL или переупаковка.

Подводный камень: pgstattuple сканирует таблицу целиком. На большой таблице это дорого - полное чтение всех страниц. На проде для прикидки берут облегчённый pgstattuple_approx или оценочные запросы по pg_class. Точный pgstattuple гоняют в окне, когда таблица не под пиковой нагрузкой.

Когда таблица уже раздута и место надо вернуть, в ход идёт VACUUM FULL. Он переписывает таблицу в новый файл без мусора и отдаёт старое место ОС. Звучит хорошо, но цена высокая:

• берёт ACCESS EXCLUSIVE блокировку - таблица недоступна на чтение и запись всё время операции;
• требует места на диске под вторую копию таблицы на время работы;
• перестраивает все индексы.

На большой таблице это означает многоминутный (а то и многочасовой) простой. Поэтому в проде вместо VACUUM FULL чаще берут утилиты вроде pg_repack, которые переупаковывают таблицу почти без блокировки. Но сама правильная стратегия - не доводить до раздувания, настроив autovacuum так, чтобы мусор убирался вовремя.

Autovacuum невидим, но за ним можно подсмотреть. Два инструмента:

Когда таблицу чистили в последний раз - в статистике:

SELECT relname, last_autovacuum, autovacuum_count

FROM pg_stat_all_tables

WHERE relname = 'bloat_demo';

Что прямо сейчас делает текущий проход - в прогресс-вью:

SELECT relid::regclass, phase,

       heap_blks_scanned, heap_blks_total

FROM pg_stat_progress_vacuum;

pg_stat_progress_vacuum показывает фазу (сканирование таблицы, очистка индексов, и т.д.) и прогресс по блокам. По нему видно, не застрял ли VACUUM на гигантской таблице и на какой фазе он сейчас. А в логе сервера при log_autovacuum_min_duration = 0 каждый проход оставляет подробную запись - что и сколько убрано.

Самый вредный совет в мире PostgreSQL звучит так: «autovacuum съедает ресурсы и мешает нагрузке, отключи его». Логика кажется разумной - и ведёт прямиком в катастрофу.

Что произойдёт после autovacuum = off:

• мёртвые версии перестанут убираться - раздувание поползёт вверх;
• горизонт заморозки замрёт - возраст таблиц начнёт расти к 200 млн;
• в какой-то момент сработает анти-wraparound autovacuum (он запускается даже при выключенном autovacuum), но уже как аврал, на пиковой нагрузке, в самый неудобный момент;
• если и его «оптимизировать» отключением - база однажды встанет с отказом выдавать xid, и спасёт только single-user VACUUM.

Правильный ответ на «autovacuum мешает» - не выключить его, а настроить: повысить autovacuum_max_workers, снизить autovacuum_vacuum_cost_delay, задать индивидуальные scale_factor горячим таблицам. Чем активнее база пишет, тем агрессивнее должна быть автоматика - а не наоборот.