Использование ресурсных очередей

Павел Семёнов

Contents

Обзор
Начало использования ресурсных очередей
- Общая конфигурация
Ресурсная очередь по умолчанию: pg_default
Управление ресурсными очередями
Назначение ресурсных очередей ролям
Отслеживание ресурсных очередей
Управление запросами в ресурсных очередях
- Отмена запроса в очереди
- Изменение приоритета
Атрибуты и лимиты

Ресурсные очереди управляют системными ресурсами кластера Greengage DB, разделяя их на изолированные наборы ограниченного размера. Каждая ресурсная очередь устанавливает ограничения, такие как количество одновременных запросов, лимит памяти и ограничения стоимости запросов.

Когда пользователь отправляет запрос, Greengage DB помещает его в ресурсную очередь, назначенную этому пользователю. Это позволяет автоматически классифицировать и приоритизировать запросы в зависимости от ролей пользователей и типов нагрузки. Например, ресурсные очереди позволяют повысить приоритет критически важных запросов или ограничить влияние ресурсоемких запросов на работу всей системы.

Группируя запросы с похожими требованиями к ресурсам, администраторы могут управлять их параллельным выполнением, потреблением памяти и CPU без необходимости контроля на уровне отдельных запросов.

Ресурсные группы

В Greengage DB также доступны ресурсные группы — более новый и гибкий механизм управления ресурсами по сравнению с ресурсными очередями. Он предоставляет более точный контроль над CPU и памятью и рекомендуется к использованию на новых инсталляциях.

Ресурсные очереди определяют следующие аспекты обработки запросов:

Максимальное количество одновременно выполняемых запросов.
Максимальный объем используемой памяти.
Ограничение суммарной стоимости выполняемых запросов.
Приоритет очереди (влияет на распределение ресурсов CPU).

Эти лимиты подробно описаны в разделе Атрибуты и лимиты.

Когда поступает запрос, Greengage DB направляет его в ресурсную очередь, назначенную пользователю, который его инициировал. Затем проверяется, достаточно ли ресурсов в очереди для немедленного запуска запроса, на основании лимитов очереди. Для этого используются следующие лимиты:

Количество активных запросов в очереди.
Доступный объем памяти очереди.
Оценочная стоимость запросов в очереди.

Если ресурсов достаточно, запрос начинает выполняться. В противном случае он ожидает освобождения необходимых ресурсов.

Во время выполнения память и CPU выделяются запросу в соответствии с лимитами очереди. Приоритет очереди определяет, как ресурсы CPU делятся между одновременно исполняемыми запросами в разных очередях.

ПРИМЕЧАНИЕ

Ограничения ресурсных очередей не распространяются на запросы суперпользователей — они всегда выполняются без проверки лимитов.

По умолчанию ограничения ресурсных очередей применяются только к следующим типам запросов:

SELECT
SELECT INTO
CREATE TABLE AS SELECT
DECLARE CURSOR

Вы можете распространить использование очередей на DML-операции (INSERT, UPDATE, DELETE), установив параметр конфигурации resource_select_only в значение off. Это может быть полезно в окружениях, где DML-операции потребляют значительные ресурсы и требуют дополнительного контроля.

ПРИМЕЧАНИЕ

Запросы, выполняемые с помощью EXPLAIN ANALYZE, не ограничиваются лимитами ресурсных очередей. Таким образом, операции анализа производительности не блокируются.

Greengage DB использует ресурсные очереди как механизм управления ресурсами по умолчанию. Вы можете использовать их сразу или настроить их общие параметры.

Если вы ранее переключились на ресурсные группы, вы можете вернуться к использованию ресурсных очередей, установив параметр gp_resource_manager в значение queue:

$ gpconfig -c gp_resource_manager -v "queue"

Для применения изменений необходимо перезапустить кластер:

$ gpstop -r

ПРИМЕЧАНИЕ

