Диску больше не наливать: проблема spill-файлов в Greenplum

Автор Категория ,
Диску больше не наливать: проблема spill-файлов в Greenplum

О том, что такое 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» укажет на сжатие с соответствующим кодеком.

Освойте администрирование и эксплуатацию Greenplum с Arenadata DB для эффективного хранения и аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Источники

  1. https://docs.greenplum.org/6-16/admin_guide/query/topics/spill-files.html
  2. https://docs.greenplum.org/6-16/ref_guide/gp_toolkit.html
  3. https://gpcc.docs.pivotal.io/660/help/spill-files.html
  4. https://habr.com/ru/company/tinkoff/blog/579794/