Помнить все: 10 практик устранения нехватки памяти в Greenplum и 2 схемы управления ресурсами кластера

Развивая наш новый курс «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 (очереди и группы) показаны в следующей таблице [1].

Используя наиболее подходящую схему управления ресурсами 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 и поговорим про конфигурирование памяти и очереди ресурсов. А освоить практику администрирования и эксплуатации этой MPP-СУБД на примере Arenadata DB или в виде отдельного продукта для эффективного хранения и аналитики больших данных вы сможете на наших специализированных курсах в лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

• Greenplum для инженеров данных
• Администрирование Greenplum / Arenadata DB

Источники

1. https://gpdb.docs.pivotal.io/6-16/best_practices/workloads.html
2. https://gpdb.docs.pivotal.io/6-16/admin_guide/wlmgmt.html