О том, что такое spill-эффект, мы недавно писали на примере Apache Spark. Однако, проблема переброса данных из оперативной памяти на жёсткий диск и обратна характерна и для Greenplum. Где посмотреть количество и объем spill-файлов, а также как устранить причину их образования с помощью конфигурационных параметров и инструментов администратора.
Что такое spill-файлы и чем они плохи
Под термином spill понимают перемещение данных из оперативной памяти на жесткий диск и обратно, когда возникает угроза сбоя приложения из-за нехватки памяти. Хотя этот механизм можно рассматривать как своего рода способ защиты от OOM-ошибки (Out Of Memory), он сам часто становится причиной снижения производительности системы.
Greenplum создает spill-файлы на жестком диске, если SQL-запросу выделено недостаточно памяти для выполнения в памяти или если в запрашиваемых данных присутствует перекос, т.е. они распределены неравномерно. Также возможны следующие причины подобного перелива данных из памяти на жесткий диск:
- обработка огромного объема данных без фильтров, например, при INNER JOIN соединениях больших таблиц;
- создание хэш-таблицы на основе таблицы большого объема с LEFT JOIN, когда хэш-таблица всегда строится на основе правой таблицы, несмотря на ее объем;
- устранение дублей (DISTINCT) на большом количестве полей, поскольку каждое уникальное сочетание значений полей сохраняется в оперативную память;
- сортировка в SQL-запросе (ORDER BY), т.к. Greenplum необходимо сохранять промежуточный результат сортировки.
К примеру, для выполнения отдельного SQL-запроса требуется 300 ГБ оперативной памяти, но под него выделено 250 ГБ. Недостающие 50 ГБ будут перелиты на жесткий диск в виде spill-файлов. При этом скорость выполнения запроса и всей системы в целом снизится, поскольку операции чтения и записи с жесткого диска выполняются намного медленнее, чем из оперативной памяти. Так снизится время выполнения самого SQL-запроса.
Также пострадают другие запросы, в т.ч. от других пользователей, которые ожидают своей очереди к ресурсам хранилища. Наконец, чрезмерное количество spill-файлов занимает полезное место в DWH на Greenplum, неэффективно используя ресурсы MPP-СУБД в качестве временного хранилища, а не OLAP-аналитики.
По умолчанию один запрос может создать не более 100 000 spill-файлов, чего достаточно для большинства случаев. Администратор может контролировать максимальное количество spill-файлов для каждого запроса и для каждого сегмента, с помощью параметра конфигурации gp_workfile_limit_files_per_query.
Если установить значение этого параметра равным 0, то любой запрос сможет создавать неограниченное количество spill-файлов, что рано или поздно станет причиной сбоя. В частности, когда запросу нужно больше ресурсов, чем разрешенное количество spill-файлов, Greenplum возвращает ошибку number of workfiles per query limit exceeded. Прежде чем повышать конфигурацию gp_workfile_limit_files_per_query, рекомендуется уменьшить количество spill-файлов, изменив сам запрос, распределение данных или настройки памяти. Подробнее об этом мы писали здесь.
Где и как посмотреть spill-файлы в Greenplum
Представления gp_workfile_* показывают информацию обо всех запросах, которые в настоящее время используют дисковое пространство. Для просмотра информации о spill-файлах в Greenplum используются следующие представления:
- gp_workfile_entries – содержит по одной строке для каждого оператора, использующего дисковое пространство для spill-файлов в сегменте в текущий момент. Представление доступно всем пользователям только для просмотра информации о тех базах данных, к которым у них есть разрешение на доступ. Это ограничение не касается суперпользователей.
- gp_workfile_usage_per_query — представление содержит одну строку для каждого запроса, использующего дисковое пространство для рабочих файлов в сегменте в текущий момент. Представление доступно всем пользователям только для просмотра информации о тех базах данных, к которым у них есть разрешение на доступ. Это ограничение не касается суперпользователей.
- gp_workfile_usage_per_segment — представление содержит по одной строке для каждого сегмента. В каждой строке отображается общий объем дискового пространства, используемого для рабочих файлов в сегменте в данный момент. Представление доступно всем пользователям только для просмотра информации о тех базах данных, к которым у них есть разрешение на доступ. Это ограничение не касается суперпользователей.
Рассмотрим пример запроса с использованием gp_toolkit.gp_workfile_usage_per_query, чтобы узнать количество и объем spill-файлов в ГБ, которые были сгенерированы SQL-запросами на текущий момент.
select
current_query
,sum(size) / 1024 / 1024 / 1024 :: float size_spill_files_gb
,sum(numfiles) count_spill_files
from
gp_toolkit.gp_workfile_usage_per_query
where
usename = current_user
group by
current_query
В результате выполнения этого запроса можно узнать точный объем spill-файлов, но лишь в данное время. Но если SQL-запрос генерирует spill-файлы в какой-то промежуток времени, а запрос с gp_toolkit.gp_workfile_usage_per_query не попадает в этот промежуток, можно сделать ошибочный вывод об отсутствии файлов сбора. В этом случае можно добавить к самому SQL-запросу оператор EXPLAIN ANALYZE, о котором мы писали здесь.
Изучая план запроса, который выдаст эта команда, в секции «Cтатистика слайсов» (независимых участков плана из нескольких SQL-операторов) можно обнаружить слайсы, помеченные звездочками (*). Это указывает на генерацию spill-файлов, однако не показывает их точного размера. Недостаток этого способа в том, что EXPLAIN ANALYZE требует полного выполнения запроса.
Как уменьшить файлы утечки
Разобравшись с тем, что такое spill-файлы и где их посмотреть, перечислим, как устранить их чрезмерную генерацию:
- увеличение объема памяти, доступной для запроса;
- оптимизация SQL-запроса для более эффективного использования доступной памяти;
- уменьшение параллелизма группы ресурсов, чтобы увеличить долю памяти для каждого запроса;
- увеличение значения параметра MEMORY_SHARED_QUOTA группы ресурсов, чтобы увеличить объем разделяемой памяти группы ресурсов;
- уменьшение процента памяти, выделенной для всех групп ресурсов, чтобы увеличить объем глобальной разделяемой памяти.
Когда активно управление ресурсами очереди ресурсов, Greenplum может обнаруживать и завершать «неуправляемые» запросы, которые потребляют большой процент доступной памяти. Предотвратить неконтролируемые запросы можно, ограничив количество создаваемых файлов утечки или их общий размер. В частности, параметр gp_workfile_limit_per_segment устанавливает максимальный общий размер диска, который разрешено использовать всем запущенным запросам для создания spill-файлов в каждом сегменте. По умолчанию значение этого параметра равно 0, т.е. место для файлов утечки не лимитировано.
Также следует убедиться, что количество создаваемых spill-файлов сведено к минимуму, а проблемы с ЦП и перекосом данных, обнаружены и исправлены. Чтобы сократить использование диска и количество операций ввода-вывода при создании файлов утечки, следует установить сжатие файлов утечки, задав параметру конфигурации gp_workfile_compresson значение on. Задать алгоритм сжатия можно через параметр gp_workfile_compress_algorithm. Этот алгоритм будет использоваться для spill-файлов, когда операция агрегирования хеша или хеш-соединения переносится на диск во время обработки SQL-запроса. Например, значение «zlib» укажет на сжатие с соответствующим кодеком.
Код курса
ADB
Ближайшая дата курса
Продолжительность
ак.часов
Стоимость обучения
0 руб.
Освойте администрирование и эксплуатацию Greenplum с Arenadata DB для эффективного хранения и аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Greenplum для инженеров данных
- Greenplum для инженеров данных
- Администрирование Greenplum / Arenadata DB
Источники