В любой момент только одна модель управления ресурсами — ресурсные очереди или ресурсные группы — может быть активна в Greengage DB.

Следующие параметры конфигурации определяют общее поведение ресурсных очередей в Greengage DB:

max_resource_queues — максимальное количество ресурсных очередей в кластере.
max_resource_portals_per_transaction — максимальное количество одновременно открытых курсоров в рамках транзакции. Каждый открытый курсор считается активным запросом и занимает слот в соответствующей ресурсной очереди.
resource_select_only — определяет типы запросов, к которым применяются ограничения очередей; по умолчанию это только SELECT-подобные запросы. Если установлено значение off, ограничения применяются также к командам INSERT, UPDATE, DELETE.
resource_cleanup_gangs_on_wait — при включении этой опции неактивные процессы, выделенные на сегментах для выполнения запросов, ожидающих слота в ресурсной очереди, завершаются автоматически. Это может снизить нагрузку на память при наличии запросов в состоянии ожидания.
stats_queue_level — включает сбор статистики по использованию ресурсных очередей. При включении статистика доступна в представлении pg_stat_resqueues.

Существуют также параметры, которые определяют отдельные аспекты поведения очередей. Они описаны в соответствующих подразделах раздела Атрибуты и лимиты.

В Greengage DB по умолчанию существует одна ресурсная очередь — pg_default. Она автоматически назначается всем новым ролям пользователей, если явно не указана другая очередь.

Конфигурация по умолчанию для pg_default показана в таблице ниже.

Лимиты pg_default
Атрибут	Значение
ACTIVE_STATEMENTS	20
MEMORY_LIMIT	-1
PRIORITY	MEDIUM
MAX_COST	-1
COST_OVERCOMMIT	false
MIN_COST	0

Подробное описание параметров ресурсных очередей приведено в разделе Атрибуты и лимиты.

Вы можете изменить лимиты pg_default, используя команду ALTER RESOURCE QUEUE.

Для управления ресурсными очередями в Greengage DB используются следующие SQL-команды:

CREATE RESOURCE QUEUE
ALTER RESOURCE QUEUE
DROP RESOURCE QUEUE

Команда CREATE RESOURCE QUEUE создает ресурсную очередь с заданными атрибутами:

CREATE RESOURCE QUEUE <queue_name> WITH (<queue_attribute> = <value> [, ... ])

При создании очереди можно задать следующие атрибуты:

MEMORY_LIMIT — общий объем памяти, доступный суммарно всем запросам в очереди.
ACTIVE_STATEMENTS — максимальное количество одновременно активных запросов в очереди.
PRIORITY — относительный приоритет запросов из этой очереди по сравнению с другими. Допустимые значения: MIN, LOW, MEDIUM, HIGH, MAX.
MAX_COST — порог суммарной оценочной стоимости для одновременно выполняемых запросов. Если общая расчетная стоимость превышает лимит, новые запросы ожидают освобождения ресурсов.
COST_OVERCOMMIT — при задании лимита MAX_COST определяет, можно ли превышать его, если система не загружена.
MIN_COST — нижний порог оценочной стоимости: запросы со стоимостью ниже этого значения считаются легковесными. Такие запросы выполняются немедленно без проверки ограничений очереди.

ПРИМЕЧАНИЕ

Для каждой ресурсной очереди должен быть определен хотя бы один из параметров: MEMORY_LIMIT или ACTIVE_STATEMENTS.

Пример: создание очереди, в которой могут одновременно выполняться не более 15 запросов:

CREATE RESOURCE QUEUE adhoc WITH (ACTIVE_STATEMENTS = 15);

Создание очереди, допускающей до 20 одновременных запросов с общим лимитом памяти 512 МБ:

CREATE RESOURCE QUEUE reporting WITH (MEMORY_LIMIT = '512MB', ACTIVE_STATEMENTS = 20);

ВАЖНО

