Версия сайта для слабовидящих
Продолжая тему недавней статьи про настройки Greenplum 7, сегодня рассмотрим еще несколько конфигураций, которые позволят сделать эту MPP-СУБД еще быстрее и надежнее.
Глобальные конфигурации Greenplum для настройки рабочих файлов
Параметры глобальной конфигурации пользователя (GUC, Global User Configuration) Greenplum могут быть как глобальными, так и локальными по отношению к экземплярам сегмента. Глобальные GUC необходимо установить только на главном экземпляре, но изменение повлияет также на все экземпляры сегмента. Локальные GUC могут быть установлены для каждого сегмента, но необходимо, чтобы все сегменты имели одинаковую конфигурацию. В этом случае необходимо установить локальный GUC, отредактировав файл postgresql.conf для каждого экземпляра сегмента. Обычно при этом требуется проверить текущие настройки GUC для всех сегментов.
GUC ограничен рабочими файлами или файлами сброса (spill-файлы, о которых мы писали здесь). Greenplum создает файлы сброса/рабочие файлы на диске, когда запрос не может быть выполнен в памяти, выделенной для Greenplum. Рабочие файлы, используемые запросом, можно просмотреть, используя следующий SQL-запрос:
SELECT * FROM gp_toolkit.gp_workfile_usage_per_query;
после этого можно настроить следующие параметры конфигурации:
- gp_workfile_limit_files_per_query — максимальное количество временных дополнительных (рабочих) файлов, разрешенное для каждого запроса на сегмент. Файлы сброса создаются при выполнении запроса, который требует больше памяти, чем выделено. Текущий запрос завершается при превышении лимита. Значение 0 разрешает неограниченное количество файлов сброса. По умолчанию этот параметр установлен в значение 100000. При его изменении нужно выполнить перезагрузку сеанса координатора.
- gp_workfile_limit_per_segment — максимальный общий размер диска, который разрешено использовать всем выполняемым запросам для создания временных файлов сброса в каждом сегменте Greenplum. По умолчанию 0, т.е. ограничение не применяется.
- gp_workfile_limit_per_query — максимальный размер диска, который отдельный запрос может использовать для создания временных файлов сброса в каждом сегменте Greenplum. По умолчанию 0, т.е. ограничение не применяется.
Статистика и конфигурации группы ресурсов
Как мы уже отмечали здесь, оптимизатор Greenplum использует статистическую информацию о таблицах для создания плана выполнения SQL-запросов. Поэтому неточная статистика — одна из наиболее распространенных причин низкой производительности запросов в кластере. Из-за неточной статистики происходит некорректная оценка строк, мощность, порядка соединения и выбор предикатов. Поэтому дата-инженеру важно убедиться, что команда ANALYZE часто выполняется для таблиц, которые часто загружаются или изменяются. Можно сказать, что регулярный запуск команд VACUUM и ANALYZE являются рутинными процедурами обслуживания Greenplum, что мы недавно отмечали в этой статье.
Таким образом, регулярный анализ таблиц каталога и пользовательских таблиц гарантирует, что оптимизатор сгенерирует наилучший доступный план для SQL-запроса, а его выполнение будет использовать оптимальный путь для возврата результатов обратно координатору. Это позволит избежать дорогостоящего потребления ресурсов в сегментах и обеспечить правильное использование ресурсов на узле сегмента. Для этого можно настроить следующие параметры конфигурации:
- gp_autostats_mode – режим запуска автоматического сбора статистики с помощью команды ANALYZE. Опция on_no_stats запускает сбор статистики для CTAS-операций (CREATE TABLE AS SELECT), INSERT или COPY для любой таблицы, которая не имеет существующей статистики. Опция on_change запускает сбор статистики только тогда, когда количество затронутых строк превышает порог, определенный в gp_autostats_on_change_threshold. Помимо CTAS, INSERT и COPY, к операциям, которые могут вызвать автоматический сбор статистики по таблице с помощью on_change относятся UPDATE и DELETE.
- gp_autostats_mode_in_functions – режим запуска автоматического сбора статистики с помощью ANALYZE для операторов в функциях процедурного языка. Опция none отключает сбор статистики. Опция on_no_stats запускает сбор статистики для CTAS-операций, INSERT или COPY, которые выполняются в функциях для любой таблицы, не имеющей существующей статистики. Опция on_change запускает сбор статистики только тогда, когда количество затронутых строк превышает порог, определенный в gp_autostats_on_change_threshold. Аналогично SQL-запросам, помимо CTAS, INSERT и COPY, операции UPDAT и DELETE в функциях процедурного языка тоже могут запускать автоматический сбор статистики с помощью on_change.
Чтобы повысить эффективность кластера MPP-СУБД, можно использовать группы ресурсов для установки и обеспечения соблюдения ограничений ЦП, памяти и одновременных транзакций в базе данных Greenplum. Greenplum использует группы управления на базе Linux для управления ресурсами ЦП и Runaway Detector для статистики, отслеживания и управления памятью. После определения группы ресурсов ее надо назначить одной или нескольким ролям базы данных Greenplum, чтобы контролировать используемые ими ресурсы. После этого ограничения ресурсов, определенные для группы, применяются ко всем ролям, которым она назначена. Например, ограничение памяти для группы ресурсов определяет максимальное использование памяти для всех выполняемых транзакций, отправленных пользователями Greenplum во всех ролях, которым назначена эта группу.
Конфигурации и ограничения группы ресурсов можно просмотреть, используя SQL-запрос
SELECT * FROM gp_toolkit.gp_resgroup_config;
После этого можно настроить следующие параметры конфигурации:
- gp_resource_group_cpu_limit — максимальный процент ресурсов ЦП системы, выделяемых группам ресурсов на каждом узле сегмента базы данных Greenplum;
- gp_resource_group_cpu_priority — приоритет ЦП для процессов Greenplum относительно процессов, отличных от Greenplum, когда группы ресурсов включены. Например, установка для этого параметра значения 10 устанавливает соотношение ресурсов ЦП, выделенных для процессов Greenplum, к процессам, не относящимся к Greenplum, равным 10:1.
- gp_resource_group_queuing_timeout – время ожидания (в миллисекундах) транзакции, поставленной в очередь в группе ресурсов, до ее отмены. Ограничение по времени применяется отдельно к каждой транзакции. Значение по умолчанию — ноль; транзакции ставятся в очередь на неопределенный срок и никогда не истекают.
- gp_resgroup_memory_policy – политика управления выделением памяти для операторов запросов. Если установлено значение auto, Greenplum использует ограничения памяти группы ресурсов для распределения памяти между операторами SQL-запросов, выделяя фиксированный размер памяти операторам, не требующим большого объема памяти, а остальную часть — операторам с интенсивным использованием памяти. Это позволяет Greenplum оптимально распределять память между операторами, перераспределяя память, освобожденную операторами, завершившими обработку, операторам на более позднем этапе запроса.
- gp_resgroup_memory_query_fixed_mem – фиксированный объем памяти в МБ, зарезервированный для всех запросов в группе ресурсов в рамках сеанса. Если для этого параметра установлено значение 0, по умолчанию этот предел памяти определяется атрибутом группы ресурсов MEMORY_LIMIT. Хотя MEMORY LIMIT применяется к запросам между сеансами, gp_resgroup_memory_query_fixed_mem переопределяет это ограничение на уровне сеанса. Таким образом, можно использовать этот параметр конфигурации для индивидуальной настройки бюджета памяти запросов для конкретного сеанса. Этот параметр специфичен для Greenplum 7, в предыдущих версиях он не использовался.
- memory_spill_ratio – пороговый процент использования памяти для операторов с интенсивным использованием памяти в транзакции. Когда транзакция достигает этого порога, она передается на диск. Процент memory_spill_ratio по умолчанию — это значение, определенное для группы ресурсов, назначенной текущей активной роли. Можно установить memory_spill_ratio на уровне сеанса, чтобы выборочно устанавливать этот предел для каждого запроса. Например, если какой-то SQL-запрос переносится на диск и требует больше памяти, можно установить большее значение memory_spill_ratio, чтобы увеличить начальное выделение памяти, указав целое процентное значение от 0 до 100 включительно. При значении 0, Greenplum будет использовать значение параметра конфигурации сервера Statement_mem для управления исходным объемом памяти оператора запроса.
Освойте администрирование и эксплуатацию Greenplum с Arenadata DB для эффективного хранения и аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
