×
Мы обрабатываем cookies, чтобы сделать наш сайт удобнее и персонализированнее для вас. Подробнее: политика использования «cookies» и «политики конфиденциальности».

Для самостоятельной настройки ознакомьтесь с инструкцией

Дополнительные настройки cookies в браузерах

Файлы cookie автоматически загружаются в ваш браузер при посещении веб-сайта. У вас есть возможность управлять этими файлами. Если Вы не согласны с использованием файлов cookies, запретите их сохранение на своём устройстве, удалите уже имеющиеся файлы cookies через настройки браузера или прекратите использование сайта.

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

Инструкция по отключению cookies
Принять
Настроить
Отклонить

ДОКУМЕНТАЦИЯ

Выберите версию, форк и язык для СУБД Digital Q.DataBase, чтобы прочитать или скачать всю документацию.
Техподдержка
Документация
Диасофт
Авторские права © 2016–2025 ООО "Диасофт Экосистема"
Скачать всю документацию:

3.4.4. Потребление ресурсов

3.4.4.1. Память
3.4.4.2. Диск
3.4.4.3. Использование ресурсов ядра
3.4.4.4. Задержка очистки на основе стоимости
3.4.4.5. Процесс фоновой записи
3.4.4.6. Асинхронное поведение

3.4.4.1. Память #

shared_buffers (integer) #

Определяет объем памяти, используемый сервером баз данных для разделяемых буферов памяти. Значение по умолчанию обычно составляет 128 мегабайт (128MB), но может быть меньше, если параметры ядра не поддерживают такой объем (как определено в процессе initdb). Значение данного параметра должно составлять не менее 128 килобайт. Однако для достижения высокой производительности обычно требуются значения, существенно превышающие минимальный порог. Если данное значение указано без единиц измерения, оно измеряется в блоках, то есть BLCKSZ байт, обычно 8 Кбайт. (Значения BLCKSZ , отличные от стандартных, изменяют минимально допустимое значение.) Данный параметр может быть задан только при запуске сервера.

Если используется выделенный сервер баз данных с объемом ОЗУ 1 ГБ или более, подходящим начальным значением для shared_buffers составляет 25% от объема памяти в системе. Существуют типы рабочей нагрузки, при которых даже более высокие значения параметров для shared_buffers эффективны, однако поскольку Digital Q.DataBase также использует кэш операционной системы, маловероятно, что выделение более чем 40% объема оперативной памяти для shared_buffers будет эффективнее, чем меньший объем. Более высокие значения параметров для shared_buffers обычно требуют соответствующего увеличения max_wal_size, чтобы распределить процесс записи больших объемов новых или измененных данных в течение более длительного периода времени.

На системах с объемом оперативной памяти менее 1 ГБ целесообразно использовать меньший процент RAM, чтобы оставить достаточно места для операционной системы.

huge_pages (enum) #

Определяет, запрашиваются ли большие страницы (huge pages) для основной разделяемой памяти области. Допустимыми значениями параметра являются try (значение по умолчанию), onи off. При значении huge_pages равном try сервер предпримет попытку запросить большие страницы (huge pages), но в случае ошибки вернется к использованию стандартных. При значении on, невозможность выделения больших страниц предотвратит запуск сервера. При установке off, большие страницы запрашиваться не будут. Текущее состояние использования больших страниц отображается значением переменной сервера huge_pages_status.

В настоящее время данная настройка поддерживается только в Linux и Windows. Параметр игнорируется в других системах, если для него установлено значение try. В Linux поддержка обеспечивается только при использовании shared_memory_type устанавливается в значение mmap (значение по умолчанию).

Использование больших страниц (huge pages) приводит к уменьшению таблиц страниц и сокращению времени работы центрального процессора, затрачиваемого на управление памятью, что повышает производительность. Для получения подробных сведений об использовании больших страниц в Linux см. раздел Раздел 3.3.4.5.

В ОС Windows большие страницы называются «large pages». Для их использования необходимо назначить право пользователя «Lock pages in memory» учетной записи пользователя Windows, под которой запускается Digital Q.DataBase. Для назначения права пользователя можно использовать инструмент «Редактор локальной групповой политики» Windows (gpedit.msc). «Lock pages in memory». Для запуска сервера баз данных из командной строки в режиме автономного процесса, а не службы Windows, командную строку необходимо запустить от имени администратора или функция контроля учетных записей (UAC) должна быть отключена. При включенном UAC обычная командная строка отзывает данное право пользователя «Lock pages in memory» при запуске.