Стоимость запроса — это абстрактная метрика, отличающаяся в оптимизаторах GPORCA и Postgres. С учетом того, что Greengage DB может автоматически переключаться между ними, поведение MAX_COST может быть непредсказуемым. Поэтому рекомендуется не использовать ограничения по стоимости, если в этом нет острой необходимости. Подробнее см. в разделе Стоимость запросов.

Чтобы изменить лимиты существующей очереди, используйте команду ALTER RESOURCE QUEUE:

ALTER RESOURCE QUEUE <queue_name> WITH (<queue_attribute> = <value> [, ... ])

С помощью этой команды можно также задать параметры, которые не были указаны при создании очереди. Например, увеличить лимит ACTIVE_STATEMENTS и установить лимит памяти для очереди adhoc:

ALTER RESOURCE QUEUE adhoc WITH (ACTIVE_STATEMENTS = 22, MEMORY_LIMIT = '512MB');

Чтобы удалить один или несколько установленных лимитов, используйте ALTER RESOURCE QUEUE с ключевым словом WITHOUT. Пример:

ALTER RESOURCE QUEUE reporting WITHOUT (MEMORY_LIMIT);

В этом случае у очереди reporting останется только лимит ACTIVE_STATEMENTS.

Чтобы удалить ресурсную очередь, используйте команду DROP RESOURCE QUEUE:

DROP RESOURCE QUEUE <queue_name>

Пример:

DROP RESOURCE QUEUE adhoc;

Удалить ресурсную очередь можно, только если она не используется. Это означает, что:

Очередь не назначена ни одной роли.
В очереди нет выполняемых или ожидающих транзакций.

Чтобы удалить ресурсную очередь:

Завершите все запросы, использующие ресурсную очередь, с помощью pg_cancel_backend(). Подробнее см. в разделе Отмена запроса в очереди.
Отмените назначение очереди пользователям, назначив им другую очередь или установив RESOURCE QUEUE NONE.
Удалите ресурсную очередь.

Пример:

ALTER ROLE bob RESOURCE QUEUE NONE;
DROP RESOURCE QUEUE adhoc;

Чтобы назначить ресурсную очередь роли, используйте команду ALTER ROLE с выражением RESOURCE QUEUE:

ALTER ROLE alice RESOURCE QUEUE reporting;

Также можно указать ресурсную очередь при создании роли в команде CREATE ROLE:

CREATE ROLE bob RESOURCE QUEUE reporting;

Каждой роли может быть назначена только одна ресурсная очередь, при этом одна очередь может использоваться несколькими ролями.

ВАЖНО

Для эффективного управления ресурсами кластера рекомендуется назначать всем пользовательским ролям в базе данных пользовательские ресурсные очереди вместо стандартной pg_default.

Чтобы отменить назначение ресурсной очереди, используйте ALTER ROLE с выражением RESOURCE QUEUE NONE. Роль будет снова использовать очередь по умолчанию pg_default:

ALTER ROLE bob RESOURCE QUEUE NONE;

Greengage DB содержит представления системного каталога для мониторинга конфигурации, текущей загрузки и статистики ресурсных очередей. Эти представления позволяют отслеживать лимиты, активность запросов и соответствие ролей очередям.

Чтобы просмотреть все настроенные ресурсные очереди и их атрибуты, используйте представление gp_toolkit.gp_resqueue_status. Оно показывает идентификаторы и названия очередей, а также их лимиты: по числу запросов, памяти и стоимости.

SELECT queueid, rsqname, rsqcountlimit, rsqcostlimit, rsqmemorylimit
FROM gp_toolkit.gp_resqueue_status;

Пример вывода:

 queueid |  rsqname   | rsqcountlimit | rsqcostlimit | rsqmemorylimit
---------+------------+---------------+--------------+----------------
    6055 | pg_default |            21 |           -1 |             -1
   16449 | reporting  |            22 |           -1 |             -1
   16456 | adhoc      |            15 |         1000 |    2.68435e+08
