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

примечание

Эта страница переведена при помощи нейросети GigaChat.

Память

shared_buffers (integer)

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

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

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

huge_pages (enum)

Управляет запросом огромных страниц для основной общей области памяти. Допустимые значения - try (по умолчанию), on и off. Этот параметр можно установить только при запуске сервера. При установке huge_pages на try сервер попытается запросить огромные страницы, но вернется к значению по умолчанию, если это не удастся. С on сбой при запросе огромных страниц предотвратит запуск сервера. С off огромные страницы запрашиваться не будут. Фактическое состояние огромных страниц показывается серверной переменной huge_pages_status.

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

Использование огромных страниц приводит к уменьшению таблиц страниц и меньшему времени процессора, затрачиваемому на управление памятью, что повышает производительность. Для получения более подробной информации об использовании огромных страниц в Linux подробнее смотрите раздел «Страницы большого размера в Linux».

Большие страницы известны как крупные страницы в Windows. Чтобы их использовать, нужно предоставить пользователю право «Блокировать страницы в памяти» учетной записи пользователя Windows, которая запускает PostgreSQL. Можно использовать инструмент групповой политики Windows (gpedit.msc), чтобы назначить пользователю право «Блокировать страницы в памяти». Чтобы запустить сервер базы данных в командной строке как отдельный процесс, а не как службу Windows, командная строка должна быть запущена от имени администратора или должен быть отключен контроль учетных записей пользователей (UAC). Когда UAC включен, обычная командная строка отменяет пользовательское право «Блокировать страницы в памяти» при запуске.

Обратите внимание, что эта настройка влияет только на основную область общей памяти. Операционные системы, такие как Linux, FreeBSD и Illumos, также могут автоматически использовать большие страницы (также известные как «супер» страницы или «крупные» страницы) для обычного распределения памяти без явного запроса от PostgreSQL. В Linux это называется «прозрачными большими страницами» (THP). Эта функция известна тем, что вызывает ухудшение производительности с PostgreSQL у некоторых пользователей в некоторых версиях 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). Для получения дополнительной информации об использовании и поддержке подробнее смотрите раздел Большие страницы 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. Значение по умолчанию равно 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.

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

autovacuum_work_mem (integer)

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

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

vacuum_buffer_usage_limit (integer)

Указывает размер стратегии доступа к буферам, используемой командами VACUUM и ANALYZE. Значение 0 позволит операции использовать любое количество shared_buffers. В противном случае допустимые размеры варьируются от 128 kB до 16 GB. Если указанный размер превышает 1/8 размера shared_buffers, он автоматически ограничивается этим значением. Значение по умолчанию: 2 MB. Если это значение задается без единиц измерения, оно считается заданным в килобайтах. Этот параметр можно задать в любой момент. Его также можно переопределить для 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. Если значение указано без единиц измерения, оно считается заданным в блоках (размер которых равен BLCKSZ байт, обычно это 8 КБ). Значение по умолчанию — 0, которое означает, что будет использовано shared_buffers/512 блоков, но не более 1024 и не менее 16 блоков. Этот параметр можно задать только при запуске сервера.

multixact_member_buffers (integer)

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

multixact_offset_buffers (integer)

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

notify_buffers (integer)

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

serializable_buffers (integer)

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

subtransaction_buffers (integer)

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

transaction_buffers (integer)

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

max_stack_depth (integer)

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

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

shared_memory_type (enum)

Задает реализацию общей памяти, которую сервер должен использовать для основного региона общей памяти, содержащего общие буферы PostgreSQL и другие общие данные. Возможные значения включают (для анонимной общей памяти, выделяемой с использованием mmap), mmap (для общей памяти System V, выделенной через sysv) и shmget (для общей памяти Windows). Не все значения поддерживаются на всех платформах, первый поддерживаемый вариант является значением по умолчанию для этой платформы. Использование опции windows, которая не является стандартной ни на одной платформе, обычно не рекомендуется, поскольку она обычно требует нестандартных настроек ядра для разрешения больших выделений (подробнее смотрите раздел «Общая память и семафоры»). Этот параметр можно установить только при запуске сервера.

dynamic_shared_memory_type (enum)

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

min_dynamic_shared_memory (integer)

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

Диск

temp_file_limit (integer)

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

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

file_copy_method (enum)

Указывает метод копирования файлов. Возможные значения: COPY (по умолчанию) и CLONE (при поддержке ОС).

Влияет на:

• CREATE DATABASE ... STRATEGY=FILE_COPY
• ALTER DATABASE ... SET TABLESPACE ...

CLONE использует системные вызовы copy_file_range() (Linux, FreeBSD) или copyfile (macOS), позволяя ядру совместно использовать дисковые блоки или делегировать работу нижним уровням файловой системы.

file_extend_method (enum)

Указывает метод расширения файлов данных при массовых операциях, таких как COPY. По умолчанию применяется первый доступный вариант в зависимости от ОС:

• posix_fallocate (Unix) — стандартный интерфейс POSIX для выделения дискового пространства. Отсутствует в некоторых системах. Если вызов присутствует, но ФС его не поддерживает, происходит автоматический откат к write_zeros. В актуальных версиях Btrfs этот метод отключает сжатие. Является значением по умолчанию при наличии функции.
• write_zeros — расширение файлов записью блоков нулей. Является значением по умолчанию при отсутствии posix_fallocate.

Метод write_zeros всегда используется при расширении файлов данных на 8 блоков или меньше.

max_notify_queue_pages (integer)

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

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

max_files_per_process (integer)

Устанавливает максимальное количество открытых файлов, которые каждый подпроцесс сервера может открыть одновременно; файлы, уже открытые в главном процессе, не учитываются в этом лимите. Значение по умолчанию — тысяча файлов.

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

bgwriter

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

bgwriter_delay (integer)

Задает задержку между циклами активности фонового писателя. В каждом цикле писатель выдает команды записи для некоторого количества поврежденных буферов (управляемых следующими параметрами). Затем он засыпает на длину bgwriter_delay, а затем повторяется. Если в пуле буфера нет поврежденных буферов, то он переходит в более длительный сон независимо от bgwriter_delay. Если это значение указано без единиц измерения, оно принимается за миллисекунды. Значение по умолчанию составляет 200 миллисекунд (200ms), не зависящее от bgwriter_delay. Обратите внимание, что во многих системах эффективное разрешение задержек сна составляет 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 представляет собой политику "точно вовремя" записи ровно такого количества буферов, которое, как ожидается, потребуется. Более высокие значения обеспечивают определенную защиту от всплесков спроса, тогда как меньшие значения намеренно оставляют записи для выполнения серверными процессами. По умолчанию установлено значение 2,0. Этот параметр можно настроить только в файле postgresql.conf или в командной строке сервера.

bgwriter_flush_after (integer)

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

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

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

backend_flush_after (integer)

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

effective_io_concurrency (integer)

Задает количество одновременных операций ввода-вывода хранилища, которые, по мнению PostgreSQL, могут выполняться одновременно. Увеличение этого значения приведет к увеличению количества операций ввода-вывода, которые любая отдельная сессия PostgreSQL попытается инициировать параллельно. Допустимый диапазон значений — от 1 до 1000, или 0 для отключения отправки асинхронных запросов ввода-вывода. Значение по умолчанию — 16.

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

В системах с поддержкой рекомендаций предварительной выборки параметр effective_io_concurrency также управляет расстоянием предварительной выборки.

Это значение можно переопределить для таблиц в конкретном табличном пространстве, задав параметр табличного пространства с тем же именем (подробнее смотрите ALTER TABLE SPACE).

maintenance_io_concurrency (integer)

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

Значение по умолчанию — 16. Это значение можно переопределить для таблиц в конкретном табличном пространстве, задав параметр табличного пространства с тем же именем (подробнее смотрите ALTER TABLE SPACE).

io_max_combine_limit (integer)

Управляет максимальным размером операции ввода-вывода в операциях, объединяющих I/O, и неявно ограничивает пользовательский параметр io_combine_limit. Параметр можно задать только при запуске сервера. Если значение указано без единиц измерения, оно интерпретируется в блоках (BLCKSZ байт, обычно 8 КБ). Максимально возможный размер зависит от ОС и размера блока, но обычно составляет 1 МБ на Unix и 128 КБ на Windows. По умолчанию — 128 КБ.

io_combine_limit (integer)

Управляет максимальным размером операции ввода-вывода в операциях, объединяющих I/O. Если значение превышает io_max_combine_limit, silently используется меньшее из двух, поэтому для увеличения размера I/O может потребоваться поднять оба параметра. Если значение указано без единиц измерения, оно интерпретируется в блоках (BLCKSZ байт, обычно 8 КБ). Максимально возможный размер зависит от ОС и размера блока, но обычно составляет 1 МБ на сборках для Unix и 128 КБ на Windows. По умолчанию — 128 КБ.

io_max_concurrency (integer)

Управляет максимальным количеством операций ввода-вывода, которые один процесс может выполнять одновременно.

Значение по умолчанию -1 выбирает количество на основе shared_buffers и максимального числа процессов (max_connections, autovacuum_worker_slots, max_worker_processes и max_wal_senders), но не более 64.

Параметр можно задать только при запуске сервера.

io_method (enum)

Выбирает метод выполнения асинхронного ввода-вывода. Возможные значения:

• worker — выполнение асинхронного I/O через рабочие процессы.
• io_uring — выполнение асинхронного I/O через io_uring (требуется сборка с --with-liburing / -Dliburing).
• sync — синхронное выполнение I/O-операций, которые могли бы быть асинхронными.

По умолчанию — worker.

Параметр можно задать только при запуске сервера.

io_workers (integer)

Задает количество рабочих процессов для ввода-вывода. По умолчанию — 3. Параметр можно задать только в файле postgresql.conf или в командной строке сервера.

Действует только если io_method установлен в worker.

Рабочие процессы

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. Установка этого значения равным нулю отключает параллельное выполнение запросов.

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

max_parallel_maintenance_workers (integer)

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

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

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