Потребление ресурсов
Эта страница переведена при помощи нейросети GigaChat.
Память
shared_buffers (integer)
Устанавливает объем памяти, который сервер баз данных использует для общих буферов памяти. По умолчанию это обычно 128 мегабайт (128MB), но может быть меньше, если настройки ядра не поддерживают его (как определено во время initdb). Это значение должно быть не менее 128 килобайт. Однако для хорошей производительности обычно требуются значения значительно выше минимального. Если это значение указано без единиц измерения, оно принимается за блоки, то есть BLCKSZ байт, обычно 8 кБ. (Не стандартные значения BLCKSZ изменяют минимальное значение.) Этот параметр можно установить только при запуске сервера.
Если есть выделенный сервер баз данных с 1 ГБ или более оперативной памяти, разумное начальное значение для shared_buffers составляет 25% от объема памяти системы. Существуют некоторые рабочие нагрузки, где даже большие значения для shared_buffers эффективны, но поскольку PostgreSQL также полагается на кеш операционной системы, маловероятно, что выделение более 40% ОЗУ для 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)
Устанавливает максимальное количество транзакций, которые могут находиться в состоянии «подготовлено» одновременно (см. ПОДГОТОВИТЬ ТРАНЗАКЦИЮ). Установка этого параметра равным нулю (что является значением по умолчанию) отключает функцию подготовленной транзакции. Этот параметр можно установить только при запуске сервера.
Если не планируется использовать подготовленные транзакции, этот параметр должен быть установлен равным нулю для предотвращения случайного создания подготовленных транзакций. Если используется подготовленные транзакции, вероятно, потребуется 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 . Следует отметить, что дисковое пространство, используемое для явных временных таблиц, в отличие от временных файлов, используемых за кулисами при выполнении запросов, не учитывается против этого ограничения.
max_notify_queue_pages (integer)
Задает максимальное количество выделенных страниц для очереди NOTIFY / LISTEN. Значение по умолчанию — 1048576. Для страниц размером 8 КБ позволяет использовать до 8 ГБ дискового пространства.
Использование ресурсов ядра
max_files_per_process (integer)
Устанавливает максимальное количество файлов, которые могут быть одновременно открыты для каждого серверного подпрцесса. По умолчанию это одна тысяча файлов. Если ядро обеспечивает безопасный предел на процесс, не нужно беспокоиться об этом параметре. Но на некоторых платформах (особенно на большинстве систем BSD) ядро позволит отдельным процессам открывать гораздо больше файлов, чем система может фактически поддерживать, если многие процессы попытаются открыть столько же файлов. Если обнаруживаются ошибки с сообщением «Слишком много открытых файлов», попробуйте уменьшить этот параметр. Этот параметр можно установить только при запуске сервера.
Отложенная очистка на основе затрат
Во время выполнения команд 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_delay настолько маленьким, насколько платформа будет последовательно измерять; большие задержки бесполезны.
vacuum_cost_page_hit (integer)
Оцениваемая стоимость вакуумирования буфера, найденного в общем кеше буферов. Она представляет собой стоимость блокировки пула буферов, поиска общей хеш-таблицы и сканирования содержимого страницы. Значение по умолчанию равно единице.
vacuum_cost_page_miss (integer)
Оцениваемая стоимость вакуумирования буфера, который необходимо прочитать с диска. Это представляет усилия по блокировке пула буферов, поиску общей хеш-таблицы, чтению нужного блока из диска и сканированию его содержимого. Значение по умолчанию равно двум.
vacuum_cost_page_dirty (integer)
Оцениваемая стоимость, взимаемая при изменении вакуума блока, который ранее был чистым. Он представляет собой дополнительные требования к вводу-выводу, необходимые для повторного сброса поврежденного блока на диск. Значение по умолчанию равно двадцати.
vacuum_cost_limit (integer)
Общая стоимость, при накоплении которой процесс очистки будет засыпать на время, указанное в vacuum_cost_delay. Значение по умолчанию равно 200.
Существуют определенные операции, которые удерживают критические блокировки и поэтому должны быть выполнены как можно быстрее. Задержки вакуума, основанные на затратах, не происходят во время таких операций. Поэтому возможно, что затраты накапливаются гораздо выше указанного предела. Чтобы избежать бесполезных длительных задержек в таких случаях, фактическая задержка рассчитывается как vacuum_cost_delay * accumulated_balance / vacuum_cost_limit с максимальным значением vacuum_cost_delay * 4.
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 или ноль для отключения выдачи асинхронных запросов ввода-вывода. В настоящее время эта настройка влияет только на сканирование битового кучи.
Для магнитных дисков хорошей отправной точкой для этой настройки является количество отдельных дисков, составляющих RAID 0 полосу или зеркало RAID 1, используемое для базы данных. (Для RAID 5 диск четности не следует учитывать). Однако, если база данных часто занята несколькими запросами, выданными в параллельных сеансах, более низкие значения могут быть достаточными для поддержания работы массива дисков. Значение выше необходимого для загрузки дисков приведет лишь к дополнительной нагрузке на процессор. SSD и другие устройства хранения на основе памяти часто могут обрабатывать множество одновременных запросов, поэтому наилучшее значение может находиться в сотнях.
Асинхронный ввод-вывод зависит от эффективной функции posix_fadvise, которой некоторые операционные системы не обладают. Если функция отсутствует, то установка этого параметра на любое значение, отличное от нуля, приведет к ошибке. В некоторых операционных системах (например, Solaris) функция присутствует, но фактически ничего не делает.
По умолчанию установлено значение 1 для поддерживаемых систем, иначе 0. Это значение может быть переопределено для таблиц в определенном табличном пространстве путем установки параметра табличного пространства с тем же именем (см. ИЗМЕНИТЬ ТАБЛИЧНОЕ ПРОСТРАНСТВО).
maintenance_io_concurrency (integer)
Аналогично effective_io_concurrency, но используется для выполнения работ по техническому обслуживанию от имени нескольких клиентских сеансов.
По умолчанию установлено значение 10 для поддерживаемых систем, иначе 0. Это значение может быть переопределено для таблиц в определенном табличном пространстве путем установки параметра табличного пространства с тем же именем (см. ИЗМЕНИТЬ ТАБЛИЧНОЕ ПРОСТРАНСТВО).
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. Установка этого значения равным нулю отключает параллельное выполнение запросов.
Обратите внимание, что параллельные запросы могут потреблять значительно больше ресурсов, чем непараллельные запросы, поскольку каждый рабочий процесс является полностью отдельным процессом, который оказывает примерно такое же влияние на систему, как и дополнительное пользовательское сеанс. Это следует учитывать при выборе значения для этого параметра, а также при настройке других параметров, которые контролируют использование ресурсов, таких как work_mem. Ограничения ресурсов, такие как work_mem, применяются индивидуально к каждому рабочему процессу, что означает, что общее потребление может быть намного выше во всех процессах, чем это было бы нормально для любого отдельного процесса. Например, параллельный запрос с использованием 4 рабочих процессов может использовать до 5 раз больше времени ЦП, памяти, пропускной способности ввода-вывода и т.д., чем запрос, который вообще не использует рабочие процессы.
max_parallel_maintenance_workers (integer)
Устанавливает максимальное количество параллельных рабочих процессов, которые могут быть запущены одной служебной командой. В настоящее время служебные команды параллельного выполнения, поддерживающие использование параллельных рабочих процессов, являются только CREATE INDEX при создании индекса B-дерева или 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 снижает вероятность того, что работники будут заблокированы из-за того, что лидер недостаточно быстро считывает кортежи, но требует, чтобы ведущий процесс ожидал запуска рабочих процессов перед тем, как можно будет произвести первые кортежи. Степень, в которой лидер может помочь или помешать производительности, зависит от типа плана, количества работников и продолжительности выполнения запроса.