В этом документе описано, как с помощью групп ресурсов управлять параллелизмом транзакций и распределением ресурсов ЦП и памяти в YMatrix. После определения группы ресурсов её можно назначить одной или нескольким ролям базы данных для контроля ресурсов, доступных этим ролям.
YMatrix использует управляющие группы Linux (cgroups) для управления ресурсами базы данных и применяет Runaway для учёта, отслеживания и управления памятью.
В следующей таблице перечислены настраиваемые параметры групп ресурсов
| Параметр | Описание | Диапазон значений | Значение по умолчанию |
|---|---|---|---|
| CONCURRENCY | Максимальное количество одновременных транзакций, разрешённых в группе ресурсов, включая активные и ожидающие транзакции. | [0 - максимальное количество соединений] | 20 |
| CPU_MAX_PERCENT | Максимальный процент ресурсов ЦП, которые может использовать группа ресурсов. | [1 - 100] | -1 (не включено) |
| CPU_WEIGHT | Приоритет планирования группы ресурсов. | [1 - 500] | 100 |
| CPUSET | Конкретные логические ядра ЦП (или логические потоки при гиперпоточности), зарезервированные для этой группы ресурсов. | Зависит от конфигурации ядер системы | -1 |
| MEMORY_QUOTA | Значение ограничения памяти для группы ресурсов. | Целое число (МБ) | -1 (не включено; в качестве ограничения памяти на один запрос используется statement_mem) |
| MIN_COST | Минимальная стоимость плана запроса, при которой запрос попадает в группу ресурсов. | Целое число | 0 |
| IO_LIMIT | Настраивает использование ввода-вывода на устройствах для управления максимальной пропускной способностью чтения/записи и максимальным количеством операций чтения/записи в секунду. Значение задаётся для каждого пространства таблиц. | [2 - 4294967295 or max] |
-1 |
Примечание!
Группы ресурсов не действуют для команд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 управляет тем, обходят ли запросы с прямой дистрибуцией (direct dispatch queries) ограничения группы ресурсов. При значении true при выполнении таких запросов ограничения ЦП и памяти, назначенные их группе ресурсов, не применяются, и запросы выполняются немедленно. В этом случае квота памяти запроса выделяется по statement_mem; при нехватке памяти запрос завершается ошибкой. Этот параметр можно задавать только на уровне отдельной сессии, а не внутри транзакции или функции.YMatrix распределяет ресурсы ЦП двумя способами:
В одном кластере для разных групп ресурсов можно настраивать разные режимы распределения ресурсов ЦП; одна группа ресурсов может использовать только один режим распределения ресурсов ЦП. Режим распределения ресурсов ЦП группы ресурсов можно изменять во время работы.
С помощью gp_resource_group_cpu_limit определяется максимальный процент системных ресурсов ЦП, выделяемых группам ресурсов на каждом segment-узле.
Распределение ресурсов ЦП по ядрам (Core)
CPUSET задаёт ядра ЦП, зарезервированные для группы ресурсов. При настройке CPUSET для группы ресурсов YMatrix отключает CPU_MAX_PERCENT и CPU_WEIGHT этой группы и устанавливает их значения в -1.
Замечания по использованию:
'1;1,3-4' использует core1 на master-узле и core 1, core 3 и core 4 на segment-узлах.Распределение ресурсов ЦП по процентам
CPU_MAX_PERCENT задаёт предел ресурсов ЦП, доступных segment-узлам: например, значение 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 — максимальный объём памяти, зарезервированный для этой группы ресурсов на segment-узлах. Это общий объём памяти, который могут потреблять рабочие процессы всех запросов на segment-узлах во время выполнения запросов. Объём памяти, выделяемый отдельному запросу, равен ограничению памяти этой группы, делённому на ограничение параллелизма этой группы: 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 YMatrix генерирует ошибку нехватки памяти (OOM).Пример конфигурации
Рассмотрим группу ресурсов с именем 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, Q3 может выполняться нормально.ADHOC_4 отправляет запрос Q4 со значением gp_resgroup_memory_query_fixed_mem 700 МБ.
Поскольку запрос 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 в качестве квоты памяти.IO_LIMIT ограничивает максимальную пропускную способность чтения/записи дискового ввода-вывода, выделяемую запросам определённой группы ресурсов, а также максимальное количество операций чтения/записи ввода-вывода в секунду. Это обеспечивает использование ресурсов группами с высоким приоритетом и предотвращает чрезмерное использование дисковой полосы пропускания. Значение этого параметра задаётся для каждого пространства таблиц.
Примечание!
IO_LIMITподдерживается только в Cgroup v2.
При настройке ограничений дискового ввода-вывода можно задать следующие параметры:
*, чтобы задать ограничение для всех пространств таблиц.rbps и wbps ограничивают максимальную пропускную способность чтения/записи дискового ввода-вывода в группе ресурсов, единица измерения — МБ/с. Значение по умолчанию — max, то есть без ограничений.riops и wiops ограничивают максимальное количество операций чтения/записи ввода-вывода в секунду в группе ресурсов. Значение по умолчанию — max, то есть без ограничений. Описание конфигурации
Если параметр IO_LIMIT не задан, значения по умолчанию для rbps, wpbs, riops и wiops устанавливаются в max, что означает отсутствие ограничений дискового ввода-вывода. Если заданы только некоторые значения IO_LIMIT (например, только rbps), незаданные параметры по умолчанию принимают значение max (в этом примере wbps, riops и wiops имеют значение по умолчанию max).
cgroup, настроенную в вашем окружении, просмотрев файловую систему, монтируемую по умолчанию при загрузке системы:stat -fc %T /sys/fs/cgroup/Для cgroup v1 вывод — tmpfs. Для cgroup v2 — cgroup2fs.
Начиная с 6.8.4, при использовании модуля групп ресурсов MatrixUI ручная проверка, описанная выше, не требуется: модуль автоматически определяет поддерживаемую версию групп ресурсов на узлах кластера.
Если версию 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 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 успешно настроено.
Настройте систему на монтирование cgroups-v2 по умолчанию при загрузке; сделайте это от имени root с помощью системного и служебного менеджера systemd.
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После выполнения этих команд может возникнуть ошибка недопустимого параметра. Это связано с тем, что cgroup v2 не поддерживает управление процессами реального времени: контроллер ЦП можно включить, только когда все процессы реального времени находятся в корневом cgroup. В этом случае найдите все процессы реального времени, переместите их в корневой cgroup, а затем снова включите контроллер.
Убедитесь, что у mxadmin есть права на запись в /sys/fs/cgroup/cgroup.procs. Это необходимо, чтобы после запуска кластера переместить процессы YMatrix из пользовательского каталога в /sys/fs/cgroup/matrixdb6.service/ для управления службой postmaster и всеми необходимыми вспомогательными процессами.
chmod a+w /sys/fs/cgroup/cgroup.procsПоскольку группы ресурсов управляют файлами cgroup вручную, после перезагрузки системы эти настройки перестанут действовать. Добавьте в systemd следующий bash-скрипт, чтобы он автоматически выполнялся при загрузке системы. Выполните следующие шаги от имени root:
Создайте matrixdb6.service
vim /etc/systemd/system/matrixdb6.serviceЗапишите в matrixdb6.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. Перезапустите кластер базы данных YMatrixmxstop -arf
После включения любые транзакции, отправляемые ролью, направляются в назначенную этой роли группу ресурсов и подчиняются ограничениям параллелизма, памяти и ЦП этой группы.
По умолчанию 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_MAX_PERCENT` или `CPUSET`.
**Пример использования**
Создайте группу ресурсов с именем `rgroup1`, ограничением ЦП 20, ограничением памяти 250, приоритетом ЦП 500 и минимальной стоимостью 50:CREATE RESOURCE GROUP rgroup1 WITH (CONCURRENCY=20, CPU_MAX_PERCENT=20, MEMORY_QUOTA=250, CPU_WEIGHT=500, MIN_COST=50);
При этом ограничения ЦП и памяти разделяются между всеми ролями, назначенными `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 поддерживает обнаружение Runaway. Запросы, управляемые группами ресурсов, могут автоматически завершаться в зависимости от объёма используемой ими памяти.
Связанные параметры конфигурации:
- `gp_vmem_protect_limit`: задаёт объём памяти, который могут потреблять все процессы postgres в активных экземплярах segment. Если запрос приводит к превышению этого ограничения, память не выделяется и запрос завершается ошибкой.
- `runaway_detector_activation_percent`: когда группы ресурсов включены, если использованный объём памяти превышает заданное значение `gp_vmem_protect_limit` * `runaway_detector_activation_percent`, YMatrix завершает запросы, управляемые группами ресурсов (кроме запросов в группе `system_group`), в зависимости от объёма используемой памяти. Завершение запросов начинается с запроса, потребляющего больше всего памяти, и продолжается до снижения использования памяти ниже заданного процента.
## Назначение групп ресурсов ролям
- Используйте предложение `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;
- Отмена выполняющихся или стоящих в очереди транзакций в группе ресурсов
Чтобы вручную отменить выполняющуюся или стоящую в очереди транзакцию, сначала определите идентификатор процесса (id или 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; - Пример результата запросаrolname | rsgname | pid | waiting | state | query | datname
---------+----------+---------+---------+--------+------------------------ -+---------
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() требует идентификатор процесса (id или 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() отменяется, но целевой процесс уже получил все места, segment-процесс не будет перемещён в новую группу, а целевой процесс сохранит места. Это несоответствие будет устранено при завершении транзакции или при выполнении любой следующей команды, запланированной целевым процессом в той же транзакции.После перемещения запроса нельзя гарантировать, что выполняющиеся в целевой группе ресурсов запросы не превысят квоту памяти этой группы. В этом случае один или несколько выполняющихся запросов целевой группы ресурсов, включая перемещённый запрос, могут завершиться ошибкой. Чтобы минимизировать вероятность такой ситуации, зарезервируйте достаточно глобальной разделяемой памяти для групп ресурсов.