(3 rows)

где:

rsqcountlimit — максимальное число одновременно выполняемых запросов в очереди.
rsqcostlimit — лимит по стоимости запроса.
rsqmemorylimit — лимит по используемой памяти в байтах.

Значение -1 означает отсутствие ограничения.

Для мониторинга текущей загрузки очередей, включая число активных и ожидающих запросов, а также использование памяти, используйте следующие представления:

gp_toolkit.gp_resqueue_status — кроме статических лимитов, показывает текущие значения использования: количество выполняемых запросов, общую оценку стоимости, потребление памяти (в байтах), число ожидающих и активных запросов.

SELECT * FROM gp_toolkit.gp_resqueue_status;

Пример вывода:

 queueid |  rsqname   | rsqcountlimit | rsqcountvalue | rsqcostlimit | rsqcostvalue | rsqmemorylimit | rsqmemoryvalue | rsqwaiters | rsqholders
---------+------------+---------------+---------------+--------------+--------------+----------------+----------------+------------+------------
    6055 | pg_default |            21 |             0 |           -1 |            0 |             -1 |              0 |          0 |          0
   16449 | reporting  |            22 |             2 |           -1 |          480 |             -1 |    2.62144e+08 |          0 |          2
   16456 | adhoc      |            15 |             0 |         1000 |            0 |    2.68435e+08 |              0 |          0 |          0
(3 rows)

где:

rsqcountvalue, rsqcostvalue и rsqmemoryvalue показывают текущее использование ресурсов.
rsqwaiters — число запросов, ожидающих слот.
rsqholders — число запросов, удерживающих слот (выполняющихся).

gp_toolkit.gp_resq_activity — отображает информацию о текущих запросах в очередях: время запуска, статус, инициатор. Полезно для определения пользователей, использующих значительные ресурсы.

SELECT * FROM gp_toolkit.gp_resq_activity;

Пример вывода:

 resqprocpid | resqrole | resqoid | resqname  |           resqstart           | resqstatus
-------------+----------+---------+-----------+-------------------------------+------------
        3460 | charlie  |   16449 | reporting | 2025-08-04 10:25:48.318273+00 | running
        3351 | alice    |   16449 | reporting | 2025-08-04 10:25:53.574034+00 | running
(2 rows)

gp_toolkit.gp_resq_activity_by_queue — агрегирует активность по очередям. Показывает число выполняющихся запросов в каждой очереди, время последнего запуска и текущий статус. Полезно для мониторинга активности в очередях и выявления перегруженных очередей.
```
SELECT * FROM gp_toolkit.gp_resq_activity_by_queue;
```
Пример вывода:
```
 resqoid | resqname  |           resqlast            | resqstatus | resqtotal
---------+-----------+-------------------------------+------------+-----------
   16449 | reporting | 2025-08-04 10:25:53.574034+00 | running    |         2
(1 row)
```

Для сбора исторической статистики по очередям включите параметр конфигурации stats_queue_level :

SET stats_queue_level = 'on';

Учитывайте, что включение этой опции добавляет небольшую нагрузку на систему. Рекомендуется активировать ее только при необходимости длительного сбора статистики.

После включения параметра статистика ресурсных очередей доступна в системном представлении pg_stat_resqueues:

SELECT * FROM pg_stat_resqueues;

Пример вывода:

 queueid | queuename  | n_queries_exec | n_queries_wait | elapsed_exec | elapsed_wait
---------+------------+----------------+----------------+--------------+--------------
   16456 | adhoc      |              5 |              0 |           10 |            0
    6055 | pg_default |              0 |              0 |            0 |            0
   16449 | reporting  |             11 |              1 |           30 |           25
(3 rows)

где:

n_queries_exec — количество выполненных запросов.
n_queries_wait — количество запросов, находившихся в ожидании.
elapsed_exec, elapsed_wait — общее время выполнения и ожидания в секундах.