Обратите внимание, что данный параметр влияет только на основную область разделяемой памяти. Такие операционные системы, как Linux, FreeBSD и Illumos, также могут использовать огромные страницы (также называемые «суперстраницами» или «большими» страницами) автоматически при обычном выделении памяти без явного запроса со стороны Digital Q.DataBase. В ОС Linux данный механизм называется «прозрачными огромными страницами» (THP). Данная функциональность может приводить к снижению производительности Digital Q.DataBase у некоторых пользователей в определенных версиях Linux поэтому её использование в настоящее время не рекомендуется (в отличие от явного использования huge_pages).

huge_page_size (integer) #

Определяет размер огромных страниц, если они задействованы через параметр huge_pages. Значение по умолчанию — ноль (0). При установке значения 0, будет использоваться системный размер больших страниц по умолчанию. Данный параметр может быть задан только при запуске сервера.

В современных 64-разрядных серверных архитектурах обычно доступны следующие размеры страниц: 2MB и 1GB (Intel и AMD), 16MB и 16GB (IBM POWER), а также 64kB, 2MB, 32MB и 1GB (ARM). Дополнительная информация об использовании и поддержке приведена в разделе Раздел 3.3.4.5.

Использование значений, отличных от настроек по умолчанию, в настоящее время поддерживается только в ОС Linux.

temp_buffers (integer) #

Задает максимальный объем памяти, выделяемой для временных буферов в рамках каждого сеанса базы данных. Данные буферы являются локальными для сеанса и применяются исключительно для доступа к временным таблицам. Если данное значение указано без единиц измерения, оно измеряется в блоках, то есть BLCKSZ байт, обычно 8 Кбайт. Значение по умолчанию составляет восемь мегабайт (8 МБ). (Если значение BLCKSZ не равно 8 Кбайт, значение по умолчанию масштабируется пропорционально ему.) Этот параметр можно изменить в рамках отдельных сеансов, но только до первого использования временных таблиц в рамках сеанса; последующие попытки изменения значения не повлияют на этот сеанс.

В сеансе временные буферы выделяются по мере необходимости до предела, задаваемого параметром temp_buffers. Затраты ресурсов на установку большого значения в сеансах, которым фактически не требуется много временных буферов, составляют лишь дескриптор буфера (около 64 байт) на каждое приращение в temp_buffers. Однако если буфер действительно используется, для него будут выделены дополнительные 8192 байта (или, в общем случае, BLCKSZ байт).

max_prepared_transactions (integer) #

Задает максимальное количество транзакций, которые могут одновременно находиться в «подготовленном» состоянии (см. PREPARE TRANSACTION). Установка значения данного параметра в ноль (что является значением по умолчанию) отключает функциональность подготовленных транзакций. Данный параметр может быть задан только при запуске сервера.

Если использование подготовленных транзакций не планируется, данный параметр следует установить в значение ноль для предотвращения случайного создания подготовленных транзакций. При использовании подготовленных транзакций значение параметра, вероятно, должно быть max_prepared_transactions как минимум не меньше значения max_connections, чтобы каждая сессия могла иметь одну ожидающую подготовленную транзакцию.

При работе резервного сервера необходимо установить данный параметр в то же или более высокое значение, чем на основном сервере. В противном случае выполнение запросов на резервном сервере будет невозможно.

work_mem (integer) #

Задает базовый максимальный объем памяти, используемый операцией запроса (например, операцией сортировки или хеш-таблицей) перед записью во временные файлы на диске. Если данное значение указано без единиц измерения, оно измеряется в килобайтах. Значение по умолчанию составляет четыре мегабайта (4MB). Следует учитывать, что сложный запрос может выполнять несколько операций сортировки и хеширования одновременно; при этом каждой операции обычно разрешается использовать объем памяти, ограниченный данным параметром, до того как начнется выгрузка данных во временные файлы. Кроме того, несколько активных сеансов могут выполнять такие операции параллельно. Таким образом, суммарный объем используемой памяти может во много раз превышать значение параметра work_mem; необходимо учитывать данный фактор при выборе значения. Операции сортировки применяются для параметра ORDER BY, DISTINCT, и соединений слиянием (merge joins). Хеш-таблицы используются при соединениях по хешу, агрегации на основе хеширования и мемоизации узлов и обработки на основе хеширования для IN подзапросов.

Операции на основе хеширования, как правило, более чувствительны к объему доступной памяти, чем аналогичные операции на основе сортировки. Лимит памяти для хеш-таблицы рассчитывается путем умножения work_mem на hash_mem_multiplier. Это делает возможным использование операциями на основе хеширования объема памяти, превышающего обычный work_mem базовый объем.

hash_mem_multiplier (floating point) #

Используется для расчета максимального объема памяти, который могут использовать операции на основе хеширования. Итоговое ограничение определяется путем умножения work_mem на hash_mem_multiplier. Значение по умолчанию составляет 2.0, что позволяет операциям на основе хеширования использовать удвоенный обычный work_mem базового объема.

