Продолжая рассказывать про наш новый курс «Greenplum для инженеров данных», сегодня поговорим про особенности конфигурирования памяти в этой MPP-СУБД: разберем, как память хоста распределяется между сегментами и рассмотрим, как администратор кластера может ускорить работу этой базы данных. Также читайте далее о связи RAM с настройками ядра операционной системы и схемами управления ресурсами Greenplum.
Память в кластере Greenplum: хосты, зеркала и сегменты
Память – это ключевой ресурс Greenplum, который может обеспечить высокую производительность и пропускную способность всей СУБД при его эффективном использовании. Чтобы понять, как это работает, сперва немного погрузимся в особенности архитектуры этой MPP-СУБД без разделения ресурсов. Каждый узел сегмента Greenplum запускает несколько экземпляров PostgreSQL, и все они совместно используют память узла. Сегменты имеют идентичную конфигурацию, одновременно потребляют одинаковое количество ресурсов: памяти, ЦП и дискового ввода-вывода, работая с запросами параллельно.
Для повышения пропускной способности SQL-запросов необходимо тщательно управлять конфигурацией памяти, параметры которой доступны на каждом уровне Greenplum, от операционной системы до управления ресурсами с помощью очередей ресурсов и групп ресурсов, о чем мы упоминали здесь и здесь. Также имеет смысл выполнять детальную установку объема памяти, выделяемой для отдельного SQL-запроса.
При настройке кластера СУБД Greenplum администратор определяет количество основных сегментов для запуска на каждом хосте и объем памяти, выделяемый для каждого сегмента. В зависимости от ядер ЦП, объема физической ОЗУ и характеристик рабочей нагрузки количество сегментов обычно составляет от 4 до 8. При этом также следует учитывать особенности зеркалирования. В частности, при включенном зеркалировании сегментов важно выделить память для максимального количества основных сегментов, выполняемых на хосте, во время сбоя. Например, конфигурация группового зеркалирования по умолчанию при сбое узла сегмента удваивает количество действующих первичных узлов на узле, где есть зеркала отказавшего узла. Конфигурации зеркал, в которых зеркала каждого хоста распределяются по нескольким другим хостам, могут снизить максимальное значение, позволяя выделить больше памяти для каждого сегмента. Например, в случае конфигурации блочного зеркалирования с 4 хостами на блок и 8 первичными сегментами на хост, сбой одного хоста приведет к тому, что другие хосты в блоке будут иметь максимум 11 активных первичных серверов, по сравнению с 16 для группового зеркалирования по умолчанию. А как оптимально настроить память хоста в зависимости от схемы управления ресурсами Greenplum, мы разберем далее.
Сегментная память хоста и параметры ядра ОС
На узле сегмента Greenplum доступная память узла распределяется между всеми процессами, выполняемыми на компьютере, включая операционную систему, экземпляры сегмента СУБД и другие процессы приложений. Администратор кластера GP должен определить, какие процессы СУБД совместно используют память хостов, и настроить систему для эффективного использования памяти. Также стоит регулярно отслеживать использование памяти хоста, чтобы обнаруживать любые изменения в способах ее использования Greenplum или другими процессами.
Память хоста — это общая память, совместно используемая всеми приложениями на хосте сегмента. Некоторые приложения могут потреблять значительную часть памяти, поэтому нужно настроить количество сегментов на узел БД Greenplum или объем памяти на сегмент. Внутри сегмента текущая активная схема управления ресурсами, очереди ресурсов или группы ресурсов, определяет, как выделяется память для выполнения SQL-оператора, чтобы эффективно преобразовывать бизнес-запросы в политики выполнения в СУБД Greenplum и защищать от запросов, которые могут снизить производительность.
Настроить объем памяти хоста можно следующими способами [1]:
- добавить к узлам больше ОЗУ, чтобы увеличить физическую память;
- выделить пространство подкачки (swap), увеличив размер виртуальной памяти;
- задать параметры ядра overcommit_memory и vm.overcommit_ratio, чтобы настроить запросы к операционной системе на выделение памяти.
Конфигурация физической ОЗУ и ОС обычно управляется командой разработчиков платформы и системными администраторами. Объем памяти, который необходимо зарезервировать для операционной системы и других процессов, зависит от рабочей нагрузки. Минимальная рекомендация для памяти операционной системы — 32 ГБ, но при высоком уровне параллелизма в Greenplum, эту память можно увеличить до 64 ГБ. Самым большим пользователем памяти операционной системы является SLAB — механизм управления памятью для эффективного распределения памяти объектов, который растет по мере параллелизма Greenplum и увеличения количества используемых сокетов.
Администрирование Greenplum / Arenadata DB
Код курса
GRAD
Ближайшая дата курса
2 декабря, 2024
Продолжительность
40 ак.часов
Стоимость обучения
120 000 руб.
Параметр ядра vm.overcommit_memory всегда должен быть равным 2, что является единственным безопасным значением для Greenplum. Этот параметр отвечает за стратегию распределения памяти на хосте, позволяя выделить виртуальным машинам памяти больше, чем имеется физически, не гарантируя, что в конкретный момент времени вся запрошенная память может быть выделена. Этот параметр позволяет увеличить плотность размещения виртуальных машин на хосте за счет динамического перераспределения памяти хоста между ними в зависимости от текущей нагрузки. Важно, что vm.overcommit_memory должен использоваться в только в тех системах, где размер пространства подкачки превышает общий размер физической памяти. А его значение, равное 2, реализует отказ обработки запросов, запрашивающих память, размер которой превышает суммарный размер памяти пространства подкачки и ОЗУ в соответствии с параметром vm.overcommit_ratio [2].
Параметр ядра vm.overcommit_ratio устанавливает процент оперативной памяти, используемой для процессов приложений, а остальная часть зарезервирована для операционной системы. По умолчанию для ОС Red Hat установлено значение 50, т.е. 50%. Повышение значения для этого параметра приведет к недостатку памяти, зарезервированной для операционной системы, что чревато сбоем узла сегмента или базы данных. При увеличении vm.overcommit_ratio важно резервировать память для действий ОС. Установка слишком низкого значения уменьшит количество одновременных операций и сложность запросов, которые можно выполнять одновременно, за счет уменьшения объема памяти, доступной для Greenplum. Значение по умолчанию, равное 50, обычно безопасно, но часто не дает максимальной эффективности. Поэтому, чтобы повысить производительность всей СУБД, его необходимо рассчитать с учетом выбранной схемы управления ресурсами: на основе очереди (Resource Queues) или на основе групп (Resource Groups), что мы и рассмотрим далее.
Как настроить параметры памяти в ядре ОС в зависимости от схемы управления ресурсами Greenplum
Память и группы ресурсов
Группы ресурсов – это схема управления ресурсами Greenplum, которая устанавливает ограничения на память, ЦП и количество одновременных транзакций в базе данных. При использовании этой схемы управления ресурсами, следует настраивать параметр vm.overcommit_ratio по мере необходимости. Если использование памяти слишком низкое, рекомендуется увеличить это значение, а при большом потреблении памяти или swap-подкачки, наоборот, уменьшить.
В схеме управления ресурсами на основе группы, объем памяти, выделенный каждому сегменту на узле сегмента rg_perseg_mem, равен объему памяти, доступный для Greenplum, умноженный на параметр конфигурации сервера gp_resource_group_memory_limit и деленный на количество активных основных сегментов на узле num_active_primary_segments. В свою очередь, объем памяти, доступный для Greenplum, рассчитывается как сумма swap-объема и произведения RAM на значение vm.overcommit_ratio, деленное на 100.
Таким образом, общий объем памяти, выделенный каждому сегменту на узле сегмента Greenplum можно рассчитать по следующей формуле [1]:
rg_perseg_mem=((RAM*(vm.overcommit_ratio/100)+SWAP)*gp_resource_group_memory_limit)/num_active_primary_segments
Схема управления ресурсами Greenplum на основе их групп предоставляют дополнительные параметры конфигурации, чтобы детально контролировать и уточнять объем памяти, выделяемой для SQL-запросов. О некоторых из них, связанных с загрузкой данных в GP, читайте в нашей новой статье.
Память и очереди ресурсов
Очереди ресурсов – схема управления ресурсами Greenplum, заданная по умолчанию. При выборе этой схемы для вычисления безопасного значения параметра vm.overcommit_ratio, сначала следует определить gp_vmem_rq — общий объем памяти, доступный процессам Greenplum, по следующей формуле:
gp_vmem_rq = ((SWAP + RAM) – (7.5GB + 0.05 * RAM)) / 1.7
где SWAP — это пространство подкачки на хосте в ГБ, а RAM — это количество ГБ оперативной памяти, установленной на хосте.
Вычисленное таким образом значение gp_vmem_rq пригодится для расчета значения vm.overcommit_ratio по формуле: vm.overcommit_ratio = (RAM — 0.026 *gp_vmem_rq)/ RAM
Значение параметра конфигурации сервера gp_vmem_protect_limit определяет объем памяти, выделяемой каждому сегмент и работает только для управления ресурсами на основе очередей. Этот параметр рассчитывается через вычисление объема памяти, доступного для всех процессов Greenplum, деленного на максимальное количество основных сегментов во время сбоя. Если значение gp_vmem_protect_limit слишком велико, запросы могут завершиться ошибкой. Для определения безопасного значения параметра gp_vmem_protect_limit пригодится следующая формула:
gp_vmem_protect_limit = gp_vmem_rq / max_acting_primary_segments
где max_acting_primary_segments — максимальное количество первичных сегментов, которые могут работать на хосте, когда зеркальные сегменты активированы из-за отказа хоста или сегмента, а gp_vmem_rq — общий объем памяти, доступный процессам Greenplum, рассчитанный ранее.
Схема управления ресурсами на основе очередей также предоставляет дополнительные параметры конфигурации, чтобы детально контролировать и уточнять объем памяти, выделяемой для запросов. О других практиках системного администрирования GP читайте в нашей новой статье.
Greenplum для инженеров данных и аналитиков данных
Код курса
GPDE
Ближайшая дата курса
27 января, 2025
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
Узнайте все подробности администрирования и эксплуатации этой MPP-СУБД на примере Arenadata DB или в виде отдельного продукта для эффективного хранения и аналитики больших данных на наших специализированных курсах в лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
- https://gpdb.docs.pivotal.io/6-16/admin_guide/wlmgmt_intro.html
- https://access.redhat.com/documentation/ru-ru/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-memory-captun