Чтобы вывести список ролей и назначенных им ресурсных очередей, используйте представление gp_toolkit.gp_resq_role:

SELECT * FROM gp_toolkit.gp_resq_role;

Пример вывода:

 rrrolname | rrrsqname
-----------+------------
 gpadmin   | pg_default
 alice     | reporting
 bob       | adhoc
 charlie   | reporting
(4 rows)

Greengage DB позволяет администраторам вручную управлять выполнением запросов в ресурсных очередях. В частности, администратор может отменять долго работающие или заблокированные запросы, а также изменять приоритеты запросов динамически.

Вы можете отменить выполняющийся или ожидающий запрос в ресурсной очереди, чтобы освободить слоты и ресурсы для других нагрузок. Чтобы получить PID транзакций, которые выполняются или ожидают в ресурсных очередях, выполните следующий запрос:

SELECT rolname,rsqname, pg_locks.pid as pid, granted,
       state, query, datname
FROM pg_roles,
     gp_toolkit.gp_resqueue_status,
     pg_locks,
     pg_stat_activity
WHERE pg_roles.rolresqueue = pg_locks.objid
  AND pg_locks.objid = gp_toolkit.gp_resqueue_status.queueid
  AND pg_stat_activity.pid = pg_locks.pid
  AND pg_stat_activity.usename = pg_roles.rolname;

Пример результата:

 rolname |  rsqname  | pid  | granted | state  |         query         | datname
---------+-----------+------+---------+--------+-----------------------+----------
 alice   | reporting | 2895 | f       | active | SELECT * FROM orders; | postgres
 charlie | reporting | 2914 | t       | active | SELECT * FROM orders; | postgres
(2 rows)

Этот вывод показывает PID и состояние запросов, которые можно отменить. Столбец granted показывает, получил ли запрос слот для выполнения (t) или все еще ожидает (f).

РЕКОМЕНДАЦИЯ

Чтобы найти запросы, ожидающие слот в ресурсной очереди, вы можете использовать представление gp_toolkit.gp_locks_on_resqueue. Запросы с lorwaiting = true находятся в ожидании ресурсов для выполнения:

SELECT *
FROM gp_toolkit.gp_locks_on_resqueue
WHERE lorwaiting = true;

Пример результата:

 lorusename | lorrsqname |  lorlocktype   | lorobjid | lortransaction | lorpid |    lormode    | lorgranted | lorwaiting
------------+------------+----------------+----------+----------------+--------+---------------+------------+------------
 alice      | reporting  | resource queue |    16449 |                |   2895 | ExclusiveLock | f          | t
(1 row)

Чтобы отменить запрос, вызовите функцию pg_cancel_backend(), передав ей PID запроса:

SELECT pg_cancel_backend(2895);

Подробнее о безопасном управлении клиентскими запросами и их остановке рассказывается в разделе Остановка клиентских запросов и процессов.

В Greengage DB можно изменять приоритет выполняющегося или ожидающего запроса в ресурсной очереди. Например, так можно повысить приоритет критичного запроса во время высокой нагрузки.

Чтобы просмотреть выполняющиеся или ожидающие запросы и их приоритеты, используйте представление gp_toolkit.gp_resq_priority_statement:

SELECT * FROM gp_toolkit.gp_resq_priority_statement;

Пример результата:

 rqpdatname | rqpusename | rqpsession | rqpcommand | rqppriority | rqpweight |                       rqpquery
------------+------------+------------+------------+-------------+-----------+------------------------------------------------------
 postgres   | alice      |         12 |          3 | HIGH        |      1000 | SELECT * FROM orders;
 postgres   | charlie    |         13 |          1 | HIGH        |      1000 | SELECT * FROM orders;
 postgres   | gpadmin    |         11 |         19 | MAX         |   1000000 | SELECT * FROM gp_toolkit.gp_resq_priority_statement;
(3 rows)

