19.4. Расход ресурсов#

19.4. Расход ресурсов

19.4. Расход ресурсов #

19.4.1. Память #

shared_buffers (integer) #

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

Если у вас есть выделенный сервер баз данных с 1 ГБ или более оперативной памяти, разумным начальным значением для shared_buffers будет 25% от объема памяти в вашей системе. Есть некоторые рабочие нагрузки, где даже большие значения для shared_buffers эффективны, но поскольку Tantor SE также полагается на кеш операционной системы, маловероятно, что выделение более 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 и Windows. На других системах она игнорируется, если установлена в значение try. В Linux она поддерживается только при установке shared_memory_type в значение mmap (по умолчанию).

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

Огромные страницы на Windows называются большими страницами. Чтобы использовать их, необходимо назначить право пользователя Lock pages in memory учетной записи пользователя Windows, от имени которого запускается Tantor SE. Вы можете использовать инструмент групповой политики Windows (gpedit.msc), чтобы назначить право пользователя Lock pages in memory. Чтобы запустить сервер базы данных в командной строке в качестве автономного процесса, а не в качестве службы Windows, командная строка должна быть запущена от имени администратора или отключено Управление доступом пользователя (UAC). Когда UAC включено, обычная командная строка отзывает право пользователя Lock pages in memory при запуске.

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

enable_temp_memory_catalog (boolean) #

Включает хранение временных записей каталога в локальной памяти бэкенда для уменьшения разрастания каталога. По умолчанию установлено значение false.

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

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 МБ или более.

enable_delayed_temp_file (boolean) #

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

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 (см. Таблица 65.1). Если это значение указано без единиц измерения, оно принимается как блоки, то есть BLCKSZ байт, обычно 8kB. Значение по умолчанию — 0, что запрашивает shared_buffers/512 до 1024 блоков, но не менее 16 блоков. Этот параметр можно установить только при запуске сервера.

multixact_member_buffers (integer) #

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

multixact_offset_buffers (integer) #

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

notify_buffers (integer) #

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

serializable_buffers (integer) #

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

subtransaction_buffers (integer) #

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

transaction_buffers (integer) #

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

max_stack_depth (integer) #

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

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

shared_memory_type (enum) #

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

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 (отсутствует). Этот параметр может быть установлен только при запуске сервера.

19.4.2. Временный каталог в памяти #

Параметр enable_temp_memory_catalog включает внутрипроцессный, хранящийся в памяти системный каталог, в котором метаданные и данные обычных временных таблиц хранятся вне дисковых каталогов. Цель этого механизма:

  • Устранить разрастание системных каталогов из-за частого создания или удаления временных таблиц.

  • Сократить объем WAL и нагрузку на autovacuum при работе с временными данными.

  • Повысить производительность запросов, активно использующих временные отношения.

Внутренне патч добавляет небольшой движок хранения в памяти, который интегрируется в обычные пути доступа к таблицам и индексам:

  • Операции над кучей (heap_insert, heap_delete, heap_update, …) перехватываются и направляются в хранилище кортежей в памяти.

  • Индексы реализованы через красно-черные деревья и обеспечивают семантику, аналогичную BTREE, как для UNIQUE так и для обычных индексов.

  • Упрощенный уровень MVCC хранит версии кортежей, обеспечивая согласованное состояние до фиксации транзакции.

  • Обратные вызовы XACT или SUBXACT отслеживают фиксации и откаты транзакций, распространяя их на кортежи в памяти.

  • Метаданные, которые обычно записываются в pg_class, pg_type, pg_attribute и другие, теперь хранятся в том же блоке памяти, без создания физических записей в каталогах.

Примечание

Потребление памяти: движок выделяет блоки по 64 МБ (ALLOC_SIZE_64MB) из TopMemoryContext текущего процесса. Все данные освобождаются автоматически при завершении процесса.

19.4.2.1. Конфигурация #

GUC Тип Контекст По умолчанию Описание
enable_temp_memory_catalog bool USERSET off Перенаправляет каталоги временных таблиц в память, снижая нагрузку на системные каталоги

Параметр можно задать в postgresql.conf, на уровне сессии или для одного запроса:

-- system‑wide
enable_temp_memory_catalog = on

-- per session
SET enable_temp_memory_catalog TO on;

Изменения вступают в силу сразу, перезапуск не требуется. Но если вы выключили enable_temp_memory_catalog, то рекомендуется переподключиться к базе данных.

19.4.2.2. Как это работает #

  1. Подсказка о типе отношения – планировщик/исполнитель устанавливают CurrentRelpersistenceHint, чтобы указать, что отношение временное.

  2. Поиск отношения – п relpersistence = 't' и включенном GUC срабатывает IsInmemHandledRelationId(), перенаправляющий операцию в память.

  3. Версионирование кортежей – каждая операция INSERT/UPDATE/DELETE создает новый элемент с признаками видимости транзакции, как в куче.

  4. Индексация – ключи хранятся в RBTree, сопоставляющем ключи со списками указателей на кортежи. Поиск использует ту же amproc‑логику, что и обычные B‑tree.

  5. Фиксация / откат – при END‑TRANSACTION обратные вызовы помечают версии как зафиксированные или удаляют откатанные. При завершении процесса память освобождается полностью.

19.4.2.3. Ограничения #

  • Работает только с временным таблицам (CREATE TEMP TABLE …). На unlogged, глобальные или постоянные таблицы не влияет.

  • Данные живут только в течение жизни backend‑процесса. При аварии или DISCONNECT все теряется, как и у обычных временных таблиц.

  • Предел памяти определяется доступной ОЗУ. Слишком большие объемы могут вызвать ERROR: out of memory.

  • Каталоги в памяти игнорируются при физической репликации и логическом декодировании.

19.4.2.4. Примеры #

-- Enable the feature just for this session
SET enable_temp_memory_catalog = on;

CREATE TEMP TABLE t(id int primary key, val text);

Обратите внимание:

  • В pg_class, pg_attribute и прочие каталоги строки не добавляются.

  • Задержка запросов сравнима с UNLOGGED‑таблицами, но без побочных эффектов в каталогах.

  • После завершения сессии память освобождается автоматически.

19.4.2.5. Совместимость и откат #

Патч не изменяет формат хранения на диске и полностью бинарно совместим с существующими кластерами. Для отката достаточно установить enable_temp_memory_catalog = off.

19.4.3. Диск #

temp_file_limit (integer) #

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

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

max_notify_queue_pages (integer) #

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

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

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

max_files_per_process (integer) #

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

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

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

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

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

vacuum_cost_page_dirty (integer) #

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

vacuum_cost_limit (integer) #

Это накопленная стоимость, которая заставит процесс очистки приостановиться на vacuum_cost_delay. По умолчанию 200.

Примечание

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

19.4.6. Фоновый записывающий процесс #

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

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

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

backend_flush_after (integer) #

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

effective_io_concurrency (integer) #

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

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

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

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

maintenance_io_concurrency (integer) #

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

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

io_combine_limit (integer) #

Управляет максимальным размером ввода-вывода в операциях, которые объединяют ввод-вывод. По умолчанию 128kB.

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