Быстрый старт
Развертывание
Моделирование данных
Подключение
Запись данных
Миграция
Запросы
Операции и обслуживание
Типовое обслуживание
Секционирование
Резервное копирование и восстановление
Масштабирование
Зеркалирование
Группы ресурсов
Безопасность
Мониторинг
Настройка производительности
Устранение неполадок
Справочник
Руководство по инструментам
Типы данных
Хранилище данных
Выполняющая система
Потоковая передача
Восстановление после сбоев
Конфигурация
Индексы
Расширения
Справочник по SQL
Часто задаваемые вопросы
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() отменяется после того, как целевой процесс уже получил часть необходимых слотов, но не все, процесс сегмента не перемещается в новую группу, а целевой процесс сохраняет полученные слоты. Это несогласованное состояние разрешается при завершении транзакции или при выполнении целевым процессом следующей команды в рамках той же транзакции.После перемещения запроса нет гарантии, что суммарное потребление памяти всеми выполняющимися запросами в целевой группе ресурсов останется в пределах её квоты памяти. В таких случаях один или несколько выполняющихся запросов — в том числе перемещённый — могут завершиться ошибкой. Чтобы минимизировать этот риск, зарезервируйте достаточный объём глобальной разделяемой памяти для группы ресурсов.