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

Настройка автоматического завершения запросов по потреблению памяти

YMatrix поддерживает механизм обнаружения «разбегающихся» (runaway) запросов.
Для запросов, управляемых группами ресурсов, 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). Затем вызовите функцию pg_cancel_backend() для её завершения.

    Шаги:

    1. Выполните следующий запрос, чтобы получить список всех активных или простаивающих операторов во всех группах ресурсов. Если результат пуст, значит, нет ни выполняющихся, ни ожидающих транзакций.
      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;
    2. Пример вывода:
      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
    3. Завершите процесс транзакции:
      SELECT pg_cancel_backend(31905);

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

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

Суперпользователи могут использовать функцию gp_toolkit.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 миллисекунд. Если передача не завершена вовремя, возвращается ошибка.
  • Если операция перемещения отменена после того, как целевой процесс уже получил слоты, но до завершения перемещения на всех сегментах, сегменты остаются в исходной группе, а целевой процесс удерживает слоты. Эта несогласованность разрешается при завершении транзакции или при следующей команде, запланированной этим процессом в рамках той же транзакции.
  • Если в целевой группе недостаточно памяти для удовлетворения текущих потребностей запроса, возвращается ошибка. Чтобы решить проблему, увеличьте квоту памяти целевой группы или дождитесь завершения других запросов и повторите попытку.

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