Рекомендуется рассмотреть возможность увеличения значения параметра hash_mem_multiplier в условиях, когда сброс данных на диск при выполнении операций запроса является регулярным событием, особенно если простое увеличение значения work_mem приводит к дефициту оперативной памяти (дефицит памяти обычно проявляется в виде периодических ошибок нехватки памяти). Значение по умолчанию 2.0 часто является эффективным при смешанных нагрузках. Более высокие значения в диапазоне от 2.0 до 8.0 или выше могут быть эффективны в средах, где значение work_mem уже было увеличено до 40 МБ и более.

maintenance_work_mem (integer) #

Определяет максимальный объем памяти, используемый при выполнении операций технического обслуживания, таких как VACUUM, CREATE INDEXи ALTER TABLE ADD FOREIGN KEY. Если данное значение указано без единиц измерения, оно измеряется в килобайтах. Значение по умолчанию составляет 64 мегабайта (64MB). Поскольку в рамках одного сеанса базы данных одновременно может выполняться только одна из таких операций, а в стандартной конфигурации системы редко запущено много подобных процессов параллельно, допускается устанавливать значительно большее значение данного параметра. чем work_mem. Увеличение данного значения может повысить производительность операций очистки и восстановления дампов базы данных.

Обратите внимание, что при выполнении автоочистки может быть выделено в несколько autovacuum_max_workers раз больше памяти, поэтому следует соблюдать осторожность и не устанавливать значение по умолчанию слишком высоким. Для контроля этого аспекта может быть полезно отдельно установить параметр autovacuum_work_mem.

autovacuum_work_mem (integer) #

Задает максимальный объем памяти, используемый каждым рабочим процессом автоочистки. Если данное значение указано без единиц измерения, оно измеряется в килобайтах. По умолчанию установлено значение -1, что означает значение maintenance_work_mem должно использоваться вместо этого. Данный параметр не влияет на поведение VACUUM при выполнении в других контекстах. Данный параметр может быть задан только в postgresql.conf файле или в командной строка.

vacuum_buffer_usage_limit (integer) #

Определяет размер Buffer Access Strategy используемой VACUUM и ANALYZE командами. Значение 0 позволит операции использовать любое количество shared_buffers. В противном случае допустимые значения находятся в диапазоне от 128 Кбайт для 16 Гбайт. Если указанный размер превышает 1/8 от размер shared_buffers, размер неявно ограничивается этим значением. Значение по умолчанию — 2MB. Если данное значение указывается без единиц измерения, оно трактуется как значение в килобайтах. Этот параметр может быть задан в любое время. Его можно переопределить для VACUUM и ANALYZE при передаче BUFFER_USAGE_LIMIT параметра. Более высокие значения могут позволить VACUUM и ANALYZE выполняться быстрее, однако установка слишком большого значения параметра может привести к вытеснению слишком большого числа других полезных страниц из разделяемых буферов.

logical_decoding_work_mem (integer) #

Определяет максимальный объем памяти, используемый при логическом декодировании до момента записи части декодированных изменений на локальный диск. Этот параметр ограничивает объем памяти, используемой соединениями логической потоковой репликации в системе. По умолчанию значение составляет 64 мегабайта (64MB). Поскольку каждое соединение репликации использует только один буфер такого размера, и обычно в рамках инсталляции не предполагается большого количества таких соединений одновременно (с учетом ограничения max_wal_senders), можно безопасно установить значение данного параметра значительно выше, чем work_mem, сокращая объем записываемых на диск декодированных изменений.

commit_timestamp_buffers (integer) #

Определяет объем памяти для кэширования содержимого pg_commit_ts (см. Таблица 7.15.1). Если данное значение указано без единиц измерения, оно измеряется в блоках, то есть BLCKSZ байт, обычно 8 Кбайт. Значение по умолчанию — 0, который запрашивает shared_buffers/512 до 1024 блоков, но не менее 16 блоков. Данный параметр может быть задан только при запуске сервера.

multixact_member_buffers (integer) #

Определяет объем разделяемой памяти для кэширования содержимого параметра pg_multixact/members (см. Таблица 7.15.1). Если данное значение указано без единиц измерения, оно измеряется в блоках, то есть BLCKSZ байт, обычно 8 Кбайт. Значение по умолчанию — 32. Данный параметр может быть задан только при запуске сервера.

multixact_offset_buffers (integer) #

Определяет объем разделяемой памяти для кэширования содержимого параметра pg_multixact/offsets (см. Таблица 7.15.1). Если данное значение указано без единиц измерения, оно измеряется в блоках, то есть BLCKSZ байт, обычно 8 Кбайт. Значение по умолчанию — 16. Данный параметр может быть задан только при запуске сервера.

notify_buffers (integer) #

