8.5. Отслеживание активных процессов очистки

предлагает использовать команду VACUUM FULL,однако ее использование полностью блокирует доступ ктаблице даже на чтение,что недопустимо в производственных окружениях.В качестве альтернативы можно использовать сторонние инструменты, предлагаемые сообществом, например pg_repack1, pgcompacttable2 и pg_squeeze3. Все они имеют различные реализацию и принципы работы,но общую цель—устранить раздувание и освободить пространство.

8.5. Отслеживание активных процессов очистки

Продолжительность выполнения очистки может зависеть от разных причин: от параметров конфигурации,размеровтаблицы,количестваиндексовиколичествамертвыхстрокит.п.При обработкетаблиц и индексов очистка создаетдополнительную нагрузку на подсистему хранения и может конкурировать за ресурсы ввода-вывода с другими процессами СУБД и влиять на их производительность.Администратору важно не только знать о ходе выполнения операцийочистки,ноиоцениватьихвлияниенасистемуипредставлять,какиспользуютсяресурсы.

Для отслеживания активных процессов очистки в СУБД есть два инструмента:

•pg_stat_activity — основное представление для отслеживания всей активности в СУБД, которое показываеттакже и процессы очистки;

•pg_stat_progress_vacuum — представление, отображающее состояние и ход выполнения операций очистки (как ручных,так и автоматических).

Поскольку pg_stat_activity является представлением общего назначения и показывает активность всех процессов СУБД в некотором обобщенном виде, из него нельзя узнать особенности, характерные для конкретных процессов. Для отслеживания процессов очистки следует использовать представление pg_stat_progress_vacuum: оно содержит больше информации о работе именно очистки. Более того, оба представления можно объединить и получить максимум возможной информации.

Представление pg_stat_activity

Представление pg_stat_activity должно быть уже хорошо знакомо по предыдущим главам, поэтому не будем подробно рассматривать его,лишь перечислим интересующие нас поля:

• pid—идентификатор процесса,в рамках которого выполняется операция очистки;

1 github.com/reorg/pg_repack

2 github.com/dataegret/pgcompacttable

3 github.com/cybertec-postgresql/pg_squeeze

214Глава 8. Очистка

•backend_type—потипупроцессаможноотфильтроватьтолькотестроки,которыеотносят- ся к процессам автоочистки. Однако следует быть внимательным: по этому полю нельзя получитьочистку,запущеннуювобычномсеансеспомощьюкомандыVACUUM:утакихпроцессов значение backend_type будет равно client backend, как и у всех прочих клиентских процессов;

•datname—имя базы данных,к которой выполнено подключение и в которой выполняется очистка;

•xact_start — время начала транзакции позволяет определить продолжительность выполнения очистки. Здесь тоже есть нюанс: очистка даже одной таблицы включает в себя выполнение несколькихтранзакций,следовательно,отметка времени можетменяться.Можно было бы использовать backend_start,но рабочий процесс автоочистки за время своего существования обрабатывает множество таблиц, и выделить время, затраченное на обработку одной конкретной,становится невозможным;

•state—состояние процесса;

•wait_event, wait_event_type — события ожидания могут быть полезны на случай, если очистка приостанавливается по какой-либо причине;

•query — текст запроса является определяющим и позволяет взять только те строки, которые относятся к процессам, выполняющим очистку, неважно, автоматическую или запущенную администратором в отдельном сеансе.

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

•Сколько процессов очистки выполняется в данный момент? Это позволяет понять, не достигнуто ли ограничение количества рабочих процессов (заданное параметром autovacuum_max_workers). Если ограничение достигнуто и при этом есть необходимость в запуске дополнительных процессов автоматической очистки, это приведет к тому, что таблицы будут вынуждены ждать очереди на обработку, а мертвые строки будут продолжать накапливаться, увеличивая объем работы для очистки. Рост очереди сдвигает обработку и других таблиц, что постепенно приводит к раздуванию и увеличению размеров таблиц и индексов.

•Сколько времени длится очистка? В идеале, если позволяют ресурсы, очистка должна выполняться быстро.Наличие свободных рабочих процессов в распоряжении СУБД позволяет избегать появления очередейтаблиц на обработку.Особенно опасной может считаться ситуация, характерная для «больших» баз данных со смешанной нагрузкой (HTAP, Hybrid Transactional/Analytical Processing).Втаких базах могут встречаться кактаблицы больших размеров,так итаблицы с большим объемом записи.Первыетаблицы могуттребовать заморозки,при которойтаблица должна быть прочитана полностью,что может занять много времени, а изменения вторых будут постоянно сдвигать счетчик транзакций вперед.

При таком стечении обстоятельств (продолжительная очистка больших таблиц, активная запись и недостаток рабочих процессов очистки) СУБД не будетуспевать выполнять обработкуисдвигатьсчетчиктранзакций,чтоможетпривестикаварийномупереходуврежим только чтения.

Для получения ответов на эти вопросы достаточно использования pg_stat_activity. В тестовом окружении довольно сложно поймать продолжительную очистку, поэтому для удобства демонстрации перепишем таблицу pgbench_accounts:

# UPDATE pgbench_accounts SET abalance = abalance + 1;

В соседнем сеансе с помощью \watch 1 запустим выполнение запроса к pg_stat_activity. После выполнения запроса на обновление pgbench_accounts в течение минуты (поскольку autovacuum_naptime = 1min) запустится рабочий процесс автоочистки,который будет «пойман» запросом к pg_stat_activity.

# SELECT pid, datname,

now() - xact_start as duration, state,

wait_event_type, wait_event, query

FROM pg_stat_activity

WHERE query ~'^autovacuum' OR query ~*'^vacuum';

В запросе используется условие на текст запроса, который должен начинаться с шаблонов, характерных для рабочих процессов автоочистки и очистки, запущенной в отдельном сеансе. Такойспособболееудобен,чемусловиенаполеbackend_type,непозволяющеевыделитьочистку в обычных сеансах. Одна строка в выводе запроса указывает на то, что запущен всего один рабочий процесс. Подсчитав количество строк функцией count, можно узнать, сколько рабочих процессов очистки запущено в конкретный момент. Это позволяет ответить на первый вопрос — о количестве выполняющихся процессов. Поле duration отображает продолжительность выполнения очистки, что дает ответ на второй вопрос — о длительности. Приведенная в запросе информация о состоянии и событиях ожиданий в мониторингне собирается и чаще всего нужна только в случаях поиска и устранения проблем.