Этот документ описывает, как использовать группы ресурсов для управления параллелизмом транзакций, распределением ресурсов ЦП и памяти в YMatrix. После определения группы ресурсов вы можете назначить её одной или нескольким ролям базы данных для контроля доступных ресурсов для этих ролей.
YMatrix использует контролируемые группы Linux (cgroups) для управления ресурсами базы данных и применяет обнаружение сбоев для учёта, отслеживания и управления памятью.
В следующей таблице перечислены настраиваемые параметры групп ресурсов:
| Параметр | Описание | Диапазон | Значение по умолчанию |
|---|---|---|---|
| CONCURRENCY | Максимальное количество одновременных транзакций, разрешённых в группе ресурсов, включая активные и неактивные транзакции. | [0 - max_connections] | 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 или max] |
-1 |
Примечание!
Группы ресурсов не применяются к командамSET,RESETилиSHOW.
Когда пользователь выполняет запрос, YMatrix оценивает состояние запроса на основе ограничений, определённых для связанной группы ресурсов.
CONCURRENCY управляет максимальным количеством одновременных транзакций, разрешённых в группе ресурсов. Значение по умолчанию — 20. Значение 0 означает, что в этой группе не могут выполняться никакие запросы.
Если лимиты ресурсов не превышены и запрос не превысит лимит параллелизма, YMatrix немедленно выполняет запрос. Если максимальный параллелизм достигнут, любая новая транзакция, отправленная после этого, помещается в очередь до завершения других запросов.
CONCURRENCY задаёт максимальное время ожидания транзакции в очереди перед отменой. Значение по умолчанию — 0, что означает неограниченное ожидание.
Обход ограничений выделения ресурсов
gp_resource_group_queuing_timeout включает или отключает ограничения параллелизма для группы ресурсов, позволяя запросам выполняться немедленно. При установке в gp_resource_group_bypass запросы обходят ограничение параллелизма. В этом случае выделение памяти следует правилу true. Если памяти недостаточно, запрос завершается с ошибкой. Этот параметр можно задавать только на уровне сессии, а не внутри транзакции или функции.statement_mem определяет, пропускают ли системные запросы к каталогам ограничения группы ресурсов. Значение по умолчанию — gp_resource_group_bypass_catalog_query. Полезно для GUI-клиентов, выполняющих метаданные. Эти запросы работают вне групп ресурсов с лимитом памяти на запрос true.statement_mem управляет тем, пропускают ли прямые запросы ограничения группы ресурсов. При установке в gp_resource_group_bypass_direct_dispatch такие запросы не ограничиваются лимитами ЦП и памяти назначенной группы и выполняются немедленно. Выделение памяти следует правилу true; если памяти недостаточно, запрос завершается с ошибкой. Этот параметр можно задавать только на уровне сессии, а не внутри транзакции или функции.YMatrix распределяет ресурсы ЦП двумя способами:
Разные режимы распределения ЦП могут быть настроены для разных групп ресурсов в одном кластере. Однако каждая группа ресурсов поддерживает только один режим одновременно. Режим распределения ЦП можно изменять во время работы.
Используйте statement_mem для определения максимального процента ресурсов ЦП, выделяемых группам ресурсов на каждом сегментном узле.
Распределение ресурсов ЦП по ядрам
gp_resource_group_cpu_limit задаёт ядра ЦП, зарезервированные для группы ресурсов. При настройке CPUSET YMatrix отключает CPUSET и CPU_MAX_PERCENT для этой группы и устанавливает их значения в CPU_WEIGHT.
Замечания по использованию:
-1 использует ядро 1 на мастере и ядра 1, 3 и 4 на сегментах.Распределение ресурсов ЦП по проценту
'1;1,3-4' задаёт верхний предел использования ЦП для сегментов. Например, установка значения 40 означает, что может использоваться до 40% доступных ресурсов ЦП. Когда задачи в группе ресурсов бездействуют, неиспользуемые циклы ЦП попадают в глобальный пул, из которого другие группы могут заимствовать.
CPU_MAX_PERCENT задаёт приоритет планирования для текущей группы. Значение по умолчанию — 100, диапазон — 1–500. Он определяет относительную долю времени ЦП, доступную задачам в группе.
Замечания по использованию:
CPU_WEIGHT = 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 |
CPU_MAX_PERCENT) имеют гарантированную долю ЦП default_group при высокой нагрузке, определяемую CPU_WEIGHT. Они могут использовать больше ресурсов при бездействии ЦП, но не более жёсткого лимита 50%, установленного 10/(10+30+10+10)=16%.16%) имеют базовую долю ЦП CPU_MAX_PERCENT при высокой нагрузке. Их максимальное использование при бездействии ограничено 70% через admin_group.30/(10+30+10+10)=50%) имеют базовую долю ЦП 70%. Однако из-за жёсткого лимита (test) в 10% они не могут превысить 10%, даже если система бездействует.10/(10+30+10+10)=16% указывает максимальный объём памяти, зарезервированный для группы ресурсов на сегменте. Это общий объём памяти, который могут потреблять все активные запросы в группе на всех рабочих процессах сегмента. Память на запрос рассчитывается как: CPU_MAX_PERCENT / 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 YMatrix выдаёт ошибку нехватки памяти (OOM).Пример конфигурации
Рассмотрим группу ресурсов с именем adhoc, где MEMORY_QUOTA = 1,5 ГБ и statement_mem = 3. Каждому оператору по умолчанию выделяется 500 МБ. Рассмотрим следующую последовательность:
gp_workfile_limit_files_per_query отправляет запрос MEMORY_QUOTA, переопределяя CONCURRENCY на 800 МБ. Запрос ADHOC_1 принимается.Q1 отправляет запрос gp_resgroup_memory_query_fixed_mem, используя значение по умолчанию 500 МБ.Q1 и ADHOC_2 выполняются, пользователь Q2 отправляет запрос Q3, используя 500 МБ.Q1 и Q2 потребили 1300 МБ из лимита группы в 1500 МБ. Если памяти достаточно, ADHOC_3 может продолжить работу.Q1 отправляет запрос Q2 с Q3 = 700 МБ.Q3 обходит ограничения группы ресурсов, он выполняется немедленно.Особые замечания
ADHOC_4 или Q4 используются для обхода ограничений группы ресурсов, лимит памяти запроса равен 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поддерживается только на cgroup v2.
При настройке ограничения дискового ввода-вывода используйте следующие параметры:
* для применения ограничений ко всем пространствам таблиц.rbps и wbps ограничивают максимальную пропускную способность чтения и записи дискового ввода-вывода в группе ресурсов, измеряемую в МБ/с. Значение по умолчанию — max, что означает отсутствие ограничения.riops и wiops ограничивают максимальное количество операций чтения и записи в секунду в группе ресурсов. Значение по умолчанию — max, что означает отсутствие ограничения.Замечания по конфигурации
Если параметр IO_LIMIT не установлен, значения по умолчанию для rbps, wbps, riops и wiops устанавливаются в max, что означает неограниченный дисковый ввод-вывод. Если установлены только некоторые значения IO_LIMIT (например, rbps), неустановленные параметры принимают значение по умолчанию max (в этом примере wbps, riops и wiops будут иметь значение по умолчанию max).
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Затем перезагрузите хост для применения изменений.
Примечание!
Требуются права суперпользователя или пользователя с доступомmemory.limit_in_bytesдля редактирования этого файла.
vi /etc/cgconfig.confДобавьте следующее в конфигурационный файл:
group gpdb {
perm {
task {
uid = mxadmin;
gid = mxadmin;
}
admin {
uid = mxadmin;
gid = mxadmin;
}
}
cpu {
}
cpuacct {
}
cpuset {
}
memory {
}
} Это настраивает CPU, учёт CPU, CPU set и memory cgroups, управляемые пользователем sudo.
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, конфигурация cgroup для управления ресурсами базы данных YMatrix успешно настроена.
Настройте систему для автоматического монтирования cgroups-v2 при загрузке через systemd от имени root:
grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=1"Перезагрузите систему для применения изменений.
reboot nowСоздайте каталог /sys/fs/cgroup/matrixdb6.service, добавьте необходимые контроллеры и обеспечьте доступ `` на чтение-запись:
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 argument». Это происходит потому, что cgroup v2 не поддерживает управление процессами реального времени, если все такие процессы не находятся в корневой cgroup. В этом случае переместите все процессы реального времени в корневую cgroup и повторно включите контроллер.
mxadmin имеет права на запись в /sys/fs/cgroup/matrixdb6.service. Это позволяет перемещать процессы YMatrix в /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.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. Перезапустите кластер базы данных YMatrix:mxstop -arf
После включения любая транзакция, отправленная ролью, будет направлена в группу ресурсов, назначенную этой роли, и будет подчиняться ограничениям на параллелизм, память и ЦП этой группы.
YMatrix по умолчанию создает группы ресурсов для ролей с именами `admin_group`, `default_group` и `system_group`. При включении групп ресурсов любая роль, не назначенная явно в группу, будет автоматически назначена в группу по умолчанию в зависимости от её функции. Роли `SUPERUSER` назначаются в `admin_group`, роли `non-administrator` — в `to 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 поддерживает обнаружение «бесполезных» запросов. Запросы, управляемые группами ресурсов, могут автоматически завершаться на основе использования памяти.
Соответствующие параметры:
- `gp_vmem_protect_limit`: Устанавливает общий объем памяти, доступный всем процессам postgres на активных сегментных экземплярах. Превышение этого лимита приводит к сбою выделения памяти и завершению запроса.
- `admin_group`: При включении групп ресурсов, если использование памяти превышает `CONCURRENCY` × `DROP RESOURCE GROUP`, 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;
- Отмена транзакций, выполняемых или ожидающих в группе ресурсов
Для ручной отмены выполняемой или ожидающей транзакции сначала определите идентификатор процесса (pid), связанный с транзакцией. После получения 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() требует идентификатора процесса (pid) выполняемого запроса и имени целевой группы ресурсов.
pg_resgroup_move_query(pid int4, group_name text);Как описано в разделе «Отмена транзакций, выполняемых или ожидающих в группе ресурсов», вы можете использовать представление gp_toolkit.gp_resgroup_status, чтобы получить список имен, ID и состояний всех групп ресурсов.
При вызове 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() отменяется, но целевой процесс уже получил слот, процесс сегмента не перемещается в новую группу, а целевой процесс сохраняет слот. Это несогласованное состояние разрешается при завершении транзакции или при отправке следующей команды целевым процессом в рамках той же транзакции.
Если целевая группа ресурсов не имеет достаточного объема доступной памяти для удовлетворения текущих требований запроса, база данных возвращает ошибку. Вы можете либо увеличить объем общей памяти, выделенный целевой группе ресурсов, либо подождать, пока завершатся некоторые выполняемые запросы, прежде чем повторно вызвать функцию.
После перемещения запроса нет гарантии, что текущие выполняемые запросы в целевой группе ресурсов останутся в пределах квоты памяти группы. В таких случаях один или несколько выполняемых запросов в целевой группе — включая перемещенный запрос — могут завершиться с ошибкой. Чтобы минимизировать этот риск, зарезервируйте достаточный объем общей памяти для группы ресурсов.