Определяет объем разделяемой памяти для кэширования содержимого параметра pg_notify (см. Таблица 7.15.1). Если данное значение указано без единиц измерения, оно измеряется в блоках, то есть BLCKSZ байт, обычно 8 Кбайт. Значение по умолчанию — 16. Данный параметр может быть задан только при запуске сервера.

serializable_buffers (integer) #

Определяет объем разделяемой памяти для кэширования содержимого параметра pg_serial (см. Таблица 7.15.1). Если данное значение указано без единиц измерения, оно измеряется в блоках, то есть BLCKSZ байт, обычно 8 Кбайт. Значение по умолчанию — 32. Данный параметр может быть задан только при запуске сервера.

subtransaction_buffers (integer) #

Определяет объем разделяемой памяти для кэширования содержимого параметра pg_subtrans (см. Таблица 7.15.1). Если данное значение указано без единиц измерения, оно измеряется в блоках, то есть BLCKSZ байт, обычно 8 Кбайт. Значение по умолчанию — 0, который запрашивает shared_buffers/512 до 1024 блоков, но не менее 16 блоков. Данный параметр может быть задан только при запуске сервера.

transaction_buffers (integer) #

Определяет объем разделяемой памяти для кэширования содержимого параметра pg_xact (см. Таблица 7.15.1). Если данное значение указано без единиц измерения, оно измеряется в блоках, то есть BLCKSZ байт, обычно 8 Кбайт. Значение по умолчанию — 0, который запрашивает shared_buffers/512 до 1024 блоков, но не менее 16 блоков. Данный параметр может быть задан только при запуске сервера.

max_stack_depth (integer) #

Определяет максимально безопасную глубину стека выполнения сервера. Оптимальным значением данного параметра является фактический предел размера стека установленный ядром (задаваемый через ulimit -s или локальный эквивалент) за вычетом запаса прочности около одного мегабайта. Данный запас прочности необходим, так как глубина стека проверяется не в каждой подпрограмме сервера, а только в ключевых потенциально рекурсивных функциях. Если данное значение указано без единиц измерения, оно измеряется в килобайтах. Значение параметра по умолчанию составляет два мегабайта (2MB), что является консервативно малым значением и вряд ли приведет к риску сбоев. Однако оно может быть слишком малым для выполнения сложных функций. Только суперпользователи и пользователи, обладающие соответствующими SET привилегиями, могут изменять данный параметр.

Установка значения параметра max_stack_depth выше, чем фактический лимит ядра, означает, что неконтролируемая рекурсивная функция может вызвать сбой отдельного процесса backend. На платформах, где Digital Q.DataBase возможно определить лимит ядра, сервер не позволит установить для данной переменной небезопасное значение. Однако не все платформы предоставляют подобную информацию, поэтому при выборе значения рекомендуется соблюдать осторожность.

shared_memory_type (enum) #

Определяет реализацию разделяемой памяти, которую сервер должен использовать для основной области разделяемой памяти, содержащей Digital Q.DataBaseразделяемые буферы и другие общие данные. Допустимые значения: mmap (для анонимной разделяемой памяти, выделяемой с помощью mmap), sysv (для разделяемой памяти System V, выделяемой через shmget) и windows (для разделяемой памяти Windows). Не все значения поддерживаются на всех платформах; первым поддерживаемым вариантом является значение по умолчанию для данной платформы. Использование конфигурационном sysv параметра, который не является значением по умолчанию ни на одной платформе, обычно не рекомендуется, так как это зачастую требует нестандартных настроек ядра для выделения больших объемов памяти (см. Раздел 3.3.4.1).

dynamic_shared_memory_type (enum) #

Определяет реализацию динамической разделяемой памяти, которую сервер должен использовать. Допустимые значения: posix (для разделяемой памяти POSIX, выделяемой с использованием shm_open), sysv (для разделяемой памяти System V, выделяемой через shmget), windows (для разделяемой памяти Windows), и mmap (для имитации разделяемой памяти с использованием отображаемых в память файлов, хранящихся в каталоге данных). Не все значения поддерживаются на всех платформах; обычно значением по умолчанию для платформы является первый поддерживаемый вариант. Использование mmap данного параметра, не являющегося значением по умолчанию ни на одной платформе, обычно не рекомендуется, так как операционная система может многократно записывать измененные страницы на диск, увеличивая нагрузку ввода-вывода системы; тем не менее, это может быть полезно для отладки, если pg_dynshmem каталог данных размещен на RAM-диске или когда другие механизмы разделяемой памяти недоступны.

min_dynamic_shared_memory (integer) #

