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

18.4.1 Память

shared_buffers (integer)

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

Если у Вас выделенный сервер БД с более чем 1GB ОЗУ, хорошим начальным значением будет 25% доступной памяти. Бывают случаи, когда для эффективной работы требуется даже больше памяти, но, поскольку PostgreSQL так же полагается на кэш ОС, скорее всего выделение более 40% ОЗУ для shared_buffers не даст прироста производительности. Большие значения shared_buffers требуют соответствующего увеличения checkpoint_segments, для того, чтобы растянуть во времени запись большого количества новых или изменённых данных.

На системах с менее чем 1GB ОЗУ подходят меньшие значения, чтобы было достаточно места для Ос. Кроме того, на Windows большие значения shared_buffers не будут эффективными. Более полезным может оказаться сохранение этой настройки небольшой, но зато увеличив используемый ОС кэш. На Windows полезными значениями могут оказаться значения от 64MB до 512MB.

Увеличение этого значения может привести к тому, что PostgreSQL потребует больше разделяемой памяти System V, чем позволяет конфигурация вашей системы. Более подробно об этом сказано в разделе 17.4.1

temp_buffers (integer)

Задаёт максимальное количество временных буферов, используемых для каждой сессии БД. Эти "сессионные" настройки используются только для доступа к временным таблицам. Значение по умолчанию - 8MB. Это значение может быть изменено в каждой сессии, но только до перед первым использованием временной таблицы в пределах сессии; последующие попытки изменить это значение не повлияют на текущую сессию.

Сессия выделяет временные буферы по мере их потребления до достижения лимита, заданного temp_buffers. Стоимость увеличения этого лимита временных буферов для сессии, которой не требуется много буферов, заключается лишь дескрипторе буфера, или где-то 64 байта на одно увеличение (видимо, на один буфер - примечание переводчика). Но, если буфер используется, то требуется ещё 8192 байта (или, в общем, BLCKSZ байт).

max_prepared_transactions (integer)

Задаёт максимальное число транзакций, которые могут одновременно находиться в состоянии "подготовленные" (см PREPARE TRANSACTION). Значение 0 (по умолчанию) отключает возможности создания подготовленных транзакций. Этот параметр можно установить только при запуске сервера.

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

Увеличение этого параметра может привести к росту потребностей PostgreSQL в разделяемой памяти System V. Для увеличения лимитов вашей системы обращайтесь к разделу 17.4.1

На резервном сервере этот параметр должен быть не меньше, чем на мастере. Иначе запросы к нему не будут обрабатываться.

(Из postgresql.conf:

# Внимание: Увеличение max_prepared_transactions стоит ~600 bytes разделяемой памяти
# на слот транзакции + пространство блокировки (см max_locks_per_transaction).

)

work_mem (integer)

Определяет количество памяти, используемое для внутренних операций сортировки и хеш-таблиц перед их записью во временные файлы. По умолчанию - 1Mb. Имейте ввиду, что для в сложных запросах несколько операций сортировки или хеширования могут быть запущены параллельно; каждая из этих операций сможет использовать указанный тут объём памяти перед записью данных во временные файлы. Запущенные сессии так же могут выполнять эти операции одновременно. Поэтому общее количество используемой памяти может быть в несколько раз больше, чем work_mem; необходимо помнить об этом, устанавливая это значение. Операции сортировки используются командами ORDER BY, DISTINCT и при объединении слиянием. Хэш таблицы используются в hash join, hash-based aggregation и hash-based обработкой IN подзапросов.

maintenance_work_mem (integer)

Определяет максимальное количество памяти, используемое для операций обслуживания, такие как VACUUM, CREATE INDEX и ALTER TABLE ADD FOREIGN KEY. По умолчанию - 16MB. Так как только одна такая операция может выполняться в одно время в сессии БД и редко параллельно будет выполняться несколько таких операций, можно поставить этому параметру достаточно большое значение, больше чем work_mem. Большие значения могут увеличить производительность операций vacuum и восстановления дампов БД.

Обратите внимание, что когда запускается autovacuum, то может потребоваться до autovacuum_max_worker раз такого количества памяти, так что не задавайте это значение слишком большим.

max_stack_depth (integer)

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

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

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

max_files_per_process (integer)

Задаёт максимальное число одновременно отрытых файлов для каждого серверного процесса. Значение по умолчанию - 1000. Если ядро принудительно само устанавливает такой лимит, то Вам вообще не надо об этом беспокоиться. Но на некоторых платформах (особенно на большинстве BSD систем) ядро позволит отдельному процессу открыть больше файлов, чем поддерживает сама система, если несколько процессов попытаются открыть такое количество файлов. Если Вы столкнулись с ошибкой "Too many open files", попробуйте уменьшить значение этого параметра. Его можно задать только при старте сервера.

shared_preload_libraries (string)

Эта строка определяет библиотеки, которые должны быть загружены при старте сервера. Например, значение '$libdir/mylib' приведёт к тому, что mylib.so (или, на некоторых платформах, mylib.sl) будет загружен из стандартного каталога установки. Все имена библиотек переводятся в нижний регистр, если они не заключены в двойные кавычки. Если требуется загрузить несколько библиотек, разделите их имена запятыми. Этот параметр может быть задан только при запуске сервера.

Таким образом могут быть загружены библиотеки процедурного языка PostgreSQL, обычно это что-то вроде '$libdir/plXXX', где XXX - зпыйдб perl, tcl или python.

Предварительная загрузка библиотеки позволяет избежать затрат времени на загрузку библиотеки, когда она понадобится. С другой стороны, время запуска каждого нового серверного процесса может незначительно увеличиться, даже если этот процесс и не будет использовать эту библиотеку. Так что этот параметр рекомендуется для библиотек, которые используются в большинстве случаев.

Примечание: на Windows предварительная загрузка библиотек не сокращает время на запукс каждого нового процесса; каждый процесс будет заново загружать все библиотеки. Всё же shared_preload_libraries полезна и на Windows, так как некоторым библиотекам может требоваться выполнить какие-то действия при запуске сервера (например, библиотеке может потребоваться зарезервировать лёгкие блокировки или разделяемую память, что нельзя сделать после старта сервера).

Если указанную библиотеку не удаётся найти, сервер не запускается.

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

18.4.3 Задержка vacuum на основе подсчёта нагрузки

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

Цель этот - позволить администратору сократить влияние этих команд на текущую работу с БД. Есть много случаев, когда нет необходимости в скорейшем завершении команд типа VACUUM и ANALYZE; однако обычно крайне важно, чтобы они по минимуму влияли на производительность БД.  Задержка vacuum на основе подсчёта нагрузки позволяет администратору добиться этого.

По умолчанию эта возможность отключена для команд VACUUM, запускаемых вручную. Для того, чтобы включить эту возможность, задайте vacuum_cost_delay ненулевое значение.

vacuum_cost_delay (integer)

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

Эффективным чаще всего являются небольшие значения, порядка 10-20 миллисекунд. Сглаживание потребления ресурсов лучше регулируется другими параметрами.

vacuum_cost_page_hit (integer)

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

vacuum_cost_page_miss (integer)

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

vacuum_cost_page_dirty (integer)

Ориентировочная стоимость изменения vacuum'ом блока, который уже был очищен. Представляет из себя дополнительные затраты ввода / вывода, необходимые для сброса чистого блока на диск. Значение по умолчанию - 20.

vacuum_cost_limit (integer)

Суммарная стоимость при достижении которой процесс очистки засыпает. Значение по умолчанию - 200.

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

18.4.4 Background writer

Есть отдельный серверный процесс, называемый background writer, чьей функцией является запись "грязных" (новых или изменённых) общих буферов. Он записывает общие буферы так, что серверным процессам, обрабатывающим запросы пользователей редко, или даже никогда не приходится ожидать этой записи. Однако background writer увеличивает общую нагрузку ввода / вывода, так как, хотя страница, становящаяся "грязной" несколько раз подряд, была бы иначе записана только один раз за интервал чекпойнта, background writer может записать её за этот интервал несколько раз (каждый раз, как она становится "грязной"). Параметры, описанные в этом разделе, могут быть использованы для настройки его поведения.

bgwriter_delay (integer)

Определяет паузу между циклами активности background writer. В каждом цикле writer обслуживает некоторое количество "грязных" буферов (определяемое в других параметрах). После этого он засыпает на bgwriter_delaymilliseconds и всё начинается заново. Установка в качестве значения числа, которое не делится на 10 может иметь тот же эффект, что и ближайшее большее число, кратное 10. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.

bgwriter_lru_maxpages (integer)

В каждом цикле не больше, чем это количество буферов может быть записано background writer'oм. Если установить в качестве значения 0, то background writer не будет записывать буферы, кроме как во веремя чекпойнтов. Значение по умолчанию - 100 буферов. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.

bgwriter_lru_multipler (floating point)

Число "грязных" буферов, которые записываются в каждом цикле основывается на числе новых буферов, которые потребовались серверному процессу в последних циклах. Среднее количество недавно требовавшихся буферов умножается на bgwriter_lru_multiplier, в результате чего получается число буферов, которые потребуются в следующем цикле. "Грязные" буферы записываются до тех пор, пока число чистых, повторно используемых буферов не достигает нужного количества. (Но, в любом случае, будет записано не больше чем bgwriter_lru_maxpages буферов за цикл.) Таким образом, значение 1.0 означает подход "just in time", когда будет записано ровно столько буферов, сколько предположительно потребуется. Большие значения обеспечивают некий запас прочности на случай всплесков, тогда как меньшие означают, что мы намеренно оставляем запись на совесть серверных процессов. Значение по умолчанию - 2.0. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.

Небольшие значения bgwriter_lru_maxpages и bgwriter_lru_multiplier сокращают дополнительную нагрузку от background writer, но приводят к тому, что скорее всего запись придётся производить серверным процессам, откладывая выполнение пользовательских запросов.

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

effective_io_concurrency (integer)

Задаёт число операций ввода / вывода, которые, как PostgreSQL ожидает, будут выполняться одновременно. Увеличение этого значения увеличивает число операций ввода/вывода, которые одна сессия PostgreSQL будет пытаться провести параллельно. Допустимые значения - от 1 до 1000, или 0 для того, чтобы отключить асинхронные запросы ввода/вывода. На данный момент эта настройка влияет только на bitmap heap scans.

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

Для более экзотических систем, таких как хранилища в ОЗУ или RAID массивы с ограничением по шине, правильным значением может быть число доступных путей ввода/вывода. Для поиска лучшего значения может потребоваться провести несколько тестов.

Асинхронный ввод/вывод зависит от эффективного функционирования posix_fadvise, а в этом деле не все йогурты одинаково полезны. Если эта функция отсутствует в системе, то установка значения, отличного от 0 приведёт к ошибке. На некоторых ОС (например, Solaris), функция присутствует, но ничего не делает.