Руководство по использованию

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

Соответствующие параметры конфигурации:

  • gp_vmem_protect_limit: задаёт общий объём памяти, который могут использовать все процессы postgres в активном экземпляре сегмента. Если запрос приводит к превышению этого лимита, дополнительная память не выделяется, и запрос завершается ошибкой.

  • 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;
  • Отмена выполняющихся или ожидающих транзакций в группе ресурсов:

Чтобы вручную отменить выполняющуюся или ожидающую транзакцию, сначала определите идентификатор процесса (pid), связанный с этой транзакцией. После получения pid вызовите функцию pg_cancel_backend() для завершения процесса.

Выполните следующие шаги:

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

```
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;
```

b. Пример вывода запроса:
```
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
```

c. Завершите процесс транзакции:
```
SELECT pg_cancel_backend(31905);
```

Примечание!
Не используйте команду операционной системы KILL для завершения каких-либо процессов базы данных YMatrix.

Перемещение запросов между группами ресурсов

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

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

Примечание!
Перемещать можно только активные или выполняющиеся запросы. Простаивающие, ожидающие или заблокированные запросы — например, из-за ограничений параллельности или памяти — переместить нельзя.

Функция pg_resgroup_move_query() требует идентификатора процесса (pid) выполняющегося запроса и имени целевой группы ресурсов.

pg_resgroup_move_query( pid int4, group_name text );

Как описано в разделе «Отмена выполняющихся или ожидающих транзакций в группе ресурсов», вы можете использовать представление gp_toolkit.gp_resgroup_status, чтобы получить список имён, идентификаторов и статусов групп ресурсов.

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

  • Если целевая группа ресурсов достигла лимита параллельности, база данных ставит запрос в очередь до освобождения слота или до истечения времени, заданного параметром gp_resource_group_queuing_timeout (в миллисекундах).
  • Если в целевой группе ресурсов имеется свободный слот, pg_resgroup_move_query() пытается передать управление слотом целевому процессу в течение gp_resource_group_move_timeout миллисекунд. Если целевой процесс не обрабатывает запрос на перемещение в течение этого интервала, база данных возвращает ошибку.
  • Если вызов pg_resgroup_move_query() отменяется после того, как целевой процесс уже получил часть необходимых слотов, но не все, процесс сегмента не перемещается в новую группу, а целевой процесс сохраняет полученные слоты. Это несогласованное состояние разрешается при завершении транзакции или при выполнении целевым процессом следующей команды в рамках той же транзакции.
  • Если в целевой группе ресурсов недостаточно свободной памяти для удовлетворения текущего требования запроса, база данных возвращает ошибку. Чтобы решить проблему, увеличьте объём разделяемой памяти, выделенной целевой группе ресурсов, либо дождитесь завершения выполняющихся запросов и повторите попытку перемещения.

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