Задает объем памяти, выделяемый при запуске сервера для выполнения параллельных запросов. Когда данная область памяти недостаточны или полностью исчерпаны параллельными запросами, новые параллельные запросы попытаться временно выделить дополнительную разделяемую память из операционной системы с использованием метода, сконфигурированного с помощью параметра dynamic_shared_memory_type, что может привести к снижению производительности из-за накладных расходов на управление памятью. На память, выделяемую при запуске, с min_dynamic_shared_memory влияет значение параметра конфигурационном huge_pages в операционных системах, в которых поддерживается данная функция; это может повысить эффективность использования больших страниц в операционных системах, где управление ими осуществляется автоматически. Значение по умолчанию — 0 (отсутствует). Данный параметр может бы быть задан только при запуске сервера.

3.4.4.2. Диск #

temp_file_limit (integer) #

Определяет максимальный объем дискового пространства, используемый процессом для временных файлов, включая временные файлы сортировки и хеширования, или файл хранения для удерживаемого курсора. Транзакция, при выполнении которой превышается данный лимит, будет отменена. Если данное значение указано без единиц измерения, оно измеряется в килобайтах. -1 (по умолчанию) означает отсутствие ограничения. Только суперпользователи и пользователи, обладающие соответствующими SET привилегиями, могут изменять данный параметр.

Данный параметр ограничивает общий объем пространства, занимаемого в любой момент времени всеми временными файлами, которые использует конкретный Digital Q.DataBase процесс. Следует отметить, что дисковое пространство, выделяемое для явных временных таблиц, в отличие от временных файлов, используемых неявно при выполнении запросов, также не учитывается в рамках данного лимита.

max_notify_queue_pages (integer) #

Определяет максимальное количество страниц, выделяемых для NOTIFY / LISTEN очереди. Значение по умолчанию — 1048576. Для страниц размером 8 Кбайт это позволяет задействовать до 8 Гбайт дискового пространства.

3.4.4.3. Использование ресурсов ядра #

max_files_per_process (integer) #

Задает максимальное количество одновременно открытых файлов, разрешенное для каждого подпроцесса сервера. Значение по умолчанию — одна тысяча файлов. Если ядро устанавливает безопасный лимит на уровне процесса, об этом параметре можно не беспокоиться. Однако на некоторых платформах (в частности, в большинстве систем BSD) ядро позволяет отдельным процессам открывать гораздо больше файлов, чем система может фактически поддерживать в случае, если множество процессов одновременно попытаются открыть такое количество файлов. Если вы сталкиваетесь с «ошибками вида files» попробуйте уменьшить значение данного параметра. Данный параметр может быть задан только при запуске сервера.

3.4.4.4. Задержка очистки на основе стоимости #

Во время выполнения VACUUM и ANALYZE команд система поддерживает внутренний счетчик, отслеживающий оценочную стоимость различных выполняемых операций ввода-вывода. При достижении накопленной стоимостью предела (задаваемого параметром vacuum_cost_limit), процесс, выполняющий операцию, приостанавливается на короткий период времени, указанный в параметре vacuum_cost_delay. Затем происходит сброс счетчика и возобновление выполнения.

Данная функция предназначена для предоставления администраторам возможности снизить влияние этих команд на операции ввода-вывода при параллельной активности базы данных. Существует множество ситуаций, когда время выполнения таких команд обслуживания, как VACUUM и ANALYZE завершить быстро; однако, как правило, крайне важно, чтобы данные команды не оказывали существенного влияния на возможность выполнения системой других операций базы данных. Механизм задержки очистки на основе стоимости предоставляет администраторам возможность реализации данного условия.

Данная функциональность по умолчанию отключена для операций, запускаемых вручную VACUUM команд. Для активации данной функции установите параметр vacuum_cost_delay в ненулевое значение.

vacuum_cost_delay (floating point) #

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

При использовании очистки на основе стоимости подходящие значения параметра vacuum_cost_delay обычно невелики, например, менее 1 миллисекунды. Несмотря на то, что для параметра vacuum_cost_delay можно задавать дробные значения миллисекунд, подобные задержки могут измеряться неточно на устаревших платформах. На таких платформах увеличение VACUUMинтенсивности потребления ресурсов значения свыше тех, что обеспечиваются при 1 мс, потребуют изменения других параметров стоимости очистки (vacuum cost) параметров. Тем не менее, следует поддерживать этот параметр vacuum_cost_delay настолько малым, насколько системная платформа позволяет стабильно выполнять измерения; большие задержки нецелесообразны.

vacuum_cost_page_hit (integer) #

Оценочная стоимость очистки буфера, находящегося в разделяемом буферном кэше. Она представляет собой стоимость блокировки пула буферов, поиска в разделяемой хеш-таблице и сканирования содержимого страницы. Значение по умолчанию — 1.

vacuum_cost_page_miss (integer) #

Оценочная стоимость очистки буфера, который необходимо считать с диска. Данный параметр представляет собой затраты на блокировку пула буферов, поиск в разделяемой хеш-таблице, чтение требуемого блока с диска и сканирование его содержимого. Значение по умолчанию — 2.

vacuum_cost_page_dirty (integer) #

Оценочная стоимость, начисляемая в случае изменения процессом очистки блока, который ранее чистыми. Данный параметр представляет собой дополнительные операции ввода-вывода, необходимые для повторного сброса измененного блока на диск. Значение по умолчанию: 20.

vacuum_cost_limit (integer) #

Это накопленная стоимость, при достижении которой процесс очистки переходит в режим ожидания параметра vacuum_cost_delay. Значение по умолчанию составляет 200.

Примечание

Существуют определенные операции, которые удерживают критические блокировки и должны завершаться максимально быстро. Задержки очистки на основе стоимости не применяются во время выполнения таких операций. Следовательно, допускается превышение накопленной стоимостью установленного лимита. Во избежание неоправданно длительных задержек в таких случаях фактическая задержка рассчитывается как vacuum_cost_delay * accumulated_balance / vacuum_cost_limit с максимальным пределом в vacuum_cost_delay * 4.

3.4.4.5. Процесс фоновой записи #

Существует отдельный серверный процесс, называемый процесс фоновой записи, функция которого заключается в инициировании записи «измененных» (новые или измененные) разделяемые буферы. Когда количество чистых разделяемых буферов оказывается недостаточным, процесс фоновой записи осуществляет запись некоторых «грязных» буферов в файловую систему и помечает их как чистые. Это снижает вероятность того, что серверные процессы, обрабатывающие пользовательские запросы, не смогут найти свободные чистые буферы и будут вынуждены самостоятельно записывать «грязные» данные на диск. Тем не менее работа процесса фоновой записи приводит к увеличению общей нагрузки ввода-вывода, поскольку страница, которая многократно изменяется, в обычном случае могла бы быть записана только один раз за интервал между контрольными точками, тогда как процесс фоновой записи может записывать ее несколько раз по мере загрязнения в течение одного и того же интервала. Параметры, рассматриваемые в данном подразделе, позволяют адаптировать это поведение под конкретные требования системы.

bgwriter_delay (integer) #

Определяет задержку между циклами активности для процесса фоновой записи. В каждом цикле данный процесс осуществляет запись определенного количества «грязных» буферов (регулируется следующими параметрами). После этого он приостанавливает работу на длина bgwriter_delay, и выполнение повторяется. Когда в пуле буферов отсутствуют «грязные» буферы, процесс переходит в режим более длительного ожидания независимо от bgwriter_delay. Если данное значение указано без единиц измерения, оно интерпретируется в миллисекундах. Значение по умолчанию составляет 200 миллисекунд (200ms). Следует учитывать, что в некоторых системах фактическое разрешение задержек ожидания составляет 10 миллисекунд; установка bgwriter_delay параметра в значение, не кратное 10, может иметь тот же результат, что и установка следующего большего значения, кратного 10. Данный параметр может быть задан только в postgresql.conf конфигурационном файле или в командной строке запуска сервера.

bgwriter_lru_maxpages (integer) #

В каждом цикле процессом фоновой записи будет записано не более указанного количества буферов. Установка данного значения равным нулю отключает процесс фоновой записи. (Следует отметить, что контрольные точки, управление которыми осуществляет отдельным специализированным вспомогательным процессом, не затрагиваются.) Значение по умолчанию составляет 100 буферов. Данный параметр может быть установлен только в postgresql.conf файле или в командной строке сервера.

bgwriter_lru_multiplier (floating point) #

Количество измененных («грязных») буферов, записываемых в каждом цикле, определяется на основе количества новых буферов, затребованных серверными процессами в ходе последних циклов. Средняя величина недавней потребности умножается на параметр bgwriter_lru_multiplier для получения оценки количества буферов, которые потребуются в следующем цикле. Измененные буферы записываются до тех пор, пока не будет обеспечено наличие достаточного количества чистых, повторно используемых буферов. (При этом за один цикл будет записано bgwriter_lru_maxpages не более указанного количества буферов.) Таким образом, установка значения 1.0 представляет собой стратегию «just in time» согласно которой выполняется запись именно того количества буферов, которое необходимо согласно прогнозу. Большие значения обеспечивают определенный резерв на случай резких скачков спроса, в то время как при меньших значениях выполнение операций записи намеренно возлагается на серверные процессы. Значение по умолчанию — 2.0. Данный параметр может быть установлен только в postgresql.conf файле или в командной строке сервера.

bgwriter_flush_after (integer) #

Как только объем данных, записанных процессом фоновой записи, превысит это значение, выполняется попытка принудительного выполнения операционной системой данных операций записи в базовое хранилище. Такой подход ограничивает объем измененных данных в кэше страниц ядра, снижая вероятность возникновения задержек в тех случаях, когда fsync вызывается в конце контрольной точки или когда ОС выполняет обратную запись данных большими порциями в фоновом режиме. Часто это приводит к значительному сокращению задержек транзакций, однако также возможны ситуации, особенно при рабочих нагрузках, объем которых превышает shared_buffers, но меньше объема кэша страниц ОС, когда производительность может снизиться. Данный параметр может не иметь эффекта на некоторых платформах. Если данное значение указано без единиц измерения, оно измеряется в блоках, то есть BLCKSZ байт, обычно 8 Кбайт. Допустимый диапазон значений находится в пределах от 0, что отключает принудительную обратную запись, до 2MB. Значение по умолчанию — 512 Кбайт в ОС Linux, 0 в других системах. (Если значение параметра BLCKSZ не равно 8 Кбайт, то значения по умолчанию и максимальные значения масштабируются пропорционально ему.) Данный параметр может быть установлен только в postgresql.conf файле или в командной строке сервера.

Меньшие значения параметра bgwriter_lru_maxpages и bgwriter_lru_multiplier снижают дополнительную нагрузку ввода-вывода, создаваемую процессом фоновой записи, но повышают вероятность того, что серверным процессам придется выполнять операции записи самостоятельно, что приведет к задержкам интерактивных запросов.

3.4.4.6. Асинхронное поведение #

backend_flush_after (integer) #

Как только объем данных, записанных процессом фоновой записи, превысит это значение, записанных одним серверным процессом, попытаться принудительно инициировать выполнение ОС данных операций записи на базовое хранилище. Это позволит ограничить объем «грязных» данных в кэше страниц ядра, снижая вероятность возникновения задержек при инициировании fsync в конце контрольной точки или при выполнении ОС фоновой записи данных большими порциями. Часто это приводит к значительному снижению задержек транзакций задержку, однако существуют также ситуации, в частности при рабочих нагрузках, превышающих shared_buffers, но меньших, чем объем кэша страниц ОС, когда производительность может снизиться. Данный параметр может не иметь эффекта на некоторых платформах. Если данное значение указано без единиц измерения, оно измеряется в блоках, то есть BLCKSZ байт, обычно 8 Кбайт. Допустимый диапазон значений — от 0, что отключает функцию принудительной обратной записи, и 2MB. Значение по умолчанию — 0, то есть функция принудительной обратной записи не используется. (Если BLCKSZ не равно 8 Кбайт, максимальное значение масштабируется пропорционально ему.)

effective_io_concurrency (integer) #

Задает количество параллельных операций дискового ввода-вывода, выполнение которых Digital Q.DataBase ожидается одновременно. Увеличение этого значения приведет к росту числа операций ввода-вывода, которые каждый отдельный Digital Q.DataBase сеанс пытается инициировать параллельно. Допустимый диапазон значений составляет от 1 до 1000, либо ноль для отключения формирования запросов асинхронного ввода-вывода. В настоящее время данный параметр влияет только на сканирование битовых карт кучи (bitmap heap scan).

Для магнитных дисков в качестве начального значения данного параметра рекомендуется использовать количество отдельных дисков в составе массива RAID 0 или RAID 1, используемого для базы данных. (Для RAID 5 диск четности учитывать не следует.) Однако если база данных часто загружена множеством запросов, выполняемых в параллельных сеансах, для полной загрузки дискового массива может быть достаточно и меньших значений. Значение, превышающее уровень, необходимый для полной загрузки дисков, приведет лишь к избыточной нагрузке на центральный процессор. SSD и другие типы накопителей на базе памяти часто способны обрабатывать множество одновременных запросов, поэтому оптимальное значение может составлять несколько сотен.

Работа асинхронного ввода-вывода зависит от наличия эффективной posix_fadvise функции, которая отсутствует в некоторых операционных системах. Если такая функция не предусмотрена, установка данного параметра в любое значение, кроме нуля, приведет к возникновению ошибки. В некоторых операционных системах (например, Solaris) функция присутствует, но фактически не выполняет никаких действий.

Значение по умолчанию — 1 в поддерживаемых системах, в противном случае — 0. Данный параметр может быть переопределен для таблиц в конкретном табличном пространстве путем установки одноименного параметра табличного пространства (см. ALTER TABLESPACE).

maintenance_io_concurrency (integer) #

Аналогично параметру effective_io_concurrency, но используется для работ по обслуживанию, выполняемых от имени множества клиентских сеансов.

Значение по умолчанию — 10 в поддерживаемых системах, в противном случае — 0. Данное значение может быть переопределен для таблиц в конкретном табличном пространстве путем установки одноименного параметра табличного пространства (см. ALTER TABLESPACE).

io_combine_limit (integer) #

Управляет максимальным объемом операций ввода-вывода при объединении запросов ввода-вывода. Значение по умолчанию — 128 Кбайт.

max_worker_processes (integer) #

Задает максимальное количество фоновых процессов, поддерживаемых кластером. Данный параметр можно установить только при запуске сервера. Значение по умолчанию — 8.

При работе резервного сервера необходимо установить данный параметр в то же или более высокое значение, чем на основном сервере. В противном случае выполнение запросов на резервном сервере будет невозможно.

При изменении этого значения также следует рассмотреть возможность корректировки параметров max_parallel_workers, max_parallel_maintenance_workers, а также max_parallel_workers_per_gather.

max_parallel_workers_per_gather (integer) #

Определяет максимальное число рабочих процессов, которые могут быть запущены одним Gather или Gather Merge узлом. Параллельные рабочие процессы выбираются из пула процессов, созданного параметром max_worker_processes, и ограничиваются параметром max_parallel_workers. Следует учитывать, что запрошенное число рабочих процессов может оказаться фактически недоступным во время выполнения. Если это произойдет, план будет выполнен с меньшим числом рабочих процессов, чем ожидалось, что может снизить эффективность работы. Значение по умолчанию — 2. Установка данного значения в 0 отключает параллельное выполнение запросов.

Обратите внимание, что параллельные запросы могут потреблять значительно больше ресурсов, чем непараллельные запросы, так как каждый рабочий процесс представляет собой полностью отдельный процесс, оказывающий на систему такое же влияние, как и дополнительный пользовательский сеанс. Это необходимо учитывать при учитывать при выборе значения данного параметра, а также при настройке других параметров, управляющих использованием ресурсов, таких в качестве work_mem. Ограничения ресурсов, такие как work_mem применяются индивидуально к каждому рабочему процессу, что означает, что общее потребление ресурсов всеми процессами может быть значительно выше, чем для одного отдельного процесса. Например, параллельный запрос с использованием 4 рабочих процессов может потреблять до 5 раз больше времени центрального процессора, объема памяти, пропускной способности ввода-вывода и т. д., чем запрос, который совсем не использует рабочие процессы.

Для получения дополнительной информации о параллельных запросах см. Глава 2.12.

max_parallel_maintenance_workers (integer) #

Задает максимальное количество параллельных рабочих процессов, которые могут быть запущены одной вспомогательной командой. В настоящее время параллельными вспомогательными командами, поддерживающими использование рабочих процессов, являются CREATE INDEX при построении индекса B-tree или BRIN, и VACUUM без FULL параметр. Параллельные рабочие процессы выбираются из пула процессов, установленного параметром max_worker_processes, ограниченного значением max_parallel_workers. Следует учитывать, что запрошенное фактическое количество рабочих процессов может оказаться недоступным во время выполнения. В этом случае операция утилиты будет выполнена с меньшим числом рабочих процессов, чем ожидалось. Значение по умолчанию — 2. Установка данного значения в 0 отключает использование параллельных рабочих процессов в командах утилит.

Следует учитывать, что команды параллельных утилит не должны потреблять значительно больше памяти, чем эквивалентные непараллельные операции. Данная стратегия отличается от стратегии параллельных запросов, в которых ограничения ресурсов обычно применяются к каждому рабочему процессу. Команды параллельных утилит применяют ограничение ресурсов maintenance_work_mem в качестве ограничения, применяемого к всей команде обслуживания, независимо от количества параллельных рабочих процессов. Тем не менее, параллельные команды обслуживания все еще могут потреблять значительно больше ресурсов центрального процессора и пропускной способности ввода-вывода.

max_parallel_workers (integer) #

Задает максимальное число рабочих процессов, поддерживаемых кластером для параллельных операций. Значение по умолчанию — 8. При увеличении или уменьшении данного значения также следует скорректировать параметр max_parallel_maintenance_workers и max_parallel_workers_per_gather. Кроме того, следует учитывать, что установка значения выше, чем max_worker_processes не даст никакого эффекта, поскольку параллельные рабочие процессы выбираются из общего пула рабочих процессов, определяемого данной настройкой.

parallel_leader_participation (boolean) #

Позволяет ведущему процессу выполнять план запроса в Gather и Gather Merge узлах вместо ожидания рабочих процессов. Значение по умолчанию — on. Установка данного значения в off снижает вероятность блокировки рабочих процессов вследствие того, что ведущий процесс считывает кортежи недостаточно быстро, однако требует от ведущего процесса ожидания запуска рабочих процессов до того, как будут получены первые кортежи. Степень, в которой ведущий процесс может повышать или снижать производительность, зависит от типа плана, количества рабочих процессов и длительности выполнения запроса.

Наверх
свяжитесь
с нами
контакты
Для прямой связи с нами вы можете использовать контакты ниже, либо оставить заявку через форму обратной связи, и мы обязательно свяжемся с вами

*поля обязательные к заполнению