Чтобы повысить приоритет конкретного запроса, используйте функцию gp_adjust_priority(). Она принимает три аргумента:

ID сессии;
порядковый номер запроса;
целевой приоритет.

Первые два аргумента идентифицируют запрос, для которого следует изменить приоритет. Эти значения можно получить из столбцов rqpsession и rqpcommand представления gp_resq_priority_statement. Например, следующий вызов устанавливает максимальный приоритет для запроса:

SELECT gp_adjust_priority(13, 1, 'MAX');

Обратите внимание, что функция gp_adjust_priority() влияет только на указанный запрос. Она не влияет на последующие запросы от того же пользователя или в той же ресурсной очереди.

В этом разделе приводятся подробные описания лимитов ресурсных очередей в Greengage DB и соответствующих атрибутов для управления ими.

Атрибут ACTIVE_STATEMENTS определяет максимальное количество запросов, которые могут выполняться одновременно в ресурсной очереди. Когда этот лимит достигнут, новые запросы ставятся в очередь и выполняются в порядке поступления по мере завершения активных запросов.

Если для очереди не заданы лимиты памяти (MEMORY_LIMIT) и стоимости запроса (MAX_COST), ACTIVE_STATEMENTS единолично определяет, будет ли запрос выполняться или ставиться в очередь. Если какой-либо из этих лимитов установлен, запрос должен удовлетворять всем им перед началом исполнения.

Атрибут MEMORY_LIMIT определяет возможность выполнения запроса в ресурсной очереди в зависимости от доступности памяти. В его значении необходимо указать единицу изменения, например, kB, MB или GB: MEMORY_LIMIT = '2048 MB'.

При использовании ресурсных очередей общий объем памяти, доступный каждому сегменту Greengage DB, задается параметром конфигурации gp_vmem_protect_limit.

ВАЖНО

Значение gp_vmem_protect_limit указывается в мегабайтах без явного указания единиц (только числом). Например, чтобы установить лимит в 8 ГБ, укажите значение 8192:

$ gpconfig -c gp_vmem_protect_limit -v 8192

Доступная память сегмента распределяется между ресурсными очередями в соответствии с их значениями MEMORY_LIMIT. Лимит памяти очереди определяет максимальный объем памяти, который все активные запросы в очереди могут одновременно использовать на сегменте. Сумма значений MEMORY_LIMIT для всех ресурсных очередей не может превышать gp_vmem_protect_limit.

РЕКОМЕНДАЦИЯ

Рекомендуется оставлять 10–20% от размера gp_vmem_protect_limit нераспределенными между очередями для возможности выполнения непредвиденных ресурсоемких запросов.

Выделенная память каждой очереди делится на равные слоты по количеству активных запросов (ACTIVE_STATEMENTS). Каждый запрос получает один слот памяти и удерживает его во время выполнения, даже если он не использует весь объем слота.

Если ACTIVE_STATEMENTS не указан, размер слота для каждого запроса определяется параметром конфигурации statement_mem.

Параметр конфигурации statement_mem позволяет изменять лимит доступной памяти на уровне отдельного запроса, например, чтобы выделить больше памяти важному ресурсоемкому запросу.

Если у ресурсной очереди заданы оба лимита MEMORY_LIMIT и ACTIVE_STATEMENTS, увеличение statement_mem для запроса фактически уменьшает количество доступных слотов памяти. Например:

Для ресурсной очереди установлены лимиты MEMORY_LIMIT = '2 GB' и ACTIVE_STATEMENTS = 4, что создает четыре слота по 512 МБ.
Запрос со statement_mem = '768 MB' попадает в очередь и получает слот памяти указанного размера.
Еще два запроса с настройками по умолчанию попадают в очередь и получают стандартные слоты по 512 МБ.

В очереди остается 256 МБ доступной памяти, чего недостаточно для стандартного слота размером 512 МБ. Если в очередь поступит четвертый запрос, он будет ждать завершения одного из выполняющихся запросов, чтобы стало возможно выделение слота на 512 МБ.

