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

Память

shared_buffers (integer)

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

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

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

huge_pages (enum)

Определяет, будут ли запрашиваться огромные страницы из основной области разделяемой памяти. Допустимые значения: try (по умолчанию), on и off. Если в параметре huge_pages установлено try, сервер будет пытаться запросить огромные страницы, но в случае сбоя вернется к поведению по умолчанию. При значении on, если получить огромные страницы не удастся, сервер не запустится. При значении off огромные страницы запрашиваться не будут.

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

Использование огромных страниц приводит к уменьшению таблиц страниц и сокращению затрат времени ЦП на управление памятью, что повышает производительность. Более подробную информацию об использовании огромных страниц в Linux см. в подразделе Огромные страницы в Linux.

Обратите внимание, что этот параметр влияет только на основную область разделяемой памяти. Операционные системы, такие как Linux, FreeBSD и Illumos, также могут автоматически использовать огромные страницы (также называемые «суперстраницами» или «большими» страницами) для обычного выделения памяти без явного запроса со стороны QHB. В Linux это называется «прозрачными огромными страницами» (Transparent Huge Pages, ТНР). Известно, что эта функция может вызвать снижение производительности QHB для некоторых пользователей в некоторых версиях Linux, поэтому использовать ее в настоящее время не рекомендуется (в отличие от явного использования huge_pages).

huge_page_size (integer)

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

Некоторые наиболее распространенные размеры страниц на современных 64-битных серверных архитектурах: 2MB и 1GB (Intel и AMD), 16MB и 16GB (IBM POWER), и 64kB, 2MB, 32MB и 1GB (ARM). Более подробную информацию об их использовании и обслуживании см. в подразделе Огромные страницы в Linux.

В настоящее время отличные от стандартных значения поддерживаются только в Linux.

temp_buffers (integer)

Задает максимальный объем памяти, выделяемый для временных буферов в каждом сеансе базы данных. Это существующие исключительно в рамках сеанса буферы, используемые только для доступа к временным таблицам. Если это значение указано без единиц измерения, оно считается заданным в блоках, размер которых равен BLCKSZ байт (обычно это 8 КБ). По умолчанию используется восемь мегабайт (8MB). (Если 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 и объединений слиянием. Хэш-таблицы применяются в хэш-соединениях, агрегировании по хэшу и обработке подзапросов IN с использованием хэша.

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

hash_mem_multiplier (floating point)

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

Увеличивать значение hash_mem_multiplier имеет смысл в средах, где постоянно происходит вытеснение данных на диск при операциях запросов, особенно когда простое увеличение work_mem приводит к дефициту памяти (обычно дефицит памяти принимает форму периодически возникающих ошибок «нехватка памяти»). При смешанных нагрузках может помочь установка значения 1.5 или 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.

Учтите, что для сбора идентификаторов неиспользуемых кортежей VACUUM способен использовать не более 1GB памяти.

autovacuum_work_mem (integer)

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

Для сбора идентификаторов неиспользуемых кортежей процесс автовакуума способен использовать не более 1GB памяти, поэтому установка в autovacuum_work_mem большего значения не повлияет на число неиспользуемых кортежей, которое автоочистка может собрать при сканировании таблицы.

logical_decoding_work_mem (integer)

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

max_stack_depth (integer)

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

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

shared_memory_type (enum)

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

dynamic_shared_memory_type (enum)

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

min_dynamic_shared_memory (integer)

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

Диск

temp_file_limit (integer)

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

Этот параметр ограничивает общий объем, занимаемый в текущий момент всеми временными файлами, используемыми данным процессом QHB. Следует отметить, что в этом ограничении не учитывается дисковое пространство, занимаемое явно созданными временными таблицами; ограничивается только объем временных файлов, используемых за кадром при выполнении запросов.

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

max_files_per_process (integer)

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

Задержка очистки по стоимости

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

Цель этой функции — позволить администраторам уменьшить влияние процессов ввода/ вывода этих команд на параллельную работу базы данных. Во многих ситуациях быстрое завершение команд обслуживания, таких как VACUUM и ANALYZE, не имеет значения; однако, как правило, очень важно, чтобы эти команды не оказывали значительного влияния на способность системы выполнять другие операции с базой данных. Администраторы могут этого добиться с помощью задержки очистки по стоимости.

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

vacuum_cost_delay (floating point)

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

При настройке интенсивности такой очистки подходящие значения для vacuum_cost_delay обычно довольно малы, вплоть до 1 миллисекунды и менее. Несмотря на то, что в этом параметре можно задать значения в долях миллисекунды, на старых платформах такие задержки могут быть неточными. На таких платформах увеличение интенсивности VACUUM по сравнению с уровнем, получаемым при задержке в 1 мс, потребует изменения других параметров стоимости очистки. Тем не менее стоит сохранять столь малое значение 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)

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

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

Фоновая запись

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

bgwriter_delay (integer)

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

bgwriter_lru_maxpages (integer)

Максимальное количество буферов, которое процесс фоновой записи будет записывать в каждом раунде. Установка этого значения в ноль выключает фоновую запись. (Обратите внимание, что это не затрагивает контрольные точки, которые управляются отдельным выделенным вспомогательным процессом.) Значение по умолчанию — 100 буферов. Этот параметр можно задать только в файле qhb.conf или в командной строке сервера.

bgwriter_lru_multiplier (floating point)

Количество грязных буферов, записанных в каждом раунде, основано на количестве новых буферов, которое понадобилось серверным процессам во время последних раундов. Для расчета предварительной потребности в буферах для следующего раунда средняя потребность за последнее время умножается на значение bgwriter_lru_multiplier. Грязные буферы будут записываются до тех пор, пока количество чистых, пригодных для повторного использования буферов не достигнет целевого значения. (Однако в каждом раунде будет записано не более bgwriter_lru_maxpages буферов.) Таким образом, значение этого параметра, равное 1.0, воплощает политику «точно в срок», при которой записывается именно то количество буферов, которое, предполагается необходимым. Увеличение этого значения обеспечивает некоторую страховку от всплесков потребностей, тогда как уменьшение преднамеренно оставляет некоторый объем записи для серверных процессов. Значение по умолчанию — 2.0. Этот параметр можно задать только в файле qhb.conf или в командной строке сервера.

bgwriter_flush_after (integer)

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

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

Асинхронное поведение

backend_flush_after (integer)

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

effective_io_concurrency (integer)

Задает количество параллельных операций ввода/вывода на диске, которые, как ожидает QHB, могут выполняться одновременно. Увеличение этого значения приведет к увеличению числа операций ввода/вывода, которые QHB попытается запустить параллельно в каждом отдельном сеансе. Допустимый диапазон: от 1 до 1000; ноль выключает выполнение асинхронных запросов ввода/вывода. В настоящее время этот параметр влияет только на сканирование по битовой карте.

Для магнитных носителей хорошей начальной точкой для этого параметра является количество отдельных дисков, содержащих массив с чередованием 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).

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 раз больше времени процессора, объема памяти, пропускной способности ввода/вывода и т. д., чем запрос, который вообще не использует рабочие процессы.

Дополнительную информацию о параллельных запросах см. в главе Параллельный запрос.

max_parallel_maintenance_workers (integer)

Задает максимальное количество параллельных рабочих процессов, которое может запустить одна служебная команда. В настоящее время единственными параллельными служебными командами, которые поддерживают использование параллельных рабочих процессов, являются CREATE INDEX (и только при построении индекса B-дерева) и 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 (выключен) снижает вероятность того, что рабочие процессы будут заблокированы из-за того, что ведущий процесс читает кортежи недостаточно быстро, но требует, чтобы ведущий процесс дожидался запуска рабочих процессов, прежде чем выдать первые кортежи. Степень положительного или отрицательного влияния ведущего процесса на производительность зависит от типа плана, числа рабочих процессов и длительности запроса.

old_snapshot_threshold (integer)

Задает минимальный период времени, в течение которого можно использовать снимок состояния для запроса без риска возникновения ошибки «snapshot too old» (снимок слишком старый). Данные, потерявшие актуальность и находящиеся в таком состоянии дольше этого периода, могут быть вычищены. Это может помочь предотвратить захламление снимками, которые остаются задействованными долгое время. Во избежание неверных результатов из-за очистки данных, которые в противном случае были бы видны в снимке, если снимок старше этого предела и используется для чтения страницы, измененной с момента его создания, то генерируется ошибка.

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

Полезные для производственной работы значения могут варьироваться от нескольких часов до нескольких дней. Малые значения (например 0 или 1min) допускаются только потому, что иногда они могут быть полезны при тестировании. Несмотря на то, что допустимо значение до 60 дней (60d), имейте в виду, что при многих рабочих нагрузках критичное «разбухание» или зацикливание идентификаторов транзакций может происходить в гораздо меньшие сроки.

Когда эта функция включена, освобожденное пространство в конце отношения нельзя отдать операционной системе, так как при этом может быть удалена информация, необходимая для выявления условия «снимок слишком стар». Все пространство, выделенное отношению, остается связанным с ним и повторно используется только в нем, пока не будет явно освобождено (например командой VACUUM FULL).

Этот параметр не дает гарантии, что данная ошибка будет генерироваться при всех возможных обстоятельствах. В действительности, если можно получить верные результаты, например, из курсора, который материализовал результирующий набор, ошибка не будет выдана, даже если нижележащие строки в ссылочной таблице были вычищены. Некоторые таблицы, например системные каталоги, невозможно безопасно очистить досрочно, поэтому данный параметр на них не повлияет. Для таких таблиц этот параметр не уменьшает раздувание, но и не чреват ошибкой «snapshot too old» (слишком старый снимок) при сканировании.