Зачем нужна автоматическая очистка таблиц системного каталога Greenplum, почему команда AUTOVACUUM выполняется локально на каждом сегменте и как ее настроить для максимальной эффективности старых кортежей в распределенной базе данных с массовой-параллельной обработкой.
Параметры автоматической очистки в Greenplum
О том, зачем нужна команда автоочистки в Greenplum и как она работает, мы уже рассказывали здесь. Однако, помимо периодического запуска этой команды сборки мусора, для ее эффективного применения команду VACUUM надо правильно настроить. При этом важно найти баланс: поскольку автоочистка – довольно ресурсоемкий процесс, ее не стоит запускать часто. Но слишком редкие запуски тоже могут привести снижению производительности из-за роста таблицы системного каталога, где хранятся данные о выполнении DDL-команд. Также автоочистка поддерживает в актуальном состоянии статистику таблиц с данными, которая необходима для работы планировщика выполнения SQL-запросов.
Очистка в Greenplum не является распределенной: она запускается локально на каждом сегментах. 7-я версия Greenplum позволяет выполнять автоматическую очистку только для таблиц каталога, а не пользовательских таблиц, распределение которых заранее неизвестно и может быть неравномерным. Таблицы системного каталога распределены равномерно, поэтому вероятность того, что процесс очистки одного сегмента длится намного дольше других и блокирует транзакции всего кластера, крайне мала. Таблица системного каталога каждого отдельного сегмента обновляется, не вызывая остановки всего кластера.
Поэтому в распределенной системе автоочистка пользовательских таблиц является сложной задачей. Распределенные транзакции могут быть остановлены автоочисткой, запущенной для пользовательской таблицы в одном сегменте, что может остановить операции для всего кластера. В связи с этим автоочистка пользовательских таблиц отключена в Greenplum.
Впрочем, даже для работы с таблицами системного каталога в Greenplum есть много настроек, которые влияют на эффективность автоочистки. Например, можно задать область автоочистки с помощью команды gp_autovacuum_scope, чтобы указать типы таблиц, которые надо очистить:
- catalog — автоочистка только таблиц каталога pg_catalog;
- catalog_ao_aux — автоочистка таблиц каталога pg_catalog и вспомогательных AO-таблиц (pg_toast и pg_aoseg). Напомним, в PostgreSQL в TOAST-таблицах (The Oversized-Attribute Storage Technique) хранятся очень большие значения полей, превышающие фиксированный размер страницы (обычно 8 КБ). А в pg_aoseg-таблицах хранятся метаданные о сегментах данных таблиц, оптимизированных для добавления (AO, Append Only), включая местоположение и размер физических файлов с самими данными.
Чтобы установить предельное значение памяти для каждого рабочего процесса автоочистки, надо изменить конфигурацию autovacuum_work_mem, по умолчанию равную -1. Если autovacuum_work_mem не задано, рабочие процессы автоочистки будут возвращаться к значению maintenance_work_mem, по умолчанию равного 64 МБ. Даже если указано большее количество памяти, рабочие процессы автоочистки не будут использовать более 1 ГБ памяти. Макисмальное количество этих рабочих процессов указывается в конфигурации autovacuum_max_workers.
Автоочистка для таблицы каталога запускается, когда объем старых кортежей достигает определенного порога, заданного параметрами autovacuum_vacuum_threshold и autovacuum_vacuum_scale_factor. Также автоочистку запустит превышение максимального времени, которого может достичь поле pg_class.relfrozenxid. Это позволяет избежать зацикливания идентификатора транзакции в таблице.
В процессе автоочистки отслеживается объем выполняемой работы. Если он превышает значение autovacuum_vacuum_cost_limit, очистка приостанавливается на некоторое время, чтобы снизить влияние на производительность кластера. Длительность паузы контролируется параметром autovacuum_vacuum_cost_delay. Значение autovacuum_vacuum_cost_limit распределяется пропорционально между работающими рабочими процессами автоочистки.
Процессы автоматической очистки очень сильно влияют на производительность из-за операций дискового ввода-вывода (IO, Input/Output), поскольку выполняются параллельно с текущими задачами базы данных: запросами на чтение и запись WAL-журнала, контрольными точками и пр. Поэтому для повышения эффективности автоочистки рекомендуется задать параметрам следующие значения, чтобы команда autovacuum запускалась чаще, выполняя меньше работы по каждой таблице.
| Параметр автоочистки | Значение по умолчанию | Рекомендуемое значение | Смысл рекомендации |
| autovacuum_vacuum_threshold | 50 | 500 | Повышенное значение минимального количества обновленных или удаленных кортежей для срабатывания автоочистки позволит предотвратить ее постоянный запуск на небольших таблицах каталога |
| autovacuum_vacuum_scale_factor | 0.20 | 0,05 | Снижение фактора масштабирования до 5% от исходного размера таблицы не позволит большим таблицам слишком долго задерживать очистку, чтобы обеспечить актуальность статистики |
| autovacuum_work_mem | 64 МБ | 128 МБ | Увеличение с 64 МБ до 128 МБ позволит выполнять меньше сканирований для больших таблиц каталога |
| vacuum_cost_page_miss | 10 | 2 | IO-операции записи данных на диск более ресурсоемкие, чем операции чтения. Этот параметр означает примерную стоимость очистки буфера, который нужно прочитать с диска. Это подразумевает блокировку пула буферов, поиск в хеш-таблице, чтение требуемого блока с диска и сканирование его содержимого. В случае записи трудоемкость такой последовательность примерно в 10 раз выше, чем при чтении. |
Разобравшись с основными настройками автоочистки, далее рассмотрим лучшие практики и рекомендации ее применения.
Лучшие практики и рекомендации применения команды VACUUM
Чтобы в режиме реального времени узнать информацию об автоочистке, можно запросить следующие таблицы системного каталога:
- pg_catalog.gp_stat_progress_vacuum
- pg_catalog.gp_stat_progress_vacuum_summary
- pg_catalog.gp_stat_progress_analyze
- pg_catalog.gp_stat_progress_analyze_summary
- pg_catalog.pg_stat_all_tables
- pg_catalog.pg_stat_sys_tables
- pg_catalog.pg_stat_user_tables
Если в Greenplum включен автоматический анализ, нет необходимости явно запускать ANALYZE после загрузки или восстановления данных. Обновление статистик будет выполнено в фоновом режиме. Чтобы избежать конкуренции за ресурсы между автоматическим анализом и пользовательским запуском оператора ANALYZE, рекомендуется отслеживать ход выполнения автоанализа в пользовательских таблицах с помощью gp_stat_progress_analyze_summary.
По умолчанию утилита gpload создает, использует, а затем удаляет внешние таблицы как часть своего рабочего процесса. Эта утилита загрузки данных в Greenplum действует как интерфейс для параллельной загрузки внешних таблиц. Она выполняет загрузку, используя спецификацию, определенную в YAML-файле управления, за одну транзакцию выполняя целый набор операций, увеличивая системный каталог. Поэтому для ETL-процессов рекомендуется вместо gpload использовать gpfdist, о чем мы писали здесь.
Группы ресурсов также могут влиять на выделение ресурсов рабочим процессам автоочистки. Изменение этих значений может повлиять на все функции службы Postmaster, которая берет на себя управление процессами сегментов Greenplum, наблюдая состояние сегментов и отвечая за их перезапуск в случае сбоев. Она была впервые представлена в Greenplum версии 7.2, вышедшей в июне 2024 года. Если группы ресурсов включены, Greenplum создает три группы ресурсов по умолчанию с именами admin_group, default_group и system_group. Автоочистка, наряду с syslogger, bgwriter, checkpointer, WAL writer/receiver/archiver и stats collector, считается системным процессом, который назначается группе ресурсов system_group.
Группы ресурсов могут контролировать ограничения для дискового ввода-вывода, ЦП и памяти. В Greenplum группы ресурсов основаны на группах Linux (cgroups) для управления ресурсами ЦП и дисковым вводом-выводом. Существует две версии cgroups: cgroup v1 и cgroup v2. Greenplum 7 поддерживает обе версии, но рекомендуется использовать вторую, которая поддерживает параметр IO_LIMIT. Если группе system_group выделено недостаточно ресурсов , автоочистке придется конкурировать с другими процессами. Если ресурсов не хватает, рекомендуется для задач автоочистки сперва настроить задержку, а не производительность ввода/вывода (IOPS) или пропускной способности. Нехватка или чрезмерное выделение системных ресурсов может привести к снижению производительности. Нехватка ресурсов для рабочих процессов автоочистки или WAL-журнала может привести к остановке системы. Чрезмерное выделение ресурсов тоже чревато потерей производительности.
Поскольку процессы автоочистки запускаются локально на каждом сегменте Greenplum, они действуют независимо, причем каждый из них использует свой собственное значение параметра autovacuum_vacuum_cost_limit. Это следует учитывать, если сегменты совместно используют какие-то ресурсы, например, диски или сетевые платы, поскольку VACUUM создает значительный объем трафика ввода-вывода. Это может привести к снижению производительности для других активных сеансов.
В заключение отметим, что временные таблицы Greenplum, которые автоматически удаляются в конце сеанса или текущей транзакции, не анализируются автоматически: нужно использовать автостатистику для периодического запуска анализа временных таблиц.
Освойте администрирование и эксплуатацию Greenplum для аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