РЕКОМЕНДАЦИЯ

Чтобы повысить производительность запросов с низкими требованиями к памяти, рекомендуется выполнять их с низким значением statement_mem:

SET statement_mem = '10 MB';

Если для очереди не задан MEMORY_LIMIT, то объем памяти, выделяемый каждому запросу, определяется только параметром statement_mem. В этом случае верхнего предела суммарного использования памяти запросами очереди нет. Важно внимательно контролировать использование памяти, чтобы предотвратить ошибки out-of-memory (OOM) и деградацию производительности.

ПРИМЕЧАНИЕ

Параметр конфигурации max_statement_mem задает верхний предел для statement_mem. Изменять его могут только суперпользователи.

Атрибут PRIORITY ресурсной очереди определяет относительную долю ресурсов CPU, выделяемых запросам в этой очереди для выполнения. Этот механизм помогает предсказуемо выполнять параллельные запросы, позволяя выделять больше CPU критичным запросам.

Есть пять возможных значений PRIORITY: MIN, LOW, MEDIUM (по умолчанию), HIGH и MAX.

В отличие от лимитов памяти или одновременных запросов, приоритет CPU применяется только в фазе выполнения запроса. Он не влияет на ожидание ресурсов в очереди, но определяет порядок распределения CPU между активными запросами во время работы.

Greengage DB постоянно оценивает приоритеты запросов и перераспределяет ресурсы CPU между выполняющимися запросами. Интервал между двумя оценками задается параметром gp_resqueue_priority_sweeper_interval. Значение по умолчанию — 1000 миллисекунд.

ПРИМЕЧАНИЕ

Примеры ниже приведены для иллюстрации общей идеи оценки приоритета. Они демонстрируют принцип изменения относительных долей CPU, а не реальные пропорции, используемые в Greengage DB.

Например, два запроса из очередей с одинаковым приоритетом (HIGH) начинают выполняться одновременно. Если других запросов нет, ресурсы CPU распределяются между ними поровну. Это делается независимо от фактических потребностей запросов в CPU; PRIORITY — единственный фактор, определяющий долю CPU.

Доли ресурсов CPU (приоритеты HIGH и HIGH)
Запрос	Приоритет	Доля CPU
Запрос 1	HIGH	50%
Запрос 2	HIGH	50%

Третий запрос из очереди с приоритетом LOW начинает выполняться, пока два запроса с приоритетом HIGH продолжают работать. Он получает меньшую долю CPU из-за более низкого приоритета. Чтобы освободить ресурсы для нового запроса, доли первых двух запросов (HIGH) уменьшаются одинаково:

Доли ресурсов CPU (приоритеты HIGH, HIGH, LOW)
Запрос	Приоритет	Доля CPU
Запрос 1	HIGH	45%
Запрос 2	HIGH	45%
Запрос 3	LOW	10%

Поступает новый запрос из очереди с приоритетом MAX. Он получает долю CPU больше, чем любой из выполняющихся запросов с более низким приоритетом. Greengage DB выделяет ему долю CPU, пропорционально уменьшая доли всех уже работающих запросов:

Доли ресурсов CPU (приоритеты HIGH, HIGH, LOW, MAX)
Запрос	Приоритет	Доля CPU
Запрос 1	HIGH	4,5%
Запрос 2	HIGH	4,5%
Запрос 3	LOW	1%
Запрос 4	MAX	90%

Общее количество ресурсов CPU, используемое всеми очередями, задается параметром gp_resqueue_priority_cpucores_per_segment. Этот параметр конфигурации является локальным, то есть может задаваться отдельно для мастера и для каждого сегмента.

Для наилучшей производительности рекомендуются следующие значения gp_resqueue_priority_cpucores_per_segment:

Мастер-хост: общее количество доступных ядер CPU.
Сегмент-хост: количество доступных ядер, разделенное на количество основных сегментов на хосте.

