Несколько хороших запросов, запущенных одновременно, могут мешать друг другу. Каждый использует память, CPU, диск и сеть, а физические ресурсы хостов конечны. В Greenplum ресурсные группы помогают разделять нагрузку и управлять тем, сколько работы допускается к исполнению.
Группа и допуск к работе
Ресурсная группа объединяет назначенные ей роли и задаёт правила использования ресурсов. Например, загрузки и интерактивная аналитика могут иметь разные ограничения. Это способ управлять конкуренцией, а не отдельный набор машин для каждой команды.
Параметр concurrency ограничивает число одновременно допущенных транзакций группы. Для обычной работы можно представить слоты: пока все заняты, следующая транзакция ждёт допуска. Время ожидания при этом не является временем сканирования таблицы.
На схеме три слота — условная настройка группы, а не рекомендация для любого кластера. Одна допущенная транзакция может включать распределённый запрос с исполнителями на нескольких сегментах. Слот не равен одному сегменту или одному CPU.
Состояние idle in transaction означает, что клиент оставил транзакцию открытой, хотя сейчас не выполняет команду. Она может продолжать удерживать занятый слот и другие ресурсы. Поэтому очередь иногда растёт при внешне небольшой вычислительной нагрузке: причина находится в жизненном цикле транзакций приложения.
CPU и память
В Greenplum 7 ресурсные группы управляют, в частности, допустимой конкуренцией, CPU и памятью. CPU можно ограничивать долей или набором ядер, а относительный вес влияет на конкуренцию за процессор. Такие параметры работают в контексте настроенных механизмов операционной системы и ресурсного менеджера.
Не стоит смешивать проценты CPU с памятью или числом слотов. Группа с несколькими активными транзакциями делит доступные ей ресурсы между выполняющимися операциями. Дополнительный слот разрешает ещё одну работу, но не добавляет RAM и не ускоряет диски.
Распределённый запрос использует память у исполнителей. Если один сегмент получил намного больше данных, нехватка может проявиться именно там. Среднее потребление по всему кластеру не доказывает, что памяти хватает самому загруженному участнику.
Названия и смысл параметров различаются между версиями Greenplum и режимами управления ресурсами. Поэтому настройки из инструкции для Greenplum 6 не копируют в Greenplum 7 без проверки. Для диагностики сначала выясняют активный менеджер ресурсов, назначение роли группе и фактические ограничения.
Почему больше concurrency бывает медленнее
Если увеличить допуск, уменьшится очередь до старта, но одновременно вырастет число конкурирующих работ. Каждая получит меньшую долю CPU, а чтение и временные файлы начнут соперничать за диск. В результате время исполнения может вырасти сильнее, чем сократилось ожидание.
Сортировки и хеш-операции при недостатке памяти могут перейти к spill — записи промежуточных данных на диск. Сам по себе spill допустим для части нагрузок, но много одновременных spill способно перегрузить хранилище. При превышении ограничений временных файлов или доступного диска запрос может завершиться ошибкой.
Поэтому настройку оценивают и по времени одного запроса, и по пропускной способности всей группы. Для короткой аналитики важна предсказуемая задержка. Для пакетной обработки — завершение полного набора работ к нужному времени. Эти цели могут требовать разных значений допуска.
Разобрать ожидание по этапам
Если запрос долго не возвращает ответ, сначала проверяют, начал ли он исполняться. Ожидание слота ресурсной группы, блокировки таблицы и медленное чтение — разные состояния. Увеличение памяти не снимает блокировку, а новый индекс не освобождает слот открытой транзакции.
Далее смотрят активные транзакции группы, длительность и состояние сессий, затем нагрузку хостов и план исполняющегося запроса. Если очередь заполнена долгими работами с большим объёмом, нужно разобраться и с их стоимостью, и с расписанием. Если слоты удерживают забытые транзакции, исправление находится в управлении соединениями и завершении транзакций.
Изменение общего лимита влияет на соседние нагрузки, поэтому его согласуют как настройку кластера. Инженер данных должен уметь показать причину: сколько времени ушло до допуска, что выполнялось после него и какой ресурс был ограничением. Такой разбор полезнее предложения «увеличить всё».
Связь с проектированием таблиц
Ресурсная группа ограничивает последствия конкуренции, но не исправляет лишнюю работу внутри запроса. Неудачное распределение, широкий Broadcast и чтение ненужных партиций продолжают расходовать ресурсы. Сначала сокращают обоснованно лишний объём и проверяют оценки, затем подбирают ограничения для всей нагрузки.
Хороший результат — не отсутствие любой очереди. Небольшое контролируемое ожидание может защищать кластер от ситуации, когда все запросы стартовали и одновременно перестали помещаться в память. Важно, чтобы очередь и время исполнения укладывались в требования, а причина задержки была наблюдаемой.