18.4. Расход ресурсов#
18.4. Расход ресурсов #
18.4.1. Память #
shared_buffers(integer) #Устанавливает количество памяти, которое использует сервер базы данных для разделяемых буферов памяти. По умолчанию обычно устанавливается 128 мегабайт (
128MB), но может быть меньше, если настройки ядра не поддерживают такое значение (как определяется во время выполнения initdb). Это значение должно быть не менее 128 килобайт. Однако, для хорошей производительности обычно требуются значительно более высокие значения. Если это значение указано без единиц измерения, оно считается заданным в блоках, то естьBLCKSZбайт, обычно 8 кБ. (Нестандартные значенияBLCKSZизменяют минимальное значение). Этот параметр может быть установлен только при запуске сервера.Если у вас есть выделенный сервер баз данных с 1 ГБ или более оперативной памяти, разумным начальным значением для
shared_buffersбудет 25% от объема памяти в вашей системе. Есть некоторые рабочие нагрузки, где даже большие значения дляshared_buffersэффективны, но поскольку Tantor BE также полагается на кеш операционной системы, маловероятно, что выделение более 40% оперативной памяти дляshared_buffersбудет работать лучше, чем меньшее количество. Большие значения дляshared_buffersобычно требуют соответствующего увеличенияmax_wal_size, чтобы распределить процесс записи больших объемов новых или измененных данных на более длительный период времени.На системах с объемом оперативной памяти менее 1 ГБ, рекомендуется использовать меньший процент от объема памяти, чтобы оставить достаточно места для операционной системы.
-
shared_buffer_partitions_log2(integer) # Устанавливает количество разделов, используемых для отображения общих буферов, выраженное в виде логарифма по основанию 2. Это помогает уменьшить конкуренцию при доступе к отображению общих буферов. Значение по умолчанию —
7(т.е. 128 разделов). Значение должно быть между7и11(т.е. от 128 до 2048 разделов). Этот параметр можно установить только при запуске сервера.huge_pages(enum) #Управляет тем, запрашиваются ли большие страницы памяти для основной области разделяемой памяти. Допустимые значения:
try(по умолчанию),onиoff. Этот параметр можно установить только при запуске сервера. Еслиhuge_pagesустановлен вtry, сервер попытается запросить большие страницы, но вернётся к значению по умолчанию, если это не удастся. При значенииonневозможность выделения больших страниц не позволит серверу запуститься. При значенииoffбольшие страницы запрашиваться не будут. Фактическое состояние использования больших страниц отображается в серверной переменной huge_pages_status.В настоящее время этот параметр поддерживается только в Linux. Параметр игнорируется в других системах, если установлен в значение
try. В Linux он поддерживается только тогда, когдаshared_memory_typeустановлен вmmap(по умолчанию).Использование огромных страниц приводит к уменьшению размера таблиц страниц и сокращению времени ЦП, затрачиваемого на управление памятью, что повышает производительность. Дополнительные сведения о использовании огромных страниц в Linux см. в разделе Раздел 17.4.5.
Обратите внимание, что этот параметр влияет только на основную область разделяемой памяти. Операционные системы, такие как Linux, также могут автоматически использовать большие страницы (также известные как “super” страницы или “large” страницы) для обычного распределения памяти, без явного запроса со стороны Tantor BE. В Linux это называется “прозрачные большие страницы” (THP). Известно, что эта функция вызывает снижение производительности с Tantor BE у некоторых пользователей на некоторых версиях 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). Дополнительную информацию о использовании и поддержке см. в Раздел 17.4.5.На данный момент на Linux поддерживаются только нестандартные настройки.
-
lock_partitions_log2(integer) # Устанавливает количество разделов в менеджере блокировок, выраженное в виде логарифма по основанию 2. Разделение помогает уменьшить конкуренцию за блокировки. Значение по умолчанию —
2(т.е. 4 раздела), с допустимыми значениями от2до8(т.е. от 4 до 256 разделов). Этот параметр можно установить только при запуске сервера.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приводит к нехватке памяти (недостаток памяти обычно проявляется в виде периодических ошибок "out of memory"). Значение по умолчанию 2.0 часто является эффективным для смешанных рабочих нагрузок. Более высокие значения в диапазоне от 2.0 до 8.0 или более могут быть эффективными в средах, где параметрwork_memуже был увеличен до 40 МБ или более.maintenance_work_mem(integer) #Определяет максимальный объем памяти, используемый операциями обслуживания, такими как
VACUUM,CREATE INDEXиALTER TABLE ADD FOREIGN KEY. Если это значение указано без единиц измерения, оно считается заданным в килобайтах. По умолчанию установлено значение 64 мегабайта (64MB). Поскольку только одна из этих операций может выполняться одновременно сессией базы данных, и обычно установлено небольшое количество таких операций, безопасно установить это значение значительно больше, чемwork_mem. Более высокие значения могут улучшить производительность при выполнении операций очистки и восстановления базы данных.Обратите внимание, что при запуске автоочистки может быть выделено памяти до autovacuum_max_workers раз, поэтому будьте осторожны с установкой слишком высокого значения по умолчанию. Может быть полезно контролировать это, отдельно устанавливая autovacuum_work_mem.
autovacuum_work_mem(integer) #Указывает максимальный объем памяти, который будет использоваться каждым рабочим процессом автоочистки. Если это значение указано без единиц измерения, оно считается заданным в килобайтах. По умолчанию оно равно -1, что означает, что вместо него будет использоваться значение maintenance_work_mem. Это значение не влияет на поведение команды
VACUUMпри выполнении в других контекстах. Этот параметр может быть установлен только в файлеpostgresql.confили в командной строке сервера.-
vacuum_buffer_usage_limit(integer) # Задает размер Стратегии Доступа к Буферу, используемой командами
VACUUMиANALYZE. Установка значения0позволит операции использовать любое количествоshared_buffers. В противном случае допустимые размеры варьируются от128 kBдо16 GB. Если указанный размер превышает 1/8 размераshared_buffers, размер будет тихо ограничен этим значением. Значение по умолчанию —2MB. Если это значение указано без единиц измерения, оно принимается за килобайты. Этот параметр может быть установлен в любое время. Он может быть переопределен для VACUUM и ANALYZE при передаче опцииBUFFER_USAGE_LIMIT. Более высокие значения могут позволить командамVACUUMиANALYZEвыполняться быстрее, но слишком большое значение может привести к вытеснению слишком большого количества других полезных страниц из общих буферов.logical_decoding_work_mem(integer) #Ограничивает максимальный объем памяти, используемой логическим декодированием, до того, как некоторые декодированные изменения будут записаны на локальный диск. Это ограничивает объем памяти, используемый подключениями для логической потоковой репликации. По умолчанию установлено значение 64 мегабайта (
64MB). Поскольку каждое подключение для репликации использует только один буфер этого размера, и обычно установка имеет немного таких соединений одновременно (ограничено параметромmax_wal_senders), безопасно установить это значение значительно выше значенияwork_mem, что уменьшит объем декодированных изменений, записываемых на диск.commit_timestamp_buffers(integer) #Указывает объем памяти, используемой для кеширования содержимого
pg_commit_ts(см. Таблица 64.1). Если это значение указано без единиц измерения, оно принимается как блоки, то естьBLCKSZбайт, обычно 8kB. Значение по умолчанию —0, что запрашиваетshared_buffers/512 до 1024 блоков, но не менее 16 блоков. Этот параметр можно установить только при запуске сервера.multixact_member_buffers(integer) #Указывает количество общей памяти, используемой для кеширования содержимого
pg_multixact/members(см. Таблица 64.1). Если это значение указано без единиц измерения, оно принимается за блоки, то естьBLCKSZбайт, обычно 8kB. Значение по умолчанию —32. Этот параметр можно установить только при запуске сервера.multixact_offset_buffers(integer) #Указывает количество общей памяти, используемой для кеширования содержимого
pg_multixact/offsets(см. Таблица 64.1). Если это значение указано без единиц измерения, оно принимается за блоки, то естьBLCKSZбайт, обычно 8kB. Значение по умолчанию —16. Этот параметр можно установить только при запуске сервера.notify_buffers(integer) #Указывает объем общей памяти, используемой для кеширования содержимого
pg_notify(см. Таблица 64.1). Если это значение указано без единиц измерения, оно принимается за блоки, то естьBLCKSZбайт, обычно 8kB. Значение по умолчанию —16. Этот параметр можно установить только при запуске сервера.serializable_buffers(integer) #Указывает количество общей памяти, используемой для кеширования содержимого
pg_serial(см. Таблица 64.1). Если это значение указано без единиц измерения, оно принимается за блоки, то естьBLCKSZбайт, обычно 8kB. Значение по умолчанию —32. Этот параметр можно установить только при запуске сервера.subtransaction_buffers(integer) #Указывает количество общей памяти, используемой для кеширования содержимого
pg_subtrans(см. Таблица 64.1). Если это значение указано без единиц измерения, оно принимается за блоки, то естьBLCKSZбайт, обычно 8кБ. Значение по умолчанию —0, что запрашиваетshared_buffers/512 до 1024 блоков, но не менее 16 блоков. Этот параметр можно установить только при запуске сервера.transaction_buffers(integer) #Указывает количество общей памяти, используемой для кеширования содержимого
pg_xact(см. Таблица 64.1). Если это значение указано без единиц измерения, оно принимается за блоки, то естьBLCKSZбайт, обычно 8kB. Значение по умолчанию —0, что запрашиваетshared_buffers/512 до 1024 блоков, но не менее 16 блоков. Этот параметр можно установить только при запуске сервера.max_stack_depth(integer) #Указывает максимально безопасную глубину стека выполнения сервера. Идеальное значение для этого параметра - фактический лимит размера стека, установленный ядром (как установлено с помощью
ulimit -sили аналогичной локальной команды), за вычетом запасного маржина в один мегабайт или около того. Запасной маржин необходим, потому что глубина стека не проверяется в каждой процедуре в сервере, а только в ключевых потенциально рекурсивных процедурах. Если это значение указано без единиц измерения, оно считается заданным в килобайтах. Значение по умолчанию - два мегабайта (2MB), что является консервативно малым и маловероятно вызовет сбои. Однако, это может быть слишком мало для выполнения сложных функций. Изменить это значение могут только суперпользователи и пользователи с соответствующими привилегиямиSET.Установка переменной
max_stack_depthвыше фактического ограничения ядра означает, что бесконечно рекурсивная функция может вызвать сбой в отдельном процессе сервера. На платформах, где Tantor BE может определить ограничение ядра, сервер не позволит установить эту переменную на небезопасное значение. Однако не все платформы предоставляют эту информацию, поэтому рекомендуется быть осторожным при выборе значения.shared_memory_type(enum) #Указывает реализацию разделяемой памяти, которую сервер должен использовать для основной области разделяемой памяти, содержащей разделяемые буферы и другие общие данные Tantor SE. Возможные значения:
mmap(для анонимной разделяемой памяти, выделяемой с помощьюmmap) иsysv(для разделяемой памяти System V, выделяемой черезshmget). Не все значения поддерживаются на всех платформах; первый поддерживаемый вариант является значением по умолчанию для данной платформы. Использование опцииsysv, которая не является значением по умолчанию ни на одной платформе, обычно не рекомендуется, так как, как правило, требует нестандартных настроек ядра для разрешения больших выделений памяти (см. Раздел 17.4.1). Этот параметр можно задать только при запуске сервера.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(отсутствует). Этот параметр может быть установлен только при запуске сервера.enable_large_allocations(boolean) #Позволяет выделять память для объектов до
2 ГБ, вместо старого лимита в1 ГБ. Это не влияет на максимальный размер поля.Значение по умолчанию —
off. Этот параметр можно установить в рамках пользовательской сессии спривилегиями суперпользователяс помощью командыSET, а также для всех подключений в конфигурации postgresql.conf сenable_large_allocations = on. Следует включать только при необходимости обработки определенных полей таблицы.Использование: Устраняет проблемы переполнения буфера при сериализации/десериализации типов данных
bytea,text, с размерами от 0.5 до 1 ГБ, во время клиентских запросов, создания дампов базы данных с pg_dump, pg_dumpall, и загрузки дампов базы данных с pg_restore.Примечание
При сохранении данных в таблицу проверки размера не выполняются, поэтому когда этот параметр установлен и будет попытка сохранить объект с размером, превышающим старый допустимый предел размера поля (1 Гб), это может привести к неопределенному поведению и, скорее всего, к потере данных. Поэтому вы должны указывать этот параметр только для небольшого диапазона задач, требующих большого объема памяти для временных задач, но чтобы избежать потери данных, не используйте его на регулярной основе.
18.4.2. Диск #
temp_file_limit(integer) #Ограничивает максимальный объем дискового пространства, которое процесс может использовать для временных файлов, таких как временные файлы сортировки и хеширования, или файл хранения для удерживаемого курсора. Транзакция, пытающаяся превысить это ограничение, будет отменена. Если это значение указано без единиц измерения, оно считается заданным в килобайтах. Значение
-1(по умолчанию) означает отсутствие ограничения. Изменить это значение могут только суперпользователи и пользователи с соответствующими привилегиямиSET.Этот параметр ограничивает общее пространство, используемое в любой момент времени всеми временными файлами, используемыми процессом Tantor BE. Следует отметить, что дисковое пространство, используемое для явных временных таблиц, в отличие от временных файлов, используемых внутри запросов, не учитывается при подсчете этого ограничения.
file_copy_method(enum) #Задает метод копирования файлов. Возможные значения:
COPY(по умолчанию) иCLONE(если поддерживается операционной системой).Этот параметр влияет на:
CREATE DATABASE ... STRATEGY=FILE_COPYALTER DATABASE ... SET TABLESPACE ...
CLONEиспользует системные вызовыcopy_file_range()(Linux), предоставляя ядру возможность совместно использовать дисковые блоки или передавать работу на нижние уровни в некоторых файловых системах.file_extend_method(enum) #Определяет метод расширения файлов данных во время массовых операций, таких как
COPY. В качестве значения по умолчанию используется первое доступное значение, в зависимости от операционной системы:При значении
posix_fallocate(Unix) используется стандартный интерфейс POSIX для выделения дискового пространства, но этот интерфейс отсутствует на некоторых системах. Если для параметра установлено это значение, но используемая файловая система его не поддерживает, его значение автоматически меняется наwrite_zeros. Текущие версии BTRFS отключают сжатие при использовании этой опции. Это значение используется по умолчанию на системах, в которых присутствует функцияposix_fallocate.При значении
write_zerosрасширение файлов происходит путём добавления блоков с нулевыми байтами. Это значение используется по умолчанию на системах, в которых отсутствует функцияposix_fallocate.
Метод
write_zerosвсегда используется, если файлы данных расширяются на 8 блоков или меньше.max_notify_queue_pages(integer) #Указывает максимальное количество выделенных страниц для NOTIFY / LISTEN очереди. Значение по умолчанию — 1048576. Для страниц размером 8 КБ это позволяет использовать до 8 ГБ дискового пространства. Этот параметр можно задать только при запуске сервера.
18.4.3. Использование ресурсов ядра #
max_files_per_process(integer) #Задает максимальное количество файлов, которые может одновременно открывать каждый подпроцесс сервера; файлы, уже открытые в postmaster, не учитываются в этом лимите. По умолчанию разрешено открывать одну тысячу файлов.
Если ядро обеспечивает безопасный лимит по процессам, можно не беспокоиться об этом параметре. Но на некоторых платформах (в частности, на большинстве систем BSD) ядро позволяет отдельным процессам открывать гораздо больше файлов, чем несколько процессов могут открывать одновременно. Если вы сталкиваетесь с ошибками “Слишком много открытых файлов (Too many open files)”, попробуйте уменьшить это значение. Этот параметр можно задать только при запуске сервера.
18.4.4. Фоновый записывающий процесс #
Существует отдельный серверный процесс, называемый фоновым писателем, задача которого заключается в записи “грязных” (новых или измененных) общих буферов. Когда количество чистых общих буферов кажется недостаточным, фоновый записывающий процесс записывает некоторые грязные буферы на файловую систему и помечает их как чистые. Это снижает вероятность того, что серверные процессы, обрабатывающие пользовательские запросы, не смогут найти чистые буферы и придется записывать грязные буферы самостоятельно. Однако фоновый записывающий процесс действительно вызывает общий увеличение нагрузки на ввод-вывод, потому что, в то время как повторно загрязненная страница в противном случае может быть записана только один раз за интервал контрольной точки, фоновый записывающий процесс может записать ее несколько раз, поскольку она загрязняется в том же интервале. Параметры, обсуждаемые в этом подразделе, могут быть использованы для настройки поведения в соответствии с локальными потребностями.
bgwriter_delay(integer) #Указывает задержку между раундами активности для фонового писателя. В каждом раунде писатель выполняет записи для некоторого количества грязных буферов (управляемого следующими параметрами). Затем он засыпает на длину
bgwriter_delayи повторяет. Однако, когда в пуле буферов нет грязных буферов, он переходит в более длительный сон независимо отbgwriter_delay. Если это значение указано без единиц измерения, оно принимается в миллисекундах. Значение по умолчанию — 200 миллисекунд (200ms). Обратите внимание, что на некоторых системах эффективное разрешение задержек сна составляет 10 миллисекунд; установкаbgwriter_delayна значение, не кратное 10, может иметь те же результаты, что и установка его на следующее большее кратное 10. Этот параметр можно установить только в файлеpostgresql.confили в командной строке сервера.bgwriter_lru_maxpages(integer) #В каждом раунде фоновым писателем будет записано не более этого количества буферов. Установка этого значения в ноль отключает фоновую запись. (Обратите внимание, что контрольные точки, которые управляются отдельным, выделенным вспомогательным процессом, не затрагиваются). Значение по умолчанию - 100 буферов. Этот параметр может быть установлен только в файле
postgresql.confили в командной строке сервера.bgwriter_lru_multiplier(floating point) #Количество грязных буферов, записываемых за каждый раунд, определяется на основе количества новых буферов, которые были необходимы серверным процессам в последние раунды. Средняя недавняя потребность умножается на
bgwriter_lru_multiplierдля получения оценки количества буферов, которые будут необходимы в следующем раунде. Грязные буферы записываются до тех пор, пока не будет доступно такое же количество чистых, повторно используемых буферов. (Однако за один раунд будет записано не болееbgwriter_lru_maxpagesбуферов). Таким образом, значение 1.0 представляет собой политику "вовремя" записи ровно того количества буферов, которое предполагается необходимым. Большие значения обеспечивают некоторую подушку от всплесков спроса, в то время как меньшие значения намеренно оставляют записи для выполнения серверными процессами. Значение по умолчанию - 2.0. Этот параметр может быть установлен только в файлеpostgresql.confили в командной строке сервера.bgwriter_flush_after(integer) #Когда количество данных, записанных фоновым писателем, превышает эту величину, попытаться заставить ОС выполнять запись этих данных на нижележащее хранилище. Это позволит ограничить количество грязных данных в кеше страниц ядра, уменьшая вероятность задержек при выполнении
fsyncв конце контрольной точки или при записи ОС данных в больших пакетах в фоновом режиме. Часто это приводит к существенному снижению задержки транзакций, но также есть случаи, особенно с рабочими нагрузками, которые больше, чем shared_buffers, но меньше, чем кеш страниц ОС, где производительность может ухудшиться. На некоторых платформах это значение может не иметь эффекта. Если это значение указано без единиц измерения, оно принимается в блоках, то естьBLCKSZбайт, обычно 8 КБ. Допустимый диапазон значений находится между0, что отключает принудительную запись, и2 МБ. По умолчанию на Linux установлено значение512 КБ, в других случаях -0. (ЕслиBLCKSZне равно 8 КБ, значения по умолчанию и максимальные значения масштабируются пропорционально этому значению). Этот параметр может быть установлен только в файлеpostgresql.confили в командной строке сервера.
Меньшие значения bgwriter_lru_maxpages и
bgwriter_lru_multiplier снижают дополнительную нагрузку на ввод-вывод,
вызванную фоновым писателем, но увеличивают вероятность того, что серверные
процессы будут вынуждены выполнять записи самостоятельно, что замедлит интерактивные
запросы.
18.4.5. I/O #
backend_flush_after(integer) #Всякий раз, когда одним бэкендом было записано больше этого количества данных, попытайтесь заставить ОС выполнять эти записи в основное хранилище. Это позволит ограничить количество грязных данных в кеше страниц ядра, уменьшая вероятность задержек при выполнении
fsyncв конце контрольной точки или когда ОС записывает данные обратно в больших пакетах в фоновом режиме. Часто это приводит к существенному снижению задержки транзакции, но также есть случаи, особенно с рабочими нагрузками, которые больше, чем shared_buffers, но меньше, чем кеш страниц ОС, где производительность может ухудшиться. Эта настройка может не иметь эффекта на некоторых платформах. Если это значение указано без единиц измерения, оно принимается в блоках, то есть в байтахBLCKSZ, обычно 8 кБ. Допустимый диапазон значений составляет от0, что отключает принудительную запись, до2MB. По умолчанию установлено значение0, то есть принудительная запись отключена. (ЕслиBLCKSZне равно 8 кБ, максимальное значение масштабируется пропорционально ему).effective_io_concurrency(integer) #Устанавливает количество параллельных операций ввода-вывода из хранилища, которое сообщает Tantor BE сколько операций ввода-вывода могут быть выполнены одновременно. Увеличение этого значения повысит количество операций ввода-вывода, которые Tantor BE будет пытаться выполнить параллельно в отдельной сессии. Допустимый диапазон — от
1до1000, либо0для отключения отправки асинхронных запросов ввода-вывода. Значение по умолчанию —16.Более высокие значения будут иметь наибольшее влияние на хранилища с высокой задержкой, где запросы в противном случае испытывают заметные задержки ввода-вывода, а также на устройствах с высокой производительностью по операциям ввода-вывода (IOPs). Необоснованно высокие значения могут увеличить задержку ввода-вывода для всех запросов в системе.
На системах с поддержкой подсказок предвыборки (prefetch advice),
effective_io_concurrencyтакже управляет расстоянием предвыборки.Это значение можно переопределить для таблиц в определённом табличном пространстве, установив параметр табличного пространства с тем же именем (см. ALTER TABLESPACE).
maintenance_io_concurrency(integer) #Аналогично
effective_io_concurrency, но используется для обслуживающих работ, выполняемых от имени множества клиентских сессий.Значение по умолчанию —
16. Это значение можно переопределить для таблиц в определённом табличном пространстве, установив параметр табличного пространства с тем же именем (см. ALTER TABLESPACE).io_max_combine_limit(integer) #Управляет максимальным размером ввода-вывода в операциях, которые объединяют ввод-вывод, и неявно ограничивает настраиваемый пользователем параметр
io_combine_limit. Этот параметр может быть установлен только при запуске сервера. Если это значение указано без единиц измерения, оно принимается за количество блоков, то естьBLCKSZбайт, обычно 8kB. Максимально возможный размер зависит от операционной системы и размера блока, но обычно составляет 1MB в Unix. Значение по умолчанию — 128kB.io_combine_limit(integer) #Управляет максимальным размером ввода-вывода (I/O) в операциях, которые объединяют I/O. Если установлено значение выше параметра
io_max_combine_limit, будет молча использовано меньшее значение, поэтому для увеличения размера I/O может потребоваться повысить оба параметра. Если это значение указано без единиц измерения, оно принимается за блоки, то есть байтыBLCKSZ, обычно 8 кБ. Максимально возможный размер зависит от операционной системы и размера блока, но обычно составляет 1 МБ в Unix. Значение по умолчанию — 128 кБ.io_max_concurrency(integer) #Задает максимальное количество операций ввода-вывода, которые один процесс может выполнять одновременно.
Значение по умолчанию
-1выбирает число на основе shared_buffers и максимального количества процессов (max_connections, autovacuum_worker_slots, max_worker_processes и max_wal_senders), но не более64.Параметр может быть установлен только при запуске сервера.
io_method(enum) #Выбирает метод выполнения асинхронного ввода-вывода. Возможные значения:
worker(выполнять асинхронный ввод-вывод с помощью рабочих процессов)sync(синхронно выполнять операции ввода-вывода, которые можно выполнять асинхронно)
По умолчанию используется
worker.Параметр может быть установлен только при запуске сервера.
io_workers(integer) #Выбирает количество рабочих процессов ввода-вывода. Значение по умолчанию — 3. Этот параметр можно задать только в файле
postgresql.confили в командной строке сервера.Работает, только если для io_method выбрано
worker.
18.4.6. Рабочие процессы #
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 раз больше времени ЦП, памяти, пропускной способности ввода-вывода и так далее, чем запрос, который не использует рабочие процессы.Для получения дополнительной информации о параллельном запросе см. Глава 15.
max_parallel_maintenance_workers(integer) #Устанавливает максимальное количество параллельных рабочих процессов, которые могут быть запущены одной командой. В настоящее время следующие служебные команды поддерживают использование параллельных рабочих процессов:
CREATE INDEXпри создании индекса B-tree, GIN или 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снижает вероятность блокировки рабочих процессов из-за того, что лидер не читает кортежи достаточно быстро, но требует ожидания рабочих процессов перед тем, как можно будет произвести первые кортежи. Степень, в которой лидер может помочь или затруднить производительность, зависит от типа плана, количества рабочих процессов и продолжительности запроса.