Например, если кластер работает на хостах с 16 ядрами и на каждом сегмент-хосте размещено четыре основных сегмента, установите:

На мастере: gp_resqueue_priority_cpucores_per_segment = 16;
На сегментах: gp_resqueue_priority_cpucores_per_segment = 4.

Обычно рекомендуется использовать все ядра CPU, доступные операционной системе, включая виртуальные ядра.

Чтобы полностью отключить приоритизацию запросов для распределения ресурсов CPU, установите параметр gp_resqueue_priority в значение off. В этом случае все значения PRIORITY игнорируются, и ресурсы CPU распределяются равномерно между выполняющимися запросами.

Оценка стоимости запроса — это приближенная оценка планировщика, показывающая ресурсоемкость выполнения запроса в условных единицах стоимости. Эти единицы отражают относительную сложность запроса, а не абсолютное потребление ресурсов.

Оценка стоимости зависит от используемого планировщика. Два доступных планировщика — Postgres и GPORCA — используют разные модели оценки, и Greengage DB может автоматически переключаться между ними в некоторых случаях. Как следствие, использование фиксированных порогов стоимости может приводить к непредсказуемому поведению.

ВАЖНО

Из-за этих различий в большинстве случаев безопаснее устанавливать ограничения по памяти (MEMORY_LIMIT) и числу одновременных запросов (ACTIVE_STATEMENTS). Используйте ограничения по стоимости только в случае конкретной необходимости.

Стоимость запроса влияет на то, будут ли запросы допущены к выполнению или освобождены от проверок ресурсной очереди:

Запросы с очень высокой стоимостью могут быть отклонены (MAX_COST).
Легковесные запросы могут обходить очередь (MIN_COST).

Атрибут MAX_COST задает максимальную суммарную оценочную стоимость запросов, которые могут одновременно выполняться в ресурсной очереди. Значение можно указывать в виде десятичного или экспоненциального числа, например:

MAX_COST = 10000
MAX_COST = 3e+10

Запросы, превышающие этот порог, отклоняются очередью, если не включено превышение лимита.

Логический атрибут COST_OVERCOMMIT позволяет выполнять в очереди запросы, превышающие MAX_COST, когда система простаивает. Если он установлен в true, запрос с высокой стоимостью может быть выполнен при наличии свободных ресурсов. Значение по умолчанию — false.

Чтобы небольшие запросы, не влияющие на работу системы, выполнялись без ожидания ресурсов, используйте атрибут MIN_COST. Он определяет максимальную оценочную стоимость запроса, считающегося легковесным. Такие запросы не подпадают под проверки лимитов очереди и выполняются немедленно.

MIN_COST можно указывать в виде десятичного или экспоненциального числа, например:

MIN_COST = 1000
MIN_COST = 5e+3

Использование ресурсных групп

Сбор статистики с помощью ANALYZE

Использование ресурсных очередей

Обзор

Лимиты ресурсных очередей

Обработка запросов в очередях

Оцениваемые выражения

Начало использования ресурсных очередей

Общая конфигурация

Ресурсная очередь по умолчанию: pg_default

Управление ресурсными очередями

Создание ресурсной очереди

Изменение ресурсной очереди

Удаление ресурсной очереди

Назначение ресурсных очередей ролям

Отслеживание ресурсных очередей

Просмотр ресурсных очередей

Просмотр использования очередей

Просмотр статистики очередей

Просмотр ресурсных очередей по ролям

Управление запросами в ресурсных очередях

Отмена запроса в очереди

Изменение приоритета

Атрибуты и лимиты

Количество одновременно выполняемых запросов

Лимит памяти

Изменение лимита памяти для отдельных запросов

Использование CPU

Оценка приоритета

Ядра CPU

Отключение приоритизации запросов

Стоимость запросов

Максимальная допустимая стоимость запроса

Исключение легковесных запросов из проверок лимитов