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

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

Contents

Обзор
- Ресурсные группы для ролей и внешних компонентов
- Очереди транзакций
Включение ресурсных групп
Ресурсные группы по умолчанию
Управление ресурсными группами
Назначение ресурсных групп
Отслеживание ресурсных групп
Управление транзакциями в ресурсных группах
- Перенос запроса в другую ресурсную группу
- Отмена транзакции в ресурсной группе
Атрибуты и лимиты

Ресурсные группы в Greengage DB (на основе Greenplum) определяют лимиты системных ресурсов, доступных пользователям и внешним компонентам. При отсутствии лимитов один ресурсоемкий OLAP-запрос может потреблять значительную долю CPU и памяти, нарушая работу системы для других клиентов. В типичных OLTP-нагрузках, где транзакции короткие, лимиты менее критичны, но могут улучшить стабильность системы.

Ресурсные группы управляют:

использованием ресурсов CPU (по ядрам или в процентах);
использованием памяти (локальной и разделяемой);
количеством одновременных транзакций.

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

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

Ресурсная группа может применяться к ролям или внешним компонентам, например, PL/Container.

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

Когда лимит какого-либо ресурса в ресурсной группе исчерпан, новые транзакции в этой группе ставятся в очередь, ожидая освобождения ресурсов. Транзакции в очереди обрабатываются в порядке поступления (FIFO). Если в очередь ставится ресурсоемкая транзакция, а затем приходит более легковесная, она все равно будет ждать своей очереди, даже если ресурсов достаточно для ее выполнения.

По умолчанию время нахождения транзакции в очереди не ограничено. Вы можете настроить тайм-аут, после которого транзакции в очереди будут отменяться, через параметр конфигурации gp_resource_group_queuing_timeout. Также можно вручную отменять транзакции или перемещать их между ресурсными группами, как описано в разделе Управление транзакциями в ресурсных группах.

ПРИМЕЧАНИЕ

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

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

Ресурсные группы в Greengage DB используют механизм cgroups v1 для управления потреблением CPU и памяти. Перед включением ресурсных групп убедитесь, что cgroups v1 настроен и активен на всех хостах кластера. Для проверки текущей версии cgroup выполните:

$ stat -fc %T /sys/fs/cgroup/

Возможные результаты:

tmpfs — используется cgroups v1. Дополнительных действий не требуется.
cgroup2fs — используется cgroups v2. Для работы ресурсных групп необходимо переключиться на cgroups v1.

Настройка cgroups v1

Ниже приведен пример настройки cgroups v1. В production-среде выполните настройку в соответствии с конфигурацией оборудования и операционной системы, а также с требованиями эксплуатации.

Откройте файл /etc/default/grub с правами root:
```
$ sudo vi /etc/default/grub
```
Найдите строку с GRUB_CMDLINE_LINUX_DEFAULT в начале и добавьте systemd.unified_cgroup_hierarchy=0 в список параметров.

Этот параметр загрузки ядра принудительно включает cgroups v1. Строка будет выглядеть примерно так:
```
GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 biosdevname=0 console=ttyS0 systemd.unified_cgroup_hierarchy=0"
```
Обновите конфигурацию загрузчика GRUB:
```
$ sudo update-grub
```
Перезагрузите систему.
Убедитесь, что установлен пакет libcgroup-tools (на RedHat и CentOS) или cgroup-tools (на Ubuntu). Например, на Ubuntu:
```
$ sudo apt-get install cgroup-tools
```
Создайте конфигурационный файл cgroup и откройте его для редактирования:
```
$ sudo vi /etc/cgconfig.conf
```

Вставьте следующую конфигурацию и сохраните файл:

group gpdb {
    perm {
        task {
            uid = gpadmin;
            gid = gpadmin;
        }
        admin {
            uid = gpadmin;
            gid = gpadmin;
        }
    }
    cpu {
    }
    cpuacct {
    }
    cpuset {
    }
    memory {
    }
}

Эта конфигурация дает пользователю gpadmin права управления ресурсами CPU и памятью на хосте.

Запустите сервис cgroups:

$ sudo cgconfigparser -l /etc/cgconfig.conf

При такой настройке cgroups нужно запускать вручную после каждого старта системы. Для автоматического запуска оберните его в systemd-сервис или настройте автозапуск другим удобным способом.

После настройки cgroups v1 включите использование ресурсных групп в Greengage DB, установив параметр конфигурации gp_resource_manager в group:

$ gpconfig -c gp_resource_manager -v "group"

Затем перезапустите кластер:

$ gpstop -r

В Greengage DB по умолчанию существуют две ресурсные группы:

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

Лимиты ресурсных групп admin_group и default_group приведены в таблице ниже.

Лимиты ресурсных групп по умолчанию
Атрибут	admin_group	default_group
CONCURRENCY	10	20
CPU_RATE_LIMIT	10	30
CPUSET	-1	-1
MEMORY_LIMIT	10	0
MEMORY_SHARED_QUOTA	80	80
MEMORY_SPILL_RATIO	0	0
MEMORY_AUDITOR	vmtracker	vmtracker

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

Вы можете изменить лимиты по умолчанию для admin_group и default_group с помощью команды ALTER RESOURCE GROUP.

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

CREATE RESOURCE GROUP
ALTER RESOURCE GROUP
DROP RESOURCE GROUP

Команда CREATE RESOURCE GROUP создает ресурсную группу с указанными атрибутами:

CREATE RESOURCE GROUP <group_name> WITH (<group_attribute>=<value> [, ... ])

Доступные атрибуты:

CPU_RATE_LIMIT — максимальный процент ресурсов CPU хоста, доступный группе.
CPUSET — конкретные ядра CPU, зарезервированные исключительно для группы.

ПРИМЕЧАНИЕ

Атрибуты CPU_RATE_LIMIT и CPUSET являются взаимоисключающими. В каждой ресурсной группе должен быть указан только один из них.
MEMORY_LIMIT — максимальный процент памяти системы, доступный группе. Обязателен для ресурсных групп, назначаемых внешним компонентам.
CONCURRENCY — максимальное количество одновременных транзакций в группе (активных и находящихся в очереди). В ресурсных группах для внешних компонентов CONCURRENCY должен быть равен 0.
MEMORY_SHARED_QUOTA — процент памяти группы, который может использоваться транзакциями группы совместно.
MEMORY_SPILL_RATIO — порог использования памяти для ресурсоемких SQL-запросов. При достижении этого порога создаются spill-файлы.
MEMORY_AUDITOR — способ учета потребления памяти в группе:
- vmtracker (по умолчанию) — используется в ресурсных группах для ролей.
- cgroup — используется в ресурсных группах для внешних компонентов.

Все лимиты применяются суммарно ко всем сессиям, использующим группу.

В ресурсных группах для ролей обязательно указывается либо CPU_RATE_LIMIT, либо CPUSET. Пример:

CREATE RESOURCE GROUP rg_analysts WITH (
    CPU_RATE_LIMIT = 20,
    MEMORY_LIMIT = 20,
    CONCURRENCY = 30
    );

В ресурсных группах для внешних компонентов необходимо указать CPU_RATE_LIMIT или CPUSET, а также MEMORY_LIMIT. MEMORY_AUDITOR должен быть установлен в cgroup, а CONCURRENCY = 0:

CREATE RESOURCE GROUP rg_plcontainer WITH (
    CPUSET = '1;1',
    MEMORY_LIMIT = 20,
    CONCURRENCY = 0,
    MEMORY_AUDITOR = cgroup
    );

ПРИМЕЧАНИЕ

Ресурсные группы нельзя создавать внутри транзакций.

Для изменения лимитов ресурсной группы используется команда ALTER RESOURCE GROUP:

ALTER RESOURCE GROUP <group_name> SET <group_attribute> <value>;

Команда ALTER RESOURCE GROUP может изменять только один атрибут за раз. Пример:

ALTER RESOURCE GROUP rg_analysts SET CONCURRENCY 10;

Применение новых лимитов зависит от атрибута и типа группы (для ролей или внешних компонентов):

Лимиты CPU — изменения применяются немедленно, включая переключение режима выделения CPU между CPUSET и CPU_RATE_LIMIT.
Лимиты памяти:
- В ресурсных группах для ролей новые лимиты применяются немедленно, если текущее потребление памяти не превышает новый лимит. В противном случае Greengage DB ждет, пока использование не снизится ниже нового лимита.
- В ресурсных группах для внешних компонентов поведение зависит от компонента. Увеличение лимитов обычно применяется сразу, если ресурсы доступны. При уменьшении лимита поведение определяется компонентом. Например, PL/Container может завершить контейнеры с ошибкой нехватки памяти при значительном снижении лимита.

Атрибут MEMORY_AUDITOR изменить нельзя.

Группы по умолчанию admin_group и default_group можно изменять так же, как и пользовательские ресурсные группы.

Для удаления ресурсной группы используется команда DROP RESOURCE GROUP:

DROP RESOURCE GROUP <group_name>

Ресурсная группа может быть удалена, только если она не используется. Для групп, назначаемых ролям, это означает, что:

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

Чтобы удалить ресурсную группу для ролей:

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

Пример:

ALTER ROLE bob RESOURCE GROUP NONE;
DROP RESOURCE GROUP rg_analysts;

При удалении ресурсной группы для внешних компонентов поведение зависит от реализации компонента. Для PL/Container удаление ресурсной группы немедленно останавливает все контейнеры, работающие в этой группе.

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

Чтобы назначить ресурсную группу роли, используйте ALTER ROLE с параметром RESOURCE GROUP:

ALTER ROLE alice RESOURCE GROUP rg_analysts;

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

CREATE ROLE bob RESOURCE GROUP rg_analysts;

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

ВАЖНО

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

Чтобы отменить назначение ресурсной группы, используйте команду ALTER ROLE с RESOURCE GROUP NONE. Роль будет снова использовать группу по умолчанию: admin_group для суперпользователей и default_group для обычных пользователей.

ALTER ROLE bob RESOURCE GROUP NONE;

Способ назначения ресурсных групп внешним компонентам зависит от конкретного компонента. Например, для PL/Container ресурсная группа указывается через параметр resource_group_id.

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

Представление gp_toolkit.gp_resgroup_config содержит конфигурации и лимиты всех ресурсных групп:

SELECT * FROM gp_toolkit.gp_resgroup_config;

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

 groupid |   groupname    | concurrency | cpu_rate_limit | memory_limit | memory_shared_quota | memory_spill_ratio | memory_auditor | cpuset
---------+----------------+-------------+----------------+--------------+---------------------+--------------------+----------------+--------
    6437 | default_group  | 20          | 30             | 0            | 80                  | 0                  | vmtracker      | -1
    6438 | admin_group    | 10          | 10             | 10           | 80                  | 0                  | vmtracker      | -1
   16411 | rg_plcontainer | 0           | -1             | 20           | 80                  | 0                  | cgroup         | 1;1
   16403 | rg_analysts    | 10          | 20             | 20           | 80                  | 0                  | vmtracker      | -1
(4 rows)

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

gp_toolkit.gp_resgroup_status — использование во всем кластере:

SELECT rsgname, num_running, num_queued, num_executed, total_queue_duration
FROM gp_toolkit.gp_resgroup_status;

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

    rsgname     | num_running | num_queued | num_executed | total_queue_duration
----------------+-------------+------------+--------------+----------------------
 default_group  |           0 |          0 |            0 | 00:00:00
 admin_group    |           1 |          0 |           38 | 00:00:00
 rg_analysts    |           0 |          0 |            4 | 00:00:00
 rg_plcontainer |           0 |          0 |            0 | 00:00:00
(4 rows)

Представление gp_resgroup_status также содержит столбцы cpu_usage и memory_usage с данными о текущем использовании в формате JSON:

cpu_usage: ключи — ID сегментов, значения — суммарный процент использования CPU группой на каждом сегменте.

Пример:
```
 {"-1":0.08, "0":0.03, "1":0.03, "2":0.04, "3":0.04}
```

memory_usage: ключи — ID сегментов, значения содержат метрики использования памяти, включая используемую, доступную и разделяемую память.

Пример одной пары:

  "1": {
    "used": 0,
    "available": 531,
    "quota_used": 10,
    "quota_available": 90,
    "quota_granted": 100,
    "quota_proposed": 100,
    "shared_used": 0,
    "shared_available": 431,
    "shared_granted": 431,
    "shared_proposed": 431
  }

Полный пример memory_usage

{
  "0": {
    "used": 0,
    "available": 531,
    "quota_used": 10,
    "quota_available": 90,
    "quota_granted": 100,
    "quota_proposed": 100,
    "shared_used": 0,
    "shared_available": 431,
    "shared_granted": 431,
    "shared_proposed": 431
  },
  "1": {
    "used": 0,
    "available": 531,
    "quota_used": 10,
    "quota_available": 90,
    "quota_granted": 100,
    "quota_proposed": 100,
    "shared_used": 0,
    "shared_available": 431,
    "shared_granted": 431,
    "shared_proposed": 431
  },
  "2": {
    "used": 0,
    "available": 531,
    "quota_used": 10,
    "quota_available": 90,
    "quota_granted": 100,
    "quota_proposed": 100,
    "shared_used": 0,
    "shared_available": 431,
    "shared_granted": 431,
    "shared_proposed": 431
  },
  "3": {
    "used": 0,
    "available": 531,
    "quota_used": 10,
    "quota_available": 90,
    "quota_granted": 100,
    "quota_proposed": 100,
    "shared_used": 0,
    "shared_available": 431,
    "shared_granted": 431,
    "shared_proposed": 431
  },
  "-1": {
    "used": 1,
    "available": 1596,
    "quota_used": 31,
    "quota_available": 279,
    "quota_granted": 310,
    "quota_proposed": 310,
    "shared_used": 0,
    "shared_available": 1287,
    "shared_granted": 1287,
    "shared_proposed": 1287
  }
}

gp_toolkit.gp_resgroup_status_per_host — использование по хостам. Пример:

SELECT rsgname, hostname, cpu, memory_used, memory_available
FROM gp_toolkit.gp_resgroup_status_per_host;

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

    rsgname     | hostname | cpu  | memory_used | memory_available
----------------+----------+------+-------------+------------------
 admin_group    | mdw      | 0.01 |           2 |             1595
 default_group  | sdw1     | 0.00 |           0 |                0
 rg_plcontainer | sdw2     | 0.00 |           0 |
 rg_analysts    | sdw1     | 0.00 |           0 |             2126
 admin_group    | sdw2     | 0.03 |           0 |             1062
 default_group  | sdw2     | 0.00 |           0 |                0
 admin_group    | sdw1     | 0.04 |           0 |             1062
 default_group  | mdw      | 0.00 |           0 |                0
 rg_plcontainer | mdw      | 0.00 |           0 |
 rg_analysts    | sdw2     | 0.00 |           0 |             2126
 rg_analysts    | mdw      | 0.00 |           0 |             3195
 rg_plcontainer | sdw1     | 0.00 |           0 |
(12 rows)

gp_toolkit.gp_resgroup_status_per_segment — использование по сегментам. Пример:

SELECT rsgname, hostname, segment_id, cpu, memory_used, memory_available
FROM gp_toolkit.gp_resgroup_status_per_segment
WHERE segment_id = 1;

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

    rsgname     | hostname | segment_id | cpu  | memory_used | memory_available
----------------+----------+------------+------+-------------+------------------
 admin_group    | sdw1     |          1 | 0.03 |           0 |              531
 default_group  | sdw1     |          1 | 0.00 |           0 |                0
 rg_plcontainer | sdw1     |          1 | 0.00 |           0 |
 rg_analysts    | sdw1     |          1 | 0.00 |           0 |             1063
(4 rows)

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

SELECT rolname, rsgname
FROM pg_roles,
     pg_resgroup
WHERE pg_roles.rolresgroup = pg_resgroup.oid;

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

 rolname |    rsgname
---------+---------------
 bob     | default_group
 gpadmin | admin_group
 charlie | rg_analysts
 alice   | rg_analysts
(4 rows)

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

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

Для переноса выполняющегося запроса в другую ресурсную группу используйте функцию gp_toolkit.pg_resgroup_move_query(). Она принимает два аргумента: PID запроса и имя целевой ресурсной группы. Пример:

SELECT gp_toolkit.pg_resgroup_move_query(7831, 'rg_reserve');

pg_resgroup_move_query() переносит только активные выполняющиеся запросы. Ожидающие в очереди или находящиеся в состоянии простоя (idle) запросы с помощью этой функции перенести нельзя.

После переноса запроса с помощью pg_resgroup_move_query() к нему применяются лимиты целевой группы. Это означает, что:

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

Успешное завершение pg_resgroup_move_query() не гарантирует мгновенное продолжение выполнения запроса в целевой группе. Перенос выполняется асинхронно. Чтобы проверить текущую ресурсную группу запроса, используйте представление системного каталога pg_stat_activity, например:

SELECT pid, query, rsgid, rsgname
FROM pg_stat_activity;

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

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
---------+-------------+---------+---------+--------+-----------------------+---------
  alice  | rg_analysts |  7831   |    f    | idle   | SELECT * FROM orders; | sales

Этот вывод поможет определить PID и состояние запроса, который нужно отменить.

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

SELECT pg_cancel_backend(7831);

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

ПРИМЕЧАНИЕ

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

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

ВАЖНО

CONCURRENCY не применяется к ресурсным группам для внешних компонентов. Для таких групп его необходимо явно устанавливать в 0.

Атрибут CONCURRENCY определяет максимальное количество одновременных транзакций в состояниях active и idle в ресурсной группе. Этот параметр обязателен для всех ресурсных групп для ролей. По умолчанию установлено значение 20, максимальное значение задается параметром max_connections.

При достижении лимита CONCURRENCY новые транзакции ставятся в очередь и выполняются в порядке поступления по мере завершения активных транзакций.

ПРИМЕЧАНИЕ

Фактическое количество одновременных транзакций может быть меньше лимита, если выполняющиеся транзакции используют весь доступный лимит по памяти или CPU.
Количество выполняющихся транзакций может временно превышать CONCURRENCY, если пользователи выполняют команды SET или SHOW. Эти команды не учитываются в проверках ресурсных групп.

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

gp_resource_group_bypass — позволяет запросам обойти проверку по транзакциям, при этом ограничивая доступную им память 10 МБ. Обычно применяется для разовых запросов с низким потреблением памяти.
gp_resource_group_bypass_catalog_query — позволяет запросам обойти проверку по транзакциям, если они выполняют только чтение из таблиц системного каталога.

Greengage DB поддерживает два режима выделения ресурсов процессора (CPU) для ресурсных групп, определяемых атрибутами:

CPUSET — выделение конкретных ядер CPU.
CPU_RATE_LIMIT — выделение CPU по процентам.

В каждой ресурсной группе должен быть задан только один из этих атрибутов. Разные группы в кластере могут использовать разные режимы, и режим можно менять в работающем кластере с помощью ALTER RESOURCE GROUP.

Дополнительно, параметр gp_resource_group_cpu_limit ограничивает суммарное использование CPU всеми запросами во всех ресурсных группах. Его значение по умолчанию — 0.9, что оставляет 10% CPU для работы ОС и других приложений на хостах кластера. Если на хостах работают ресурсоемкие приложения, рекомендуется снизить это значение.

ВНИМАНИЕ

Не увеличивайте gp_resource_group_cpu_limit выше 0.9. Это может привести к нехватке CPU для ОС и критичных фоновых процессов СУБД.

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

ВАЖНО

Не используйте ядро с порядковым номером 0 в ресурсных группах. Оно используется Greengage DB для встроенных групп при отсутствии других доступных ядер.

Значение CPUSET — это строка из двух частей, разделенных точкой с запятой (;). Первая часть задает ядра на мастер-хосте, вторая — на сегмент-хостах. Каждая часть может содержать номера ядер через запятую или диапазоны через дефис. Вся строка заключается в одинарные кавычки. Пример:

CPUSET = '1;1,3-5'

Этот пример выделяет ядро 1 на мастер-хосте и ядра 1, 3, 4, 5 на каждом сегмент-хосте.

Рекомендации по использованию CPUSET:

Используйте наименьшие доступные номера ядер для лучшей работы планировщика ОС.
Оставляйте часть ядер нераспределенными для работы системных операций Greengage DB и групп с CPU_RATE_LIMIT.
Для переносимости используйте ядра с номерами, общими для целевых систем. Например, на сегмент-хосте с 16 ядрами выделяйте ядра 1-7, оставляя остальные свободными. Это позволит восстановить сегмент на хосте с 8 ядрами без изменений.

Атрибут CPU_RATE_LIMIT задает процент процессорной мощности хоста, доступный данной ресурсной группе. Применяется ко всем хостам кластера: мастер-хосту и сегмент-хостам. На сегмент-хостах выделенный процент делится поровну между всеми основными сегментами этого хоста.

CPU_RATE_LIMIT может иметь значения от 1 до 100. Сумма значений CPU_RATE_LIMIT всех ресурсных групп в кластере не должна превышать 100.

Фактическое выделение процессорных мощностей по CPU_RATE_LIMIT ограничивается:

Значением параметра gp_resource_group_cpu_limit.
Процентом доступных (нераспределенных через CPUSET) ядер.

Например, на хосте с 8 ядрами, где 4 ядра выделены через CPUSET, остальные 4 ядра делятся между группами, использующими CPU_RATE_LIMIT.

По умолчанию Greengage DB автоматически перераспределяет CPU между группами с CPU_RATE_LIMIT в зависимости от их активности. Такой режим называется эластичным (elastic mode). В этом режиме неиспользуемые ресурсы процессора из неактивных групп временно перераспределяются в активные группы, сохраняя относительные пропорции CPU_RATE_LIMIT. Например, группа с CPU_RATE_LIMIT = 20 получает в 2 раза больше CPU, чем группа с CPU_RATE_LIMIT = 10. При возвращении ранее неактивной группы к работе эти ресурсы возвращаются ей обратно.

Чтобы отключить автоматическое перераспределение, переключитесь в режим жесткого лимита (ceiling enforcement mode), установив параметр gp_resource_group_cpu_ceiling_enforcement в true. В этом режиме каждая группа получает выделенный ей процент CPU вне зависимости от активности других групп.

ПРИМЕЧАНИЕ

Значение -1 атрибута CPUSET или CPU_RATE_LIMIT означает, что соответствующий режим выделения CPU не используется группой. Это значение присваивается атрибуту неиспользуемого режима автоматически.

Greengage DB управляет памятью на нескольких уровнях:

хост;
сегмент;
ресурсная группа;
транзакция (в ресурсных группах для ролей).

Общий объем памяти, доступной для распределения между ресурсными группами на хосте, определяется объемом системной памяти и параметром конфигурации gp_resource_group_memory_limit.

Системная память

Объем системной памяти вычисляется по формуле:

system_memory = <RAM> * (vm.overcommit_ratio / 100) + <swap>

где:

RAM — объем физической памяти хоста.
swap — доступный размер файла подкачки (swap).

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

vm.overcommit_memory=2
vm.overcommit_ratio=95

Узнайте больше в разделе Параметры ядра.

По умолчанию gp_resource_group_memory_limit равно 0.7. Это значит, что 70% системной памяти доступно для ресурсных групп Greengage DB:

total_gg_memory = system memory * gp_resource_group_memory_limit

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

segment_memory = total_gg_memory / <host_primary_segments>

где <host_primary_segments> — количество активных сегментов на хосте.

Память сегмента далее делится между:

выделенными слотами памяти для ресурсных групп;
глобальным разделяемым пулом памяти.

Атрибут MEMORY_LIMIT задает процент памяти сегмента, резервируемой для ресурсной группы. Допустимые значения: от 0 до 100. Сумма значений MEMORY_LIMIT всех ресурсных групп не может превышать 100.

group_memory = segment_memory * MEMORY_LIMIT / 100

Выделенная память группы делится на:

фиксированные слоты памяти для транзакций;
разделяемую память группы.

Количество слотов памяти для транзакций соответствует значению CONCURRENCY, а размер одного слота вычисляется так:

transaction_memory = (group_memory * (100 - MEMORY_SHARED_QUOTA)) / CONCURRENCY

Каждая из одновременных транзакций в группе гарантированно получает один слот выделенной памяти. При исчерпании этой памяти транзакция может использовать разделяемую память группы.

Каждая ресурсная группа для ролей может использовать собственный пул памяти, разделяемый между транзакциями — разделяемую память группы (group shared memory). Процент памяти группы, выделяемый под разделяемую память, задается атрибутом MEMORY_SHARED_QUOTA. По умолчанию его значение равно 80 (80% от MEMORY_LIMIT).

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

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

Ресурсные группы с MEMORY_LIMIT = 0 не резервируют память, а используют пул глобальной разделяемой памяти (global shared memory).

