VACUUM и горизонт транзакции

VACUUM - это сборщик мусора PostgreSQL. За один проход по таблице он делает несколько вещей:

• находит мёртвые версии строк (те, чей xmax закоммичен и старше горизонта) и помечает их указатели как переиспользуемые;
• вычищает из всех индексов записи, ведущие на эти мёртвые версии;
• обновляет Free Space Map - карту свободного места, чтобы будущие вставки знали, куда класть данные;
• обновляет Visibility Map - карту видимости, отмечая страницы, где все версии видны всем (это нужно для index-only сканов и для ускорения будущих проходов);
• продвигает горизонт заморозки relfrozenxid (об этом - глава 15).

Чего обычный VACUUM не делает - не возвращает место операционной системе. Он освобождает место внутри файлов таблицы под будущие вставки, но сам файл не сжимается. Уменьшить файл умеет только VACUUM FULL, переписывающий таблицу целиком (с тяжёлой блокировкой). Подробнее про границы и счётчики - в статье vacuum.

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

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

Горизонт - это не одно число на всю базу в простом смысле. У каждого бэкенда есть свой backend_xmin - нижняя граница того, что ему ещё может понадобиться. Глобальный горизонт уборки - это минимум по всем ним. Двигается он только вперёд и только когда старые транзакции завершаются. Полный разбор - в transaction-horizon.

Теперь ключевой сценарий. Откроем в одной сессии транзакцию и не будем её закрывать:

-- сессия A

BEGIN ISOLATION LEVEL REPEATABLE READ;

SELECT 1;   -- снимок взят, горизонт зафиксирован

-- ... и сессия молчит, транзакцию не коммитит ...

В сессии B активно работаем: обновляем строки, плодим мёртвые версии, запускаем VACUUM:

-- сессия B

UPDATE bloat_demo SET payload = repeat('z', 200);

VACUUM bloat_demo;

SELECT n_dead_tup FROM pg_stat_all_tables WHERE relname = 'bloat_demo';

И видим: n_dead_tup не падает. VACUUM отработал, но удалить ничего не смог - потому что транзакция в сессии A всё ещё активна, и её снимок мог бы потребовать старые версии. Горизонт застрял на ней.

Закроем транзакцию в A (COMMIT или ROLLBACK) и повторим VACUUM в B - мёртвые версии исчезнут. Одна забытая транзакция держала мусор всей базы.

В реальности горизонт чаще всего держит не аналитический запрос, а приложение, которое открыло транзакцию и забыло её закрыть - состояние idle in transaction. Типичная причина: код взял соединение из пула, выполнил BEGIN, сходил во внешний сервис, получил таймаут, и транзакция повисла.

Найти таких виновников можно так:

SELECT pid, state, now() - xact_start AS xact_age, query

FROM pg_stat_activity

WHERE state = 'idle in transaction'

ORDER BY xact_start;

Чем дольше xact_age, тем дальше отодвинут горизонт и тем больше мусора заперто. Поэтому в проде ставят idle_in_transaction_session_timeout

• PostgreSQL сам прибьёт транзакцию, висящую без дела дольше лимита.

Подводный камень: длинные транзакции на реплике тоже держат горизонт мастера. Если включён hot_standby_feedback, реплика сообщает мастеру, какие версии ей ещё нужны для запросов. Долгий запрос на реплике через эту обратную связь отодвигает горизонт уборки на мастере - и VACUUM на мастере не может убрать мусор, хотя локально никаких длинных транзакций нет. Удобно искать причину в pg_stat_activity и забыть про реплику.

Внутри VACUUM горизонт превращается в конкретное число - removable cutoff (исторически в коде он зовётся OldestXmin). Это самый старый xid, который ещё может понадобиться кому-либо. Правило простое:

• версия с xmax, закоммиченным и строго старше cutoff, - мёртвая и удаляемая;
• версия с xmax новее или равным cutoff - ещё может быть нужна, VACUUM её не трогает.

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

Чтобы не гадать, VACUUM умеет рассказывать о себе. Запустим с VERBOSE и разберём вывод:

VACUUM (VERBOSE) bloat_demo;

INFO:  vacuuming "lab.public.bloat_demo"

INFO:  finished vacuuming "lab.public.bloat_demo": index scans: 1

  pages: 0 removed, 89 remain, 89 scanned (100.00% of total)

  tuples: 2000 removed, 2000 remain, 0 are dead but not yet removable

  removable cutoff: 754, which was 0 XIDs old when operation ended

  ...

По строкам:

• 2000 removed - столько мёртвых версий удалено;
• 2000 remain - столько живых осталось;
• 0 are dead but not yet removable - вот это - индикатор горизонта. Это мёртвые версии, которые VACUUM нашёл, но не смог удалить, потому что они новее removable cutoff. Если здесь большое число - в базе висит старая транзакция;
• removable cutoff: 754 ... 0 XIDs old - сам cutoff и насколько он отстал от текущего момента. Большой возраст cutoff - тоже признак застрявшего горизонта.

Строка «dead but not yet removable» - это первое, что смотрят при жалобах на раздувание. Ненулевое значение почти всегда означает: ищи длинную транзакцию.

Один из побочных, но важных результатов VACUUM - обновление карты видимости (Visibility Map). Это компактная карта, где на каждую страницу таблицы приходится пара бит: «все версии в этой странице видны всем» и «все версии в этой странице заморожены».

Первый бит даёт большую оптимизацию - index-only scan. Если индекс нашёл нужные строки и карта говорит, что их страницы видны всем, PostgreSQL может вернуть данные прямо из индекса, не заглядывая в таблицу. Без VACUUM этот бит не выставляется, и index-only scan вырождается в обычный с обращением к таблице.

Поэтому VACUUM полезен не только для уборки мусора: он буквально ускоряет чтение, поддерживая карту видимости в актуальном состоянии. К index-only сканам и роли карты видимости мы вернёмся в части про индексы.

В обычной жизни VACUUM запускает автоматика - autovacuum (глава 16). Вручную его дёргают в нескольких ситуациях:

• после массового DELETE/UPDATE, когда хочется убрать мусор немедленно, не дожидаясь порога autovacuum;
• перед снятием статистики (VACUUM ANALYZE), чтобы планировщик работал на свежих данных;
• при диагностике - VACUUM (VERBOSE), чтобы прочитать строку «dead but not yet removable» и понять, держит ли кто-то горизонт.

Чего точно не стоит делать в проде по привычке - VACUUM FULL на живой таблице. Он переписывает её целиком под эксклюзивной блокировкой: никто не сможет ни читать, ни писать, пока он не закончит. Об этом и об измерении раздувания - в главе 16.