Версия сайта для слабовидящих
Развивая наш новый курс «Greenplum для инженеров данных», сегодня рассмотрим, почему в этой MPP-СУБД возникают проблемы нехватки памяти, каковы типовые способы их решения и чем очереди ресурсов отличаются от ресурсных групп. Читайте далее про схемы управления ресурсами в Greenplum и особенности параметра конфигурации statement_mem.
Очереди vs Группы: 2 схемы управления ресурсами в Greenplum
Управление памятью существенно влияет на производительность кластера MPP-СУБД Greenplum. Типичное сообщение об ошибке нехватки памяти идентифицирует сегмент Greenplum, хост и процесс, в которых возникла ошибка нехватки памяти [1]:
Out of memory (seg27 host.example.com pid=47093)
VM Protect failed to allocate 4096 bytes, 0 MB available
Чаще всего нехватка памяти в Greenplum возникает по следующим причинам [1]:
- недостаточно системной оперативной памяти, доступной в кластере;
- неправильно настроенные параметры памяти;
- неравномерное распределение данных на уровне сегмента (перекос), о чем мы рассказывали в этой статье;
- перекос вычислений на уровне SQL-запроса, про который мы также упоминали здесь.
Справиться с этими проблемами позволяют практики оптимальной настройки системных параметров Greenplum, регулирующих распределение ресурсов. Функции управления базой данных позволяют администратору расставить приоритеты и выделить ресурсы для запросов в соответствии с бизнес-требованиями, а также предотвратить запуск запросов, когда ресурсы недоступны. В частности, можно ограничить количество одновременных запросов, объем памяти, используемый для выполнения SQL-запроса, и относительный объем ЦП, выделяемый на обработку запроса. Для этого Greenplum предоставляет две схемы управления ресурсами: очереди ресурсов (Resource Queues) и группы ресурсов (Resource Groups), которые не могут быть активны одновременно. При этом можно создавать и назначать группы ресурсов, когда очереди ресурсов активны, но следует явно разрешить группам ресурсов использовать эту схему управления.
По умолчанию при установке СУБД Greenplum включена схема очередей ресурсов. Настройки по умолчанию подходят для большинства вариантов использования, поэтому не рекомендуется изменять их, пока не определены характеристики памяти и ее использования в конкретном прикладном кейсе.
Группы ресурсов – это более новая схема управления ресурсами Greenplum, которая устанавливает ограничения на память, ЦП и количество одновременных транзакций в базе данных. Примечательно, что при использовании этой схемы управления ресурсами Greenplum, развернутой на RedHat 6.x и CentOS 6.x, производительность этой MPP-СУБД сильно снижалась. Эта проблема была вызвана ошибкой ядра Linux cgroup и исправлена в системах CentOS 7.x и Red Hat 7.x. В случае использования Greenplum на RedHat версии 6 рекомендуется обновить ядро ОС до версии 2.6.32-696 или выше, чтобы воспользоваться другими исправлениями реализации cgroups [2].
Greenplum для инженеров данных и аналитиков данных
Код курса
GPDE
Ближайшая дата курса
24 июня, 2024
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
Ключевые отличия схем управления ресурсами Greenplum (очереди и группы) показаны в следующей таблице [1].
|
Критерий сравнения |
Очереди ресурсов |
Группы ресурсов |
|
Параллелизм |
Управляется на уровне запроса |
Управляется на уровне транзакции |
|
ЦП |
Указывает приоритет запроса |
Указывает процент ресурсов ЦП, используя группы управления ОС Linux |
|
Память |
Управление памятью на уровне очереди и оператора, число подписанных пользователей может превысить возможный предел |
Управляемый на уровне транзакции с улучшенным распределением и отслеживанием, число подписанных пользователей ограничивается и не может превысить заданный предел |
|
Изоляция памяти |
Нет |
Память изолирована между разными группами ресурсов и между транзакциями внутри одной группы ресурсов Greenplum |
|
Пользователи |
Ограничить авторизации можно только для пользователей без прав администратора |
Ограничения применяются как к SUPERUSER, так и к пользователям без прав администратора |
|
Очереди |
Только при отсутствии доступного слота |
Когда ни один слот недоступен или недостаточно доступной памяти |
|
Сбой запроса |
Запрос немедленно завершается ошибкой при недостатке памяти |
Запрос завершается ошибкой при достижении предела фиксированной памяти транзакции, когда не существует общей памяти группы ресурсов, а для транзакции нужно больше памяти |
|
Ограничение обхода |
Не применяются для ролей SUPERUSER, некоторых операторов и функций |
Не применяются для команд SET, RESET и SHOW |
|
Внешние компоненты |
Нет |
Управление памятью и ресурсами ЦП |
Используя наиболее подходящую схему управления ресурсами Greenplum в каждом конкретном случае, можно устранить проблемы нехватки памяти, возникающие по разным причинам. Также для этой цели существует целый ряд лучших практик, которые мы рассмотрим далее.
ТОП-10 практик устранения проблем нехватки памяти
Наиболее распространенными, простыми и эффективными решениями устранения проблемы нехватки памяти в Greenplum считаются следующие [2]:
- оптимизация и настройка SQL-запроса так, чтобы он требовал меньше памяти для выполнения;
- уменьшение параллелизма запросов с помощью очереди ресурсов;
- проверка параметра конфигурации gp_vmem_protect_limit на уровне базы данных, о чем мы подробнее поговорим в следующей статье;
- установка квоты памяти в очереди ресурсов, чтобы ограничить память, используемую запросами, выполняемыми в очереди ресурсов;
- использование настройки сеанса, чтобы уменьшить параметр конфигурации statement_mem, который отвечает за потребление памяти конкретным SQL-запросом;
- уменьшение statement_mem на уровне базы данных;
- сокращение количества сегментов на хост в кластере Greenplum, что потребует повторной инициализации СУБД и перезагрузки данных;
- увеличение объема памяти на хосте, что может потребовать дополнительного оборудования;
- непосредственное добавление узлов сегментов в кластер не устранит проблем с нехваткой памяти, т.к. память, используемая каждым SQL-запросом, определяется параметром statement_mem и устанавливается при его вызове. Однако, если добавление дополнительных хостов уменьшит количество сегментов на хост, то объем памяти, выделенной в gp_vmem_protect_limit, может возрасти.
- В некоторых случаях сокращение параметра statement_mem (например, в диапазоне 1-3 МБ) увеличивает производительность запросов с низкими требованиями к памяти.
Администрирование Greenplum / Arenadata DB
Код курса
GRAD
Ближайшая дата курса
13 мая, 2024
Продолжительность
40 ак.часов
Стоимость обучения
120 000 руб.
В следующей статье мы продолжим разговор про управление ресурсами Greenplum и поговорим про конфигурирование памяти и очереди ресурсов. А освоить практику администрирования и эксплуатации этой MPP-СУБД на примере Arenadata DB или в виде отдельного продукта для эффективного хранения и аналитики больших данных вы сможете на наших специализированных курсах в лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
