Продвигая наши курсы по Greenplum и Arenadata DB, сегодня рассмотрим пару полезных лайфхаков, как избежать избыточного потребления памяти, настроив конфигурационные параметры операционной системы хоста. Читайте далее, почему не стоит задавать слишком большой размер страниц виртуальной памяти, зачем администратору контролировать количество spill-файлов и как в этом помогает утилита gp_toolkit.
Операционная система и особенности потребления памяти Greenplum
Напомним, концепция без разделения ресурсов (share nothing) в Greenplum относится к всему кластеру, а на уровне отдельного узла сегменты этой MPP-СУБД, запущенные на одном хосте, совместно используют все имеющиеся на этой машине ресурсы: ядра ЦП, память и сетевые карты, конкурируя друг с другом и с другими работающими процессами. В частности, экземпляр Greenplum не будет работать, если сегменту общей памяти установлено слишком маленькое значение. При этом важно не только задать корректные настройки на уровне самой СУБД, но и на уровне операционной системы. В частности, определить переменные Linux sysctl vm.overcommit_memory и vm.overcommit_ratio, которые влияют на выделение памяти. Например, vm.overcommit_memory определяет метод ОС для определения объема памяти, который может быть выделен процессам. Это всегда должно быть установлено на 2, о чем мы подробно писали в этой статье. При vm.overcommit_memory=1 система считает, что в наличии неограниченное количество памяти и выделяет её без ограничений до тех пор, пока она действительно не закончится [1].
Вообще избыточное использование памяти предполагает выделение большего количества памяти виртуальным вычислительным устройствам или процессам, чем имеется фактически на физической машина. Потенциально это возможно, поскольку виртуальные машины или процессы не обязательно используют всю назначенную память, буферизуя данные. К примеру, если 4 виртуальных машины имеют 1 ГБ памяти на каждом физическом узле с 4 ГБ памяти, но реально используют только 500 МБ, можно создать дополнительные виртуальные машины, которые будут потреблять оставшиеся 500 МБ от каждой VM. Неравномерность потребления памяти (всплески) частично выравниваются за счет подкачки (swap). Но файлы подкачки памяти читаются медленнее, чем фактическая память, что чревато падением производительности. Хотя о чрезмерном использовании памяти обычно говорят в контексте виртуализации, на самом деле это обобщенное понятие, характерное и для ядра Linux-подобных систем [2].
Также не рекомендуется задавать слишком большой размер страничной памяти в операционной системе. Хотя в этом случае, когда виртуальные адреса отображаются на физические постранично и на больший размер страницы можно поместить больше данных, выделяемая виртуальная память может возвращаться операционной системе маленькими порциями, что приведет к потере огромного объема страницы.
За долю оперативной памяти, используемой для процессов приложений, отвечает параметр vm.overcommit_ratio, который в Red Hat Enterprise Linux по умолчанию установлен в значение 50, т.е. 50%. Увеличение этого значения ведет к недостатку памяти, зарезервированной для операционной системы, что может привести к сбою узла сегмента или базы данных. А слишком низкое значение снизит количество одновременных операций и сложность запросов, которые можно выполнять одновременно, за счет уменьшения объема памяти, доступной для Greenplum. Значение по умолчанию обычно безопасно, но не дает максимальной эффективности. Как рассчитать его оптимальное значение в зависимости от схемы управления ресурсами в Greenplum, объема памяти хоста, доступного для этой СУБД и общего размера RAM на узле, мы писали здесь. Итоговая формула вычисления значения этого параметра выглядит следующим образом: vm.overcommit_ratio = (RAM — 0,026 * gp_vmem) / RAM.
Greenplum для инженеров данных и аналитиков данных
Код курса
GPDE
Ближайшая дата курса
27 января, 2025
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
Как настроить общую память и посмотреть spill-файлы
Будучи основана на PostgreSQL, Greenplum использует разделяемую память для связи между процессами, которые являются частью одного и того же экземпляра этой ORM-СУБД. Следующие параметры общей памяти редко меняются и должны быть установлены в sysctl. Обычно рекомендуются следующие значения [3]:
- shmmax = 810810728448
- shmmni = 4096
- shmall = 197951838
Параметр kernel.shmall устанавливает общий объем разделяемой памяти в страницах, который может использоваться в масштабе всей системы. Параметр kernel.shmmax устанавливает максимальный размер одного сегмента разделяемой памяти в байтах. Значения kernel.shmall и kernel.shmmax зависят от физической памяти системы и размера страницы. Обычно значение этих параметров составляет половину физической памяти системы. Установить эти параметры помогут переменные операционной системы _PHYS_PAGES и PAGE_SIZE:
- shmall = ( _PHYS_PAGES / 2)
- shmmax = ( _PHYS_PAGES / 2) * PAGE_SIZE
Вычислить значения kernel.shmall и kernel.shmmax помогут следующие команды, используя команду getconf, которая возвращает значение переменной операционной системы:
$ echo $(expr $(getconf _PHYS_PAGES) / 2)
$ echo $(expr $(getconf _PHYS_PAGES) / 2 \* $(getconf PAGE_SIZE))
Администратору рекомендуется установить следующие значения в файле /etc/sysctl.conf, используя вычисленные значения. Например, в хост-системе установлено 1583 ГБ памяти, и она возвращает следующие значения: _PHYS_PAGES = 395903676 и PAGE_SIZE = 4096. Тогда значения kernel.shmall и kernel.shmmax будут равны: kernel.shmall = 197951838 и kernel.shmmax = 810810728448.
Если главный сервер базы данных Greenplum имеет другую конфигурацию разделяемой памяти, чем хосты сегмента, значения _PHYS_PAGES и PAGE_SIZE могут отличаться. Поэтому значения kernel.shmall и kernel.shmmax на главном хосте будут другими, чем на других узлах сегментов.
Поскольку Greenplum использует файлы подкачки, стоит сказать про файлы сброса (spill files), которые создаются при недостатке памяти для размещения всех выходных данных соответствия, когда занято 80% буферного пространства. База данных Greenplum создает spill-файлы (также называемые рабочими файлами или workfiles) на диске, если запросу выделено недостаточно памяти для выполнения в памяти. По умолчанию один запрос может создать не более 100 000 файлов утечки, чего достаточно для большинства запросов. Администратор может контролировать максимальное количество spill-файлов, создаваемых для каждого запроса и для каждого сегмента, с помощью параметра конфигурации gp_workfile_limit_files_per_query. Установка этого параметра в значение 0 позволяет запросам создавать неограниченное количество spill-файлов. Ограничение количества разрешенных файлов утечки предотвратит нарушение работы системы неконтролируемыми запросами.
SQL-запрос в Greenplum может создать большое количество spill-файлов, если ему не выделено достаточно памяти или если в запрашиваемых данных присутствует перекос данных. Если запросe требует больше ресурсов, чем указанное количество spill-файлов, Greenplum возвращает следующую ошибку: number of workfiles per query limit exceeded. Прежде чем повышать конфигурацию gp_workfile_limit_files_per_query, рекомендуется уменьшить количество spill-файлов, изменив запрос, распределение данных или настройки памяти.
Для этого в Greenplum есть специальный инструмент – утилита gp_toolkit, которую можно использовать для запроса информации о состоянии системы в системных каталогах, лог-файлах и операционной среде. Схема gp_toolkit содержит ряд представлений, доступных через команды SQL. Схема gp_toolkit доступна всем пользователям базы данных, хотя для некоторых объектов могут потребоваться разрешения суперпользователя [4]. В частности, следующие представления gp_toolkit отобразят информацию обо всех запросах, которые в настоящее время используют spill-файлы, что пригодится администратору и дата-инженеру для устранения неполадок и настройки [1]:
- представление gp_workfile_entries содержит по одной строке для каждого оператора, использующего дисковое пространство сегмента для рабочих файлов;
- представление gp_workfile_usage_per_query содержит по одной строке для каждого запроса, использующего дисковое пространство сегмента для рабочих файлов;
- представление gp_workfile_usage_per_segment содержит по одной строке для каждого сегмента, в каждой из которых отображается общий объем дискового пространства, используемого для рабочих файлов.
Параметр конфигурации gp_workfile_compression указывает, сжаты ли spill-файлы. По умолчанию сжатие отключено. Включение сжатия может повысить производительность использования spill-файлов. Подробнее про spill-файлы в Greenplum читайте в нашей новой статье.
Greenplum для инженеров данных и аналитиков данных
Код курса
GPDE
Ближайшая дата курса
27 января, 2025
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
Больше подробностей администрирования и эксплуатации Greenplum на примере Arenadata DB или в виде отдельного продукта для эффективного хранения и аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Greenplum для инженеров данных
- Greenplum для инженеров данных
- Администрирование Greenplum / Arenadata DB
Источники
