Этот документ описывает, как использовать группы ресурсов для управления параллелизмом транзакций, распределением ресурсов ЦП и памяти в YMatrix. После определения группы ресурсов вы можете назначить её одной или нескольким ролям базы данных для контроля ресурсов, доступных этим ролям.
YMatrix использует контролируемые группы Linux (cgroups) для управления ресурсами базы данных и Runaway для статистики, отслеживания и управления памятью.
В следующей таблице перечислены настраиваемые параметры группы ресурсов:
| Тип ограничения | Описание | Диапазон значений | Значение по умолчанию |
|---|---|---|---|
| CONCURRENCY | Максимальное количество одновременных транзакций, разрешённых в группе ресурсов, включая активные и бездействующие транзакции. | [0 - max_connection] | 20 |
| CPU_MAX_PERCENT | Максимальный процент ресурсов ЦП, которые может использовать группа ресурсов. | [1 - 100] | -1 (не задано) |
| CPU_WEIGHT | Приоритет планирования группы ресурсов. | [1 - 500] | 100 |
| CPUSET | Конкретные логические ядра ЦП (или логические потоки при гиперпоточности), зарезервированные для группы ресурсов. | Зависит от конфигурации ядер системы | -1 |
| MEMORY_QUOTA | Заданное ограничение памяти для группы ресурсов. | Целое число (МБ) | -1 (не задано, используется statement_mem в качестве лимита памяти для одного запроса) |
| MIN_COST | Минимальная стоимость плана запроса, чтобы он был включён в группу ресурсов. | Целое число | 0 |
Примечание!
Ограничения ресурсов не применяются к командамSET,RESETиSHOW.
Когда пользователь выполняет запрос, YMatrix оценивает состояние запроса на основе набора ограничений, определённых для группы ресурсов.
CONCURRENCY управляет максимальным количеством одновременных транзакций, разрешённых в группе ресурсов. Значение по умолчанию — 20; значение 0 означает, что группа ресурсов не разрешает выполнение запросов.
Если лимит ресурсов не достигнут и запрос не превысит лимит параллелизма транзакций группы, YMatrix немедленно запустит запрос. Если максимальное количество одновременных транзакций в группе достигнуто, YMatrix поставит в очередь все транзакции, отправленные после достижения группой лимита CONCURRENCY, и будет ждать завершения других запросов перед их запуском.
gp_resource_group_queuing_timeout можно использовать для указания времени ожидания перед отменой транзакции в очереди. Значение по умолчанию — 0, что означает неограниченное ожидание.
Обход ограничений выделения группы ресурсов
gp_resource_group_bypass используется для включения или отключения лимита параллелизма транзакций группы, позволяя выполнять запросы немедленно. Если установлено значение true, запрос пропустит лимит параллелизма группы. В этом случае память для запроса выделяется в соответствии с statement_mem. При недостатке памяти запрос завершится с ошибкой. Этот параметр можно задать только в рамках одной сессии и не допускается задавать внутри транзакции или функции.gp_resource_group_bypass_catalog_query определяет, пропускают ли запросы к системным таблицам ограничения ресурсов группы. Значение по умолчанию — true. Это применимо к ситуациям, когда GUI-клиенты подобных баз данных выполняют запросы каталога для получения метаданных. Их выделение ресурсов происходит вне группы ресурсов, а лимит памяти на каждый запрос составляет statement_mem.gp_resource_group_bypass_direct_dispatch управляет тем, пропускают ли прямые запросы ограничения группы ресурсов. Если установлено значение true, запрос больше не будет ограничен ресурсами ЦП и памяти, выделенными его группой, и будет выполняться немедленно. В этом случае память для запроса выделяется в соответствии с statement_mem. При недостатке памяти запрос завершится с ошибкой. Этот параметр можно задать только в рамках одной сессии и не допускается задавать внутри транзакции или функции.YMatrix распределяет ресурсы ЦП двумя способами:
Разные режимы распределения ресурсов ЦП могут быть настроены для разных групп ресурсов в одном кластере, и каждая группа ресурсов может использовать только один режим распределения ресурсов ЦП. Режим распределения ресурсов ЦП группы можно изменять во время выполнения.
Вы можете определить максимальный процент системных ресурсов ЦП, выделяемых группам ресурсов каждого узла сегмента, через gp_resource_group_cpu_limit.
Назначение ресурсов ЦП по ядрам
CPUSET используется для задания ядер ЦП, зарезервированных для группы ресурсов. При настройке CPUSET для группы YMatrix отключает CPU_MAX_PERCENT и CPU_WEIGHT группы и устанавливает их значения в -1.
Замечания по использованию:
Назначение ресурсов ЦП по проценту
CPU_MAX_PERCENT используется для установки верхнего предела ресурсов ЦП, которые может использовать сегмент. Например, установка значения 40 означает, что может использоваться не более 40% доступных ресурсов ЦП. Когда задачи в группе ресурсов бездействуют и не используют время ЦП, оставшееся время собирается в глобальный пул неиспользованных циклов ЦП, из которого другие группы ресурсов могут заимствовать циклы ЦП.
CPU_WEIGHT используется для назначения приоритета планирования текущей группы. Значение по умолчанию — 100, диапазон значений — от 1 до 500. Это значение определяет относительную долю времени ЦП, которую задачи в группе ресурсов могут получить.
Замечания по использованию:
CPU_MAX_PERCENT всех групп установлено на 100), первая группа получит 50% общего времени ЦП, а две другие — по 25%.CPU_MAX_PERCENT, установленным на 100), первая группа сможет использовать только 33% ЦП, а остальные группы получат по 16,5%, 16,5% и 33% соответственно.Пример конфигурации
| Имя группы | CONCURRENCY | CPU_MAX_PERCENT | CPU_WEIGHT |
|---|---|---|---|
| default_group | 20 | 50 | 10 |
| admin_group | 10 | 70 | 30 |
| system_group | 10 | 30 | 10 |
| test | 10 | 10 | 10 |
Роли в default_group имеют доступную долю ЦП (определяемую CPU_WEIGHT), равную 10/(10+30+10+10)=16%. Это означает, что при высокой нагрузке системы они могут использовать как минимум 16% ЦП. При наличии свободных ресурсов ЦП они могут использовать больше ресурсов, так как жёсткий лимит (заданный CPU_MAX_PERCENT) составляет 50%.
Роли в admin_group имеют доступную долю ЦП 30/(10+30+10+10)=50% при высокой нагрузке системы. При наличии свободных ресурсов ЦП они могут использовать ресурсы до жёсткого лимита 70%.
Роли в test имеют долю ЦП 10/(10+30+10+10)=16%. Однако, поскольку жёсткий лимит, определённый CPU_MAX_PERCENT, составляет 10%, они могут использовать не более 10% ресурсов даже при бездействии системы.
MEMORY_QUOTA представляет максимальный объём памяти, зарезервированный для группы ресурсов на сегменте. Это общий объём памяти, который могут потреблять все рабочие процессы запросов на сегменте во время выполнения запроса. Объём памяти, выделяемый запросу, равен лимиту памяти группы, делённому на лимит параллелизма группы: MEMORY_QUOTA / CONCURRENCY.
Если запросу требуется больше памяти, вы можете задать требуемый объём памяти на уровне сессии с помощью gp_resgroup_memory_query_fixed_mem, что переопределит и превысит память, выделенную группой ресурсов. Меры предосторожности при использовании
gp_resgroup_memory_query_fixed_mem установлен, используется заданное значение для обхода настроек группы ресурсов.gp_resgroup_memory_query_fixed_mem не установлен, используется MEMORY_QUOTA / CONCURRENCY в качестве объёма памяти, выделяемого запросу.MEMORY_QUOTA не установлен, значение памяти запроса по умолчанию равно statement_mem.gp_workfile_limit_files_per_query.Пример конфигурации
Рассмотрим группу ресурсов с именем adhoc, у которой MEMORY_QUOTA установлено в 1,5 ГБ, а CONCURRENCY — в 3. По умолчанию каждому запросу, отправленному в группу, выделяется 500 МБ памяти. Рассмотрим следующую последовательность событий:
ADHOC_1 отправляет запрос Q1, переопределяя gp_resgroup_memory_query_fixed_mem на 800 МБ. Запрос Q1 допускается в систему.ADHOC_2 отправляет запрос Q2, используя значение по умолчанию 500 МБ.Q1 и Q2 пользователь ADHOC_3 отправляет запрос Q3, используя значение по умолчанию 500 МБ.Q1 и Q2 использовали 1300 МБ из 1500 МБ группы ресурсов. Однако если в системе в какие-то моменты доступно достаточно памяти для запроса Q3, он будет работать корректно.ADHOC_4 отправляет запрос Q4, установленный на 700 МБ с помощью gp_resgroup_memory_query_fixed_mem.
Поскольку запрос Q4 обходит ограничения группы ресурсов, он будет выполнен немедленно.Особые предостережения:
gp_resource_group_bypass или gp_resource_group_bypass_catalog_query устанавливают параметры конфигурации для обхода ограничений группы ресурсов, лимит памяти запроса равен statement_mem.MEMORY_QUOTA / CONCURRENCY) < statement_mem, используется statement_mem в качестве фиксированного объёма памяти, выделяемого запросу.statement_mem равно max_statement_mem.MIN_COST используют statement_mem в качестве квоты памяти.cgroup, настроенную в вашей среде, проверив файловую систему, смонтированную по умолчанию при запуске системы:stat -fc %T /sys/fs/cgroup/Для cgroup v1 вывод будет tmpfs. Для cgroup v2 вывод будет cgroup2fs.
Если вам не нужно менять версию cgroup, просто перейдите к Настройке cgroup v1 или Настройке cgroup v2 для завершения операции настройки.
Если необходимо переключиться с cgroup v1 на v2, выполните следующую команду от имени root:
grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="systemd.unified_cgroup_hierarchy=1"vim /etc/default/grub
# add or modify: GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=1"
update-grubЕсли необходимо переключиться с cgroup v2 на v1, выполните следующую команду от имени root:
grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller"vim /etc/default/grub
# add or modify: GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=0"
update-grubЕсли вы хотите продолжить использовать cgroup v1, убедитесь, что в каждом файле memory.limit_in_bytes под /sys/fs/cgroup/memory/gpdb (включая /sys/fs/cgroup/memory/gpdb/memory.limit_in_bytes и /sys/fs/cgroup/memory/gpdb/[OID]/memory.limit_in_bytes) нет ограничений. Если они есть, выполните:
echo -1 >> memory.limit_in_bytesПосле этого перезагрузите хост, чтобы изменения вступили в силу.
Примечание!
Для редактирования этого файла необходимо использовать суперпользователя или пользователя с доступомsudo.vi /etc/cgconfig.confДобавьте следующую информацию в файл конфигурации.
group gpdb { perm { task { uid = mxadmin; gid = mxadmin; } admin { uid = mxadmin; gid = mxadmin; } } cpu { } cpuacct { } cpuset { } memory { } }Этот контент настроен с использованием CPU, CPU accounting, наборов ядер ЦП и групп управления памятью, управляемых пользователем
mxadmin.
cgroup для каждого узла кластера YMatrix.cgconfigparser -l /etc/cgconfig.conf
systemctl enable cgconfig.service
systemctl start cgconfig.servicecgroup узлаgrep cgroup /proc/mounts cgroup — /sys/fs/cgroup.tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_prio,net_cls 0 0
cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct,cpu 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/hugetlb cgroup rw,nosuid,nodev,noexec,relatime,hugetlb 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0 ls -l <cgroup_mount_point>/cpu/gpdb
ls -l <cgroup_mount_point>/cpuset/gpdb
ls -l <cgroup_mount_point>/memory/gpdbЕсли директория существует, а её владелец — mxadmin:mxadmin, это означает, что управление ресурсами базы данных YMatrix успешно настроено с использованием cgroup.
grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=1"reboot now/sys/fs/cgroup/matrixdb6.service, добавьте все необходимые контроллеры и убедитесь, что пользователь mxadmin имеет права на чтение и запись в него. mkdir -p /sys/fs/cgroup/matrixdb6.service
echo "+cpuset +io +cpu +memory" | tee -a /sys/fs/cgroup/cgroup.subtree_control
chown -R mxadmin:mxadmin /sys/fs/cgroup/matrixdb6.serviceПосле выполнения вышеуказанной команды может возникнуть ошибка «invalid parameter». Это происходит потому, что cgroup v2 не поддерживает управление процессами с реальным временем, и контроллер cpu может быть включен только тогда, когда все процессы с реальным временем находятся в корневом cgroup. В этом случае найдите все активные процессы и переместите их в корневой cgroup, прежде чем повторно включить контроллер.
mxadmin имеет права на запись в /sys/fs/cgroup/cgroup.procs. Это необходимо для перемещения процессов YMatrix из пользовательского cgroup в /sys/fs/cgroup/matrixdb6.service/ после запуска кластера, чтобы управлять службой postmaster и всеми необходимыми рабочими процессами. chmod a+w /sys/fs/cgroup/cgroup.procsПоскольку группа ресурсов вручную управляет файлом cgroup, вышеуказанные настройки станут недействительными после перезагрузки системы. Добавьте следующий скрипт bash для systemd, чтобы он автоматически запускался при загрузке системы. Выполните следующие шаги от имени root:
matrixdb6.service vim /etc/systemd/system/matrixdb6.servicematrixdb6.service следующее содержимое; если пользователь не mxadmin, замените его на соответствующего пользователя.
[Unit]
Description=Greenplum Cgroup v2 Configuration Service
[Service]
Type=simple
WorkingDirectory=/sys/fs/cgroup/matrixdb6.service
Delegate=yes
Slice=-.sliceExecCondition=bash -c '[ xcgroup2fs = x$(stat -fc "%%T" /sys/fs/cgroup) ] || exit 1' ExecStartPre=bash -ec " \ chown -R mxadmin:mxadmin .; \ chmod a+w ../cgroup.procs; \ mkdir -p helper.scope" ExecStart=sleep infinity ExecStartPost=bash -ec "echo $MAINPID > /sys/fs/cgroup/cgroup.procs;" [Install] WantedBy=basic.target
3. Перезагрузите демон `systemd` и включите службу: systemctl daemon-reload systemctl enable gpdb.service
## Включение групп ресурсов
1. Установите параметр конфигурации сервера `gp_resource_manager` в значение `"group"` gpconfig -c gp_resource_manager -v "group"
2. Перезапустите кластер базы данных YMatrix mxstop -arf
При включении любые транзакции, отправленные ролью, будут направляться в группу ресурсов, назначенную этой роли, и подчиняться ограничениям по параллелизму, памяти и CPU группы ресурсов.
YMatrix по умолчанию создает группы ресурсов для ролей с именами `admin_group`, `default_group` и `system_group`. При включении группы ресурсов любая роль, которой явно не назначена группа ресурсов, получает группу по умолчанию, соответствующую типу роли. Роль `SUPERUSER` назначается в `admin_group`, неадминистративные роли — в `default_group`, а ресурсы системных процессов — в `system_group`. При этом ни одна роль не может быть вручную назначена в `system_group`.
Каждая группа ресурсов для ролей настраивается следующим образом.
Параметр | admin_group | default_group | system_group
--- | --- | --- | ---
CONCURRENCY | 10 | 5 | 0
CPU_MAX_PERCENT | 10 | 20 | 10
CPU_WEIGHT | 100 | 100 | 100
CPUSET | -1 | -1 | -1
IO_LIMIT | -1 | -1 | -1
MEMORY_LIMIT | -1 | -1 | -1
MIN_COST | 0 | 0 | 0
## Создание группы ресурсов
Команда `CREATE RESOURCE GROUP` создаёт новую группу ресурсов. При создании группы ресурсов для роли укажите имя и шаблон выделения ресурсов CPU (ядра или проценты). Должно быть указано ограничение `CPU_MAX_PERCENT` или `CPUSET`.
**Пример использования**
Создайте группу ресурсов с именем `rgroup1`, с ограничением CPU 20, ограничением памяти 250, приоритетом CPU 500 и минимальной стоимостью 50: CREATE RESOURCE GROUP rgroup1 WITH (CONCURRENCY=20, CPU_MAX_PERCENT=20, MEMORY_QUOTA=250, CPU_WEIGHT=500, MIN_COST=50);
Здесь ограничения по CPU и памяти разделяются между всеми ролями, назначенными в `rgroup1`.
Команда `ALTER RESOURCE GROUP` обновляет ограничения групп ресурсов. ALTER RESOURCE GROUP rg_role_light SET CONCURRENCY 7; ALTER RESOURCE GROUP exec SET MEMORY_QUOTA 30; ALTER RESOURCE GROUP rgroup1 SET CPUSET '1;2,4';
> ***Примечание!***
> Значение `CONCURRENCY` для `admin_group` не может быть установлено или изменено на 0.
Команда `DROP RESOURCE GROUP` удаляет группу ресурсов. Чтобы удалить группу ресурсов для роли, она не должна быть назначена ни одной роли, и в группе не должно быть активных или ожидающих транзакций. DROP RESOURCE GROUP exec;
## Настройка автоматического завершения запросов на основе использования памяти
YMatrix поддерживает обнаружение «бегущих» запросов. Для запросов, управляемых группами ресурсов, запрос может быть автоматически завершён на основе объёма используемой памяти.
Соответствующие параметры конфигурации:
- `gp_vmem_protect_limit`: Устанавливает объём памяти, который могут потреблять все процессы postgres в активном сегменте. Если запрос превышает этот лимит, память не выделяется, и запрос завершается с ошибкой.
- `runaway_detector_activation_percent`: При включении групп ресурсов, если объём используемой памяти превышает значение `gp_vmem_protect_limit` * `runaway_detector_activation_percent`, YMatrix завершает запросы, управляемые группами ресурсов (за исключением запросов в группе `system_group`), на основе использования памяти. Завершение запросов начинается с запроса, потребляющего наибольший объём памяти, до тех пор, пока использование памяти не станет ниже указанного процента.
## Назначение групп ресурсов ролям
- Назначьте группы ресурсов ролям базы данных с помощью clauses `RESOURCE GROUP` команд `CREATE ROLE` или `ALTER ROLE`. ALTER ROLE bill RESOURCE GROUP rg_light; CREATE ROLE mary RESOURCE GROUP exec;
Группы ресурсов могут быть назначены одной или нескольким ролям. Если иерархия роли определена, группа ресурсов, назначенная родительской роли, не наследуется дочерними ролями.
- Если необходимо удалить назначение группы ресурсов для роли и назначить ей группу по умолчанию, измените назначение группы роли на `NONE`. ALTER ROLE mary RESOURCE GROUP NONE;
## Мониторинг состояния групп ресурсов
- Просмотр ограничений групп ресурсов SELECT * FROM gp_toolkit.gp_resgroup_config;
- Проверка состояния запросов в группах ресурсов SELECT * FROM gp_toolkit.gp_resgroup_status;
- Проверка использования памяти группами ресурсов на каждом хосте SELECT * FROM gp_toolkit.gp_resgroup_status_per_host;
- Просмотр групп ресурсов, назначенных ролям SELECT rolname, rsgname FROM pg_roles, pg_resgroup WHERE pg_roles.rolresgroup=pg_resgroup.oid;
- Просмотр выполняемых и ожидающих запросов групп ресурсов SELECT query, rsgname,wait_event_type, wait_event FROM pg_stat_activity;
- Отмена выполняемых или поставленных в очередь транзакций в группах ресурсов
Чтобы вручную отменить выполняемую или ожидающую транзакцию, сначала определите идентификатор процесса (pid), связанный с транзакцией. Получив идентификатор процесса, вызовите `pg_cancel_backend()`, чтобы завершить процесс.
Конкретные шаги:
- Сначала выполните следующий запрос, чтобы просмотреть информацию о процессах, связанных со всеми активными или неактивными операторами во всех группах ресурсов. Если запрос не возвращает результатов, в группах ресурсов нет выполняемых или ожидающих транзакций. SELECT rolname, g.rsgname, pid, waiting, state, query, datname FROM pg_roles, gp_toolkit.gp_resgroup_status g, pg_stat_activity WHERE pg_roles.rolresgroup=g.groupid AND pg_stat_activity.usename=pg_roles.rolname;
- Пример результата запроса sammy | rg_light | 31861 | f | idle | SELECT * FROM mytesttbl; | testdb
billy | rg_light | 31905 | t | active | SELECT * FROM topten; | testdb
- Завершение процесса транзакции SELECT pg_cancel_backend(31905); ``` ``
Примечание!
Не используйте команду операционной системыKILLдля отмены любого процесса базы данных YMatrix.
Пользователи с правами суперпользователя могут выполнить функцию gp_toolkit.pg_resgroup_move_query(), чтобы переместить выполняемый запрос из одной группы ресурсов в другую без остановки запроса. Используйте эту функцию для ускорения запросов, перемещая долгие запросы в группы ресурсов с более высокой доступностью.
Функция pg_resgroup_move_query() перемещает только указанный запрос в целевую группу ресурсов; последующие запросы остаются назначены в исходную группу.
Примечание!
Перемещать можно только активные или выполняемые запросы. Запросы, находящиеся в состоянии ожидания или простоя, не могут быть перемещены из-за ограничений по параллелизму или памяти.
Функция pg_resgroup_move_query() требует идентификатора процесса (pid) выполняемого запроса и имени группы ресурсов, в которую нужно переместить запрос.
pg_resgroup_move_query( pid int4, group_name text );Как описано в разделе «Отмена выполняемой или ожидающей транзакции в группе ресурсов», вы можете использовать представление gp_toolkit.gp_resgroup_status, чтобы получить список имён, идентификаторов и статусов каждой группы ресурсов.
При вызове функции pg_resgroup_move_query() выполняемый запрос подчиняется конфигурации целевой группы ресурсов, включая лимиты параллельных задач, лимиты памяти и т.д.
gp_resource_group_queuing_timeout, — в очередь на указанное количество миллионных секунд. pg_resgroup_move_query() пытается передать управление слотом целевому процессу, максимум gp_resource_group_move_timeout миллионных секунд. Если целевой процесс не может обработать запрос на перемещение в течение gp_resource_group_queuing_timeout времени, база данных возвращает сообщение об ошибке. pg_resgroup_move_query() отменён, но целевой процесс уже получил все свободные слоты, процесс сегмента не переместится в новую группу, а целевой процесс сохранит слоты. Это несогласованное состояние будет исправлено по завершению транзакции или при следующей команде, запланированной целевым процессом в рамках той же транзакции. После перемещения запроса невозможно гарантировать, что запросы, выполняемые в целевой группе ресурсов, не превысят квоту памяти этой группы. В этом случае один или несколько выполняемых запросов в целевой группе могут завершиться с ошибкой, включая перемещённый запрос. Вы можете минимизировать вероятность этого, зарезервировав достаточное количество групп ресурсов для совместного использования глобальной памяти.