Получите консультацию
Управление нагрузкой и настройка кластера Arenadata DB
Кластер greenplum редко используется одной командой ради одной задачи. Ночью по нему проходит ETL-загрузка, утром — регламентные отчёты, днём — аналитики с ad-hoc запросами в BI-инструменте. Без явных правил все они конкурируют за одни и те же CPU, память и диск, и в проигрыше обычно оказывается самый важный процесс — например, ETL, который должен был закончиться до открытия офиса. Greenplum оптимизация нагрузки начинается не с индексов и не с ключа дистрибуции, а с того, что кластеру явно указывают, кому и сколько ресурсов доступно.
В статье разберём разницу между Resource Queues и Resource Groups, как настраивать greenplum роли и лимиты, как управлять этим через Arenadata Cluster Manager и как следить за нагрузкой через системные представления.
В статье разберём разницу между Resource Queues и Resource Groups, как настраивать greenplum роли и лимиты, как управлять этим через Arenadata Cluster Manager и как следить за нагрузкой через системные представления.
Greenplum архитектура: зачем управлять ресурсами СУБД
База данных greenplum — MPP-система shared nothing: запрос выполняется параллельно на всех сегментах, и без ограничений один тяжёлый ad-hoc запрос аналитика способен занять память и CPU на каждом сегменте одновременно, вытеснив десятки более лёгких, но более важных для бизнеса запросов. В обычной однопроцессной СУБД такая проблема касается одного сервера, в MPP-архитектуре гринплам она немедленно масштабируется на весь кластер.
Управление ресурсами в Greenplum решает три задачи: ограничивает число одновременно выполняющихся тяжёлых запросов, распределяет CPU и память между разными группами пользователей и предотвращает ситуацию, когда один сбойный или неоптимальный запрос кладёт весь кластер. Субд greenplum предлагает для этого два независимых механизма — очереди ресурсов и ресурсные группы.
Greenplum архитектура: зачем управлять ресурсами СУБД
Это два поколения одной и той же подсистемы: первое — простое и грубое, второе — точное и построенное поверх стандартных механизмов ядра Linux.
Очереди ресурсов (Resource Queues)
Resource Queues — исходный механизм управления нагрузкой в Greenplum. Очередь ограничивает количество одновременно активных запросов и доступную им память, но не управляет CPU напрямую — это административный контроль допуска, а не приоритизация в реальном времени.
CREATE RESOURCE QUEUE etl_queue
WITH (ACTIVE_STATEMENTS=5, MEMORY_LIMIT='4GB');
ALTER ROLE etl_user RESOURCE QUEUE etl_queue;Ограничение Resource Queues в том, что запрос либо допущен к выполнению, либо ждёт в очереди целиком — тонко разделить CPU между уже выполняющимися запросами эта модель не может. Приоритет между уже запущенными запросами внутри очереди можно грубо регулировать через gp_resqueue_priority, но это скорее подсказка планировщику ОС, чем жёсткая гарантия.
Ресурсные группы Greenplum (Resource Groups)
Resource Groups — механизм по умолчанию в современных версиях Greenplum, построенный на cgroups ядра Linux. Группа задаёт не только допуск, но и долю CPU и памяти, которую получат все запросы её участников, включая приоритизацию уже во время выполнения, а не только на входе.
CREATE RESOURCE GROUP etl_group
WITH (CPU_RATE_LIMIT=30, MEMORY_LIMIT=40, CONCURRENCY=10);
ALTER ROLE etl_user RESOURCE GROUP etl_group;Поскольку cgroups управляют CPU на уровне ядра ОС, группа реально ограничивает потребление ресурсов в моменте, а не просто решает, пускать запрос или нет. Это и есть главное отличие Resource Groups от Resource Queues, из-за которого Arenadata и сообщество Greenplum рекомендуют переходить на группы во всех новых кластерах.
Как распределяются мощности: Greenplum роли и лимиты
Практическая настройка обычно начинается с выделения 3-4 ролей под типовые нагрузки: admin — минимальный, но гарантированный набор ресурсов для служебных операций; etl — высокий MEMORY_LIMIT для больших батчевых загрузок, но CPU_RATE_LIMIT можно снижать в рабочие часы; analytics — заметный CONCURRENCY для множества параллельных, но лёгких BI-запросов, при умеренном MEMORY_LIMIT на каждый.
Пример распределения CPU, памяти и конкурентности между ролями admin / ETL / analytics
Проверить, к какой группе относится текущая сессия, или временно переключиться для тестов можно через set role greenplum:
SET ROLE etl_user;
SHOW gp_resource_manager;После назначения greenplum role пользователю новые сессии автоматически подчиняются лимитам группы — менять привилегии на лету для уже открытых соединений нельзя, требуется новое подключение. На практике лимиты подбирают итеративно: выставляют консервативные значения, смотрят по представлениям gp_toolkit, упирается ли группа в лимит в часы пиковой нагрузки, и постепенно донастраивают CPU_RATE_LIMIT и MEMORY_LIMIT под реальный, а не предполагаемый профиль запросов.
Настройка управления через Arenadata Cluster Manager (ADCM)
Arenadata adcm — веб-интерфейс и API для развёртывания и администрирования кластеров Arenadata, включая Arenadata DB Greenplum. Вместо ручной правки postgresql.conf на каждом хосте и перезапуска сервиса, greenplum setting для менеджера ресурсов (gp_resource_manager) и параметры конкретных групп настраиваются через конфигурационную вкладку сервиса — изменения применяются централизованно на все узлы кластера.
Мониторинг ресурсов и Greenplum статистика
Текущее состояние групп видно через системные представления: gp_toolkit.gp_resgroup_config показывает лимиты каждой группы, а gp_toolkit.gp_resgroup_status — что происходит прямо сейчас: сколько запросов выполняется, сколько ждёт в очереди, сколько памяти реально занято.
SELECT groupname, cpu_rate_limit, memory_limit
FROM gp_toolkit.gp_resgroup_config;
groupname | cpu_rate_limit | memory_limit
-----------+----------------+--------------
etl_group | 30 | 40
analytics | 20 | 25Лимиты ресурсных групп не заменяют базовую гигиену DWH: если greenplum статистика по таблицам устарела, планировщик будет строить неоптимальные планы независимо от того, сколько CPU выделено группе, — мониторинг стоит вести по обоим направлениям сразу, а не только по загрузке cgroups.
Администрирование Arenadata DB Greenplum от ДБ-Сервис
Развести роли, очереди и группы по кластеру, где годами копилась разнородная нагрузка, вручную — работа не на один день: нужно понять, кто и как реально использует кластер, прежде чем резать лимиты. Специалисты администрирования и аудита Greenplum и Arenadata DB от DB Serv настраивают ресурсные группы под реальный профиль нагрузки, переносят кластеры с устаревших Resource Queues на Resource Groups и внедряют мониторинг, который заранее показывает, что группа скоро упрётся в лимит.
Краткие выводы
- Resource Queues допускают или откладывают запрос целиком, но не управляют CPU в реальном времени.
- Resource Groups построены на cgroups и ограничивают CPU и память уже во время выполнения запроса.
- Типовая схема ролей — admin, etl и analytics — с разными CPU_RATE_LIMIT, MEMORY_LIMIT и CONCURRENCY.
- Arenadata Cluster Manager позволяет менять параметры менеджера ресурсов централизованно, без правки конфигов на каждом хосте.
- Текущую нагрузку групп показывают gp_toolkit.gp_resgroup_config и gp_toolkit.gp_resgroup_status.
- Лимиты ресурсных групп не заменяют актуальную статистику таблиц — оба параметра нужно мониторить вместе.
Частые вопросы по теме
Начать стоит с перехода на Resource Groups, если кластер всё ещё работает на Resource Queues, — это даёт реальный контроль CPU, а не только допуск запросов. Дальше роли распределяются по фактическому профилю нагрузки: ETL получает высокий MEMORY_LIMIT, аналитика — высокий CONCURRENCY, а лимиты периодически пересматриваются по данным gp_toolkit.gp_resgroup_status.
Это отдельный вопрос об архитектуре, не о ресурсных группах: кардинальность столбца, его участие в JOIN-ах и равномерность значений определяют, подойдёт ли DISTRIBUTED BY, RANDOMLY или REPLICATED. Мы разбирали это подробно в статье о выборе ключа дистрибуции в Greenplum — если управление ресурсами уже настроено, а тормозят конкретные JOIN-ы, дело почти наверняка именно в ключе дистрибуции, а не в лимитах группы.
Проще всего — прямой запрос SHOW gp_resource_manager: значение queue означает Resource Queues, group — Resource Groups. Дополнительно можно проверить заполненность каталогов gp_toolkit.gp_resqueue_status и gp_toolkit.gp_resgroup_status — непустым окажется только тот, что соответствует активному менеджеру ресурсов.
Требуется профессиональный аудит и администрирование Arenadata DB (Greenplum)?
Выявим причины падения производительности, настроим управление нагрузкой (Resource Groups) и обеспечим 100% контроль над ресурсами вашего кластера Arenadata DB.
Эксперт ДБ-сервис
Заявка на администрирование или аудит Greenplum от DB Serv
Наши топ-3 компетенции по Arenadata DB
Каждое из наших направлений создано для того, чтобы ваше хранилище данных работало на максимальной скорости, а бизнес развивался без сбоев и непредсказуемых рисков.
-
Глубокий анализ производительности вашего хранилища данных. Выявляем узкие места в архитектуре, проверяем «тяжелые» запросы и ключи дистрибуции. Предоставляем четкие рекомендации и пошаговый план оптимизации кластера. -
Комплексное техническое сопровождение кластера. Грамотно распределяем ресурсы (Resource Groups), обеспечиваем бесперебойную работу ночных ETL-загрузок и дневной аналитики. -
Применяем системный и прозрачный подход. Понятный процесс работы: от детального сбора метрик конфигурации до профилирования нагрузки. Внедряем лучшие инженерные практики для выхода на новый уровень надежности.
Еще статьи по теме