Последняя запись в кластере параметров автовакуума и самая новая. PostgreSQL 18 представил autovacuum_worker_slots для решения давней операционной проблемы: изменение autovacuum_max_workers ранее требовало перезапуска сервера, что делало невозможным реагирование на меняющуюся рабочую нагрузку вакуума без окна обслуживания. PG 18 исправляет это, разделяя параметр на две части.
С тех пор как в PostgreSQL существует логическая репликация, правило было таковым: если вы когда-нибудь захотите её использовать, установите wal_level = logical при запуске сервера и живите с объёмом WAL вечно. Стоимость не была катастрофической, но она была постоянной. Установите один раз — платите всегда, включая 364 дня в году, когда вы не использовали ни одного логического слота.
PostgreSQL 19 меняет это. Параметр всё ещё существует. Он просто больше не совсем то, что вы установили.
autovacuum_work_mem задаёт максимальный объём памяти, который каждый рабочий процесс автовакуума может использовать для отслеживания идентификаторов мёртвых кортежей (TID — tuple identifier) во время вакуума. Значение по умолчанию: -1, что означает «унаследовать от maintenance_work_mem». Контекст параметра — sighup. Этот параметр существует для того, чтобы потребление памяти автовакуумом можно было настраивать независимо от памяти, используемой ручным VACUUM, CREATE INDEX, REINDEX и другими разовыми операциями обслуживания.
За последний год я работал в нескольких контекстах, управляя большими объёмами данных, хранящихся в формате JSONB в PostgreSQL. Сценарий обычен: пользователи ценят гибкость документо-ориентированной модели хранения, избегая необходимости предопределять схемы или постоянно мигрировать структуры таблиц по мере изменения их требований к данным. JSONB-документы могут быть глубоко вложенными с многочисленными необязательными полями и масштабироваться до сотен килобайт на запись без проблем. Однако, когда приходит время запрашивать эти документы — фильтровать по идентификатору пользователя, типу события, временным меткам или вложенным свойствам действий — запросы могут стать медленными и/или неудобными для работы.
Проблема, которую я хочу решить: «Как сделать поиск по JSONB-данным более эффективным, не разбивая наши документы и не вставляя их в столбцы реляционной базы данных?» В Postgres доступно несколько подходов, каждый со своими компромиссами. Я надеюсь пролить свет на эти подходы в этой статье.
Классическая пара параметров запуска вакуума, наконец. Последние несколько статей мы потратили на параметры, которые изменяют, ограничивают или дополняют формулу запуска, управляемую этими двумя; теперь мы добрались до оригиналов.
Когда количество устаревших кортежей (обновлённых или удалённых строк) с момента последнего вакуума превышает это значение, автовакуум планирует выполнение VACUUM для таблицы. В PostgreSQL 18 и новее результат также ограничивается параметром autovacuum_vacuum_max_threshold. Значения по умолчанию: autovacuum_vacuum_threshold = 50, autovacuum_vacuum_scale_factor = 0.2. Оба параметра имеют контекст sighup, и для каждого существуют переопределения на уровне таблицы через параметры хранения.
Полный поиск по шаблону (например, LIKE '%поисковая_фраза%') в Microsoft SQL Server может быть медленным и неэффективным, поскольку гарантируется сканирование всех строк в таблице. Имеются ли какие-нибудь варианты оптимизации запросов с оператором SQL LIKE?
Оптимизация независимого от регистра полного поиска по шаблону с начальным и конечным подстановочным знаком является проблемой в базах данных SQL - эти шаблоны LIKE не получают выгоды от индексирования. Здесь исследуются потенциальные варианты оптимизации такого поиска и проверяются распространенные заблуждения. Продолжить чтение "Оптимизация поиска при использовании SQL LIKE с подстановочными знаками"
Новинка в PostgreSQL 18. Этот параметр является первоклассным исправлением проблемы, с которой всё сообщество боролось около пятнадцати лет: на очень больших таблицах стандартная формула запуска вакуума ждёт абсурдно долго, прежде чем что-либо сделать.
При значениях по умолчанию — autovacuum_vacuum_threshold = 50 и autovacuum_vacuum_scale_factor = 0.2 — таблица на 100 миллионов строк ждёт 20 миллионов мёртвых кортежей, прежде чем запустится вакуум. Таблица на миллиард строк ждёт 200 миллионов. К моменту, когда вакуум действительно запускается, у вас уже огромное количество раздувания (bloat), сам вакуум занимает часы, а следующий запускается из такого же плохого состояния.
Классическим обходным решением (workaround) была покадровая настройка autovacuum_vacuum_scale_factor для каждой таблицы до значений вроде 0.02 или 0.005, которую мы обсудим, когда доберёмся до этих параметров в следующей статье. Это работает, но требует предварительного выявления каждой большой таблицы и назначения ей индивидуальных параметров хранения (storage parameters). Легко забыть, легко упустить, когда маленькая таблица вырастает в большую.
Эти два параметра образуют третью согласованную пару в комплекте автовакуума, после пары для ANALYZE и пары для обычного вакуума (последняя будет рассмотрена следующей). Они управляют тем, когда автовакуум запускает VACUUM для таблицы на основе количества вставок (INSERT) с момента последнего вакуума — не обновлений, не удалений, только вставок. Они были добавлены в PostgreSQL 13 и существуют для решения конкретной проблемы.
Первичный сервер PostgreSQL теряет питание в 2 часа ночи. Запись возобновляется менее чем за тридцать секунд. Дежурный инженер читает оповещение утром, видит, что кластер восстановился самостоятельно, и возвращается к кофе. Это тот результат, который должна обеспечивать высокая доступность PostgreSQL.
Работающий кластер Patroni сам по себе доводит вас лишь до половины пути. Выборы лидера работают. Резервный сервер (standby) повышается до первичного. Состояние кластера в etcd остаётся согласованным. Затем приложение продолжает пытаться подключиться к IP-адресу, который теперь указывает на неправильный узел, старый первичный сервер требует ручного повторного присоединения (rejoin), и дежурный инженер оказывается на конференц-связи, а не в постели.
Я видел этот шаблон достаточно часто, чтобы назвать его стандартным. Кластер делает свою работу. Приложение ждёт человека. Достаётся инструкция (runbook). Время восстановления (RTO) превышает соглашение об уровне обслуживания (SLA). Все соглашаются после этого, что «нам следует серьёзнее отнестись к высокой доступности».
Эти три параметра вместе задают темп работы автовакуума: как часто он запускается, как интенсивно работает во время выполнения и как долго приостанавливается, чтобы не монополизировать ваш ввод-вывод. Как и пара параметров autovacuum_analyze_*, их лучше всего понимать как единое целое.
В предыдущей статье мы видели, как каждое обновление (UPDATE) оставляет после себя мёртвый кортеж. То же поведение «копирования при записи» (copy-on-write) проявляется с операционной точки зрения в статье «DELETEs are difficult». Это плата за MVCC, и если мы имеем дело только с кучей (heap) это терпимо. Проблема в индексах.
Каждое обновление в PostgreSQL потенциально записывает данные во все индексы таблицы, даже если индексированные столбцы не изменились. Пять индексов, один обновлённый столбец? Пять лишних операций записи в индексы, пять новых записей для вакуума, в пять раз больше трафика WAL. При тысячах обновлений в секунду это становится доминирующей стоимостью работы с таблицей, в которой много обновлений.
Heap-Only Tuple (HOT) updates — это механизм PostgreSQL, позволяющий обойти эту проблему. На мой взгляд, это самое изящное оптимизационное решение в движке хранения. Давайте проследим, как именно оно работает.
Этот параметр является multixact-эквивалентом autovacuum_freeze_max_age. Механизм параллелен; защищаемый объект — не пространство идентификаторов транзакций (XID), а пространство идентификаторов MultiXact, о котором большинство пользователей PostgreSQL никогда не задумывались, а остальные узнали о нём во время аварии. Итак, перед рассмотрением параметра — краткий обзор multixact.
За годы обучения, консультирования и поддержки пользователей PostgreSQL я разработал несколько запросов для мониторинга автовакуума. Мониторинг автовакуума — не новое требование, поэтому существует уже много готовых запросов для мониторинга. Однако не все эти запросы полезны. Поэтому я подумал, что будет хорошей идеей написать статью о моей собственной коллекции — как для себя в качестве справочника, так и в качестве услуги для администраторов PostgreSQL по всему миру.
autovacuum_max_workers задаёт максимальное количество фоновых процессов автовакуума (autovacuum worker processes), которые могут выполняться одновременно. Значение по умолчанию — 3. Контекст параметра — postmaster, поэтому его изменение требует перезапуска сервера. Процесс-планировщик (launcher process) является отдельным и не учитывается в этом числе.
Это тот параметр, который кто-то увеличивает с 3 до 10, решив, что автовакуум работает слишком медленно, после чего обнаруживает, что вакуум, как ни странно, на самом деле не стал быстрее. У этого есть причина, и это самое важное, что нужно понять об этом GUC.