Глобальная разделяемая память — это нераспределенная часть памяти сегмента, равная разнице между 100 и суммой значений MEMORY_LIMIT всех групп:

global_shared_memory = 100 - SUM(MEMORY_LIMIT всех групп)

Глобальная разделяемая память доступна только для ресурсных групп с аудитором памяти vmtracker (для ролей). Она используется, если транзакциям требуется больше памяти, чем выделено группе. Это помогает избежать ошибок при нехватке памяти в ресурсоемких операциях.

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

Рекомендуется оставлять 10–20% памяти нераспределенной (для глобального пула), чтобы эффективно обрабатывать неожиданные ресурсоемкие запросы.

Использование глобальной разделяемой памяти контролируется параметром runaway_detector_activation_percent, который включает автоматическое прерывание запросов по достижении порога потребления этой памяти. По умолчанию установлено значение 90. Это значит, что при потреблении 90% глобальной разделяемой памяти Greengage DB начинает прерывать выполнение запросов в ресурсных группах для ролей. Первыми завершаются запросы с наибольшим потреблением памяти, и это продолжается, пока использование глобальной разделяемой памяти не упадет ниже порога. Установка runaway_detector_activation_percent в 100 отключает автоматическое завершение запросов по лимиту глобальной памяти.

Атрибут MEMORY_SPILL_RATIO задает порог использования памяти для операций, интенсивно потребляющих память, например, сортировок или соединений. Он измеряется в процентах от доступной памяти группы. При достижении этого порога создаются spill-файлы, чтобы понизить потребление памяти и предотвратить возможные ошибки.

По умолчанию значение MEMORY_SPILL_RATIO равно 0 В этом случае порог определяется параметром statement_mem.

Если MEMORY_SPILL_RATIO больше 0, то spill-файлы создаются после того, как транзакция использует объем памяти, равный:

transaction_memory_spill = group_memory * (MEMORY_SPILL_RATIO / 100) / CONCURRENCY

Если у ресурсной группы MEMORY_LIMIT = 0, MEMORY_SPILL_RATIO также должен быть равен 0.

Также можно переопределить порог создания spill-файлов на уровне сессии или для конкретных запросов с помощью параметра memory_spill_ratio.

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

Для ускорения легковесных запросов рекомендуется выполнять их с низким порогом statement_mem и memory_spill_ratio = 0:

SET memory_spill_ratio = 0;
SET statement_mem = '10 MB';

Атрибут MEMORY_AUDITOR определяет способ учета потребления памяти в ресурсной группе. Этот атрибут отличает группы для ролей от групп для внешних компонентов. Описания двух типов ресурсных групп приведены в разделе Ресурсные группы для ролей и внешних компонентов.

Возможные значения MEMORY_AUDITOR:

vmtracker (по умолчанию) — внутренний трекер виртуальной памяти Greengage DB. Используется в ресурсных группах для ролей.
cgroup — использует Linux cgroup v1. Применяется в ресурсных группах для внешних компонентов. Чтобы узнать, как настроить cgroups на хостах кластера, см. раздел Включение ресурсных групп.

После создания ресурсной группы атрибут MEMORY_AUDITOR изменить нельзя.

Настройка СУБД с помощью GUC

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

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

Обзор

Ресурсные группы для ролей и внешних компонентов

Очереди транзакций

Включение ресурсных групп

Ресурсные группы по умолчанию

Управление ресурсными группами

Создание ресурсной группы

Изменение ресурсной группы

Удаление ресурсной группы

Назначение ресурсных групп

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

Отмена назначения ресурсных групп у ролей

Назначение ресурсных групп внешним компонентам

Отслеживание ресурсных групп

Просмотр ресурсных групп

Проверка загрузки ресурсных групп

Просмотр ресурсных групп по ролям

Управление транзакциями в ресурсных группах

Перенос запроса в другую ресурсную группу

Отмена транзакции в ресурсной группе

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

Количество одновременных транзакций

Обход ограничения по количеству транзакций

Лимиты CPU

Ядра CPU: CPUSET

Процент CPU: CPU_RATE_LIMIT

Лимиты памяти

Память группы: MEMORY_LIMIT

Разделяемая память группы: MEMORY_SHARED_QUOTA

Глобальная разделяемая память

Создание spill-файлов: MEMORY_SPILL_RATIO

Аудитор памяти