Настройка сжатия данных Performance Insight для уменьшения требуемого объема на диске

Описание

В СУБД Pangolin реализована доработка оптимизации структуры хранения данных.

В данных Performance Insights наблюдаются дублирования:

1. Избыточные строковые данные, занимающие много места, а также повторяющиеся данные по процессам, находящимся в одном и том же состоянии продолжительное время.

   При удалении таблицы связанный объект oid становится недоступным, что может привести к потере информации. Во избежание потерь рекомендуется использовать pg_profile для сохранения и анализа данных.

2. Чрезмерное количество файлов при хранении данных с высокой частотой выборки.

   Если активный пользователь сохраняет данные за месяц с интервалом в 1 секунду, возникает огромное количество файлов, что делает их открытие затруднительным. Это приводит к избыточности хранения данных и увеличению времени обработки.

Цели доработки:

• Уменьшить дублирование при хранении данных.
• Сократить количество файлов для обеспечения возможности их открытия.

Возможности при использовании доработки оптимизации:

• Пользователь может управлять схемой хранения данных на диске, используя диапазоны и сжатие в форматах gzip и zstd для уменьшения количества файлов.
• Возможно ограничение объема хранимых данных: при превышении заданного объема самые старые файлы автоматически удаляются.
• Пользователь может выбирать формат сохранения новых файлов, при этом старые файлы остаются доступными независимо от текущего формата.
• Для архивируемых форматов (gzip, zstd) предусмотрена возможность внешней распаковки (gunzip, unzstd) для восстановления поврежденных архивов.

Настройка

Очистка файлов

Для разных форматов определены разные методы очистки, которые применяются к соответствующим файлам на постоянной основе, вне зависимости от указанного performance_insights.file_format. Подробнее описание параметров приведено в разделе «Аналитика производительности (Performance Insights)».

1. Формат 0 (Default):

   Для performance_insights.file_format = 0 (Default) происходит очистка по времени исходя из заданных параметров хранения (performance_insights.sampling_period, performance_insights.num_samples_in_ram, performance_insights.num_samples_in_files). Интервал, за который хранятся файлы формата 0 (Default) вычисляется следующим образом: performance_insights.sampling_period * (performance_insights.num_samples_in_ram + performance_insights.num_samples_in_files).

   Пример:

   performance_insights.sampling_period = ‘100ms’
   performance_insights.num_samples_in_ram = 300
   performance_insights.num_samples_in_files = 10000

   Тогда interval = 0.1s * (300 + 10000) = 1030s – допустимый к хранению интервал. Файл не будет удален до тех пор, пока полностью не выйдет за данный диапазон хранения [current_time - interval, current_time].

2. Форматы 1, 2 и 3 (gzip, zstd, без сжатия с диапазоном секунд):

   Для новых форматов (1, 2 и 3) очистка происходит исходя из занимаемого ими объема (size_samples_in_files). При этом рассматриваются размеры только файлов новых форматов. Файлы формата 0 (Default) не учитываются при вычислении суммарного занимаемого размера.

Внимание!

При смене форматов очистка продолжает происходить для всех форматов. Но, если при использовании формата 0, не происходит добавление файлов форматов 1, 2 и 3 - их очистка не будет запускаться (пока не изменится параметр size_samples_in_files), так как их общий объем остается прежним.

Логика работы буфер файла

В рамках работы форматов 1 и 2 (gzip, zstd) создаются два файла: databuffer.* и *_xxx, которые содержат последние вытесненные из памяти данные. Например, в случае формата gzip: databuffer.gz и 792532267_xxx.

Файл *_xxx содержит распакованные данные, вытесненные из памяти, тогда как databuffer.* содержит те же данные, но в сжатом виде. Поскольку файл databuffer.* невозможно правильно прочитать до тех пор, пока он не закрыт, для корректной работы программы сохраняется его несжатая версия. Постоянное наличие файла databuffer.* в процессе работы, а не только в момент переключения файлов / завершения работы, связано с длительностью процесса сжатия файла «с нуля», которая могла бы превысить допустимое время завершения.

Ориентиром для переключения файла служит именно размер *_xxx (размер распакованного блока данных, хранимых в одном файле - performance_insights.packed_block_size). При работе с форматами 1, 2 при переключении файлов или завершении работы происходит переименование файла databuffer.* в итоговый файл с диапазоном секунд и расширением.

примечание

При работе с форматом 3 (без сжатия, формат с диапазоном секунд) присутствует только файл *_xxx и он будет переименован при переключении файлов / завершении работы.

Формула преобразования имени файла в unix epoch time

Формула преобразования имени файла в unix epoch time:

unix_time = time + (POSTGRES_EPOCH_JDATE - UNIX_EPOCH_JDATE) * SECS_PER_DAY = time + 946684800

Внимание!

unix_time будет посчитан для часового пояса GMT+0000. Для перевода в GMT+0300 (Мск) необходимо к unix_time прибавить 10800 (3 часа).

Однако при выводе данных пользователю (например, при чтении истории performance_insights с помощью запроса SELECT * FROM pg_stat_get_activity_history(NULL,NULL,NULL)), в таблице будет указано время, скорректированное на часовой пояс указанный в postgresql.conf для конфигурации standalone, в postgres.yml для конфигурации cluster.

Резервное копирование

Независимо от способа создания резервной копии (pg_basebackup / pg_probackup), содержимое папки $PGDATA/pg_perf_insights не будет включаться в бэкап. Наличие файлов разных форматов (zst / gz) на это поведение влияния не оказывает.

Внимание!

Только каталог pg_perf_insights исключается из резервного копирования, значение переменной performance_insights.directory в данном случае не учитывается.

Логирование

1. В рамках процесса performance Insights:

   При автоматическом удалении файлов формата 0, так и 1, 2 и 3 не выводятся дополнительные сообщения в лог. Как и в предыдущей версии performance insights для этого требуется уровень логирования минимум DEBUG1, что приведет к выводу большого объема дополнительной информации в процессе работы.

   При потенциально некорректной настройке, например, отсутствии прав на запись в директорию, в логи будет попадать информация о невозможности записать данные в конкретный файл *_xxx (для 1, 2 и 3 форматов), но лишь один раз. При этом нужно учитывать, что диапазон в названии новых форматов файлов задается в секундах, соответственно за минуту таких логов может быть 60 штук (на каждую секунду при соответствующей нагрузке).

   Для формата 0 (Default) поведение аналогичное, однако названия файлов этого формата задаются в минутах, поэтому такой лог будет появляться не чаще, чем раз в минуту.

2. В рамках получения данных в консоли:

   При работе с файлами, содержащими некорректные данные (например, в которых не совпадает сохраненный размеров данных с реальным или значение в header отличается от ожидаемого), могут выводиться WARNING сообщения c информацией о конкретных проблемах, возникших в ходе обработки данного файла. При этом данные будут прочитаны до момента непосредственной проблемы и лишь в момент появления ошибок будет произведен переход к чтению следующего файла.

   Информация о невозможности открытия файла по различным причинам относится к этой же категории.

Управление

Сценарии работы

Возможные сценарии работы выглядят следующим образом:

1. Для сохранения совместимости со старой структурой устанавливается значение performance_insights.file_format = 0 (используется по умолчанию), структура хранения аналогична старой ${PGDATA}/pg_perf_insights.

2. Для обеспечения максимального сжатия необходимо установить следующие значения параметров:

   performance_insights.file_format = 2                  # сжатие в zstd
   performance_insights.compression_level = 9            # максимальное сжатие
   performance_insights.packed_block_size = 256MB        # минимальное количество файлов, высокая компрессия

   При значении performance_insights.sampling_period >= 1s обеспечивается минимальное влияние на производительность сервера.

3. Для снижения нагрузки на сервер доступно изменение параметра performance_insights.compression_level.

   Внимание!

   Значение performance_insights.compression_level = 0 может привести к увеличению файлов из-за хранения заголовков сжатия.

Обработка ошибок

При обнаружении дефектного сжатого файла:

• Логируется ошибка, проблемный фрагмент пропускается.
• Некоторые дефекты могут приводить к остановке чтения, включая последующие файлы.
• Имя проблемного файла фиксируется в логах.

Для восстановления поврежденных архивов:

• Рекомендуется использовать внешние утилиты (gunzip, unzstd) для усечения архивов.
• Архивы с данными могут быть перепакованы внешними средствами, но это не гарантируется для всех возможных настроек утилит.

Управление объемом данных

Параметр performance_insights.size_samples_in_files используется для очистки наиболее старых данных при сохранении новых. Фактический объем хранимых данных может быть превышен в двух случаях:

1. При работе с активным сохраняемым диапазоном который больше, чем разрешенный размер хранения.

   Пример:

   performance_insights.size_samples_in_files=20MB
   performance_insights.packed_block_size=256MB

   Фактическое место на диске может составлять 276MB (256 + 20).

2. При активной работе с сохраняемым диапазоном. В таком случае, общий объем составит: performance_insights.size_samples_in_files + performance_insights.packed_block_size(performance_insights.packed_block_size - зависит от коэффициента сжатия).