Существует несколько параметров конфигурации, связанных с журналом предварительной записи (WAL), которые влияют на производительность базы данных. В этом разделе объясняется их использование. Обратитесь к Глава 3.4 за общей информацией об установке параметров конфигурации сервера.

Контрольные точки — это точки в последовательности транзакций, в которых гарантируется, что файлы данных кучи (heap) и индексов были обновлены всей информацией, записанной до этой контрольной точки. Во время контрольной точки все «грязные» страницы данных сбрасываются на диск, и в файл журнала предварительной записи записывается специальная запись о контрольной точке. (Записи об изменениях ранее были сброшены в файлы WAL.) В случае сбоя процедура восстановления после сбоя просматривает последнюю запись о контрольной точке, чтобы определить точку в журнале (известную как redo-запись), с которой следует начать операцию повтора (REDO). Любые изменения, внесенные в файлы данных до этой точки, гарантированно уже находятся на диске. Следовательно, после контрольной точки сегменты журнала предварительной записи, предшествующие тому, который содержит redo-запись, больше не нужны и могут быть утилизированы или удалены. (Когда выполняется архивирование WAL, сегменты журнала должны быть заархивированы перед утилизацией или удалением.)

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

Процесс формирования контрольных точек (checkpointer) сервера автоматически выполняет контрольную точку через определенные промежутки времени. Контрольная точка начинается каждые checkpoint_timeout секунд или если max_wal_size вот-вот будет превышен, в зависимости от того, что наступит раньше. Настройки по умолчанию составляют 5 минут и 1 ГБ соответственно. Если с момента предыдущей контрольной точки в журнал предварительной записи не было внесено никаких записей, новые контрольные точки будут пропущены, даже если прошло время checkpoint_timeout. (Если используется архивирование журнала предварительной записи и вы хотите установить нижний предел того, как часто архивируются файлы, чтобы ограничить потенциальную потерю данных, вам следует настроить параметр archive_timeout, а не параметры контрольной точки.) Также можно принудительно выполнить контрольную точку с помощью SQL-команды CHECKPOINT.

Уменьшение checkpoint_timeout и/или max_wal_size приводит к более частому возникновению контрольных точек. Это позволяет ускорить восстановление после сбоя, так как потребуется меньше работы по повторному выполнению операций. Однако это необходимо сбалансировать с увеличенными затратами на более частое сбрасывание «грязных» страниц данных. Если установлен параметр full_page_writes (как это сделано по умолчанию), следует учитывать еще один фактор. Чтобы обеспечить согласованность страниц данных, первая модификация страницы данных после каждой контрольной точки приводит к записи всего содержимого страницы в журнал. В этом случае меньший интервал контрольных точек увеличивает объем вывода в журнал предварительной записи, частично сводя на нет цель использования меньшего интервала и в любом случае вызывая больше дискового ввода-вывода.

Контрольные точки обходятся довольно дорого, во-первых, потому что они требуют вытеснения всех текущих «грязных» буферов, и во-вторых, потому что они приводят к дополнительному последующему трафику журнала предварительной записи, как обсуждалось выше. Поэтому разумно установить параметры формирования контрольных точек достаточно высокими, чтобы они не происходили слишком часто. В качестве простой проверки адекватности ваших параметров контрольных точек вы можете установить параметр checkpoint_warning. Если контрольные точки происходят чаще, чем через checkpoint_warning секунд, в лог сервера будет выведено сообщение с рекомендацией увеличить max_wal_size. Эпизодическое появление такого сообщения не является поводом для тревоги, но если оно появляется часто, параметры управления контрольными точками следует увеличить. Массовые операции, такие как крупные пересылки COPY, могут привести к появлению ряда таких предупреждений, если вы не установили max_wal_size достаточно высоким.

Чтобы избежать перегрузки системы ввода-вывода всплеском записей страниц, запись «грязных» буферов во время контрольной точки растягивается во времени. Этот период контролируется параметром checkpoint_completion_target, который задается как доля интервала контрольных точек (настраиваемого с помощью checkpoint_timeout). Скорость ввода-вывода регулируется таким образом, чтобы контрольная точка завершалась, когда истекает заданная доля от checkpoint_timeout секунд или до того, как будет превышен max_wal_size, в зависимости от того, что произойдет раньше. При значении по умолчанию 0.9 можно ожидать, что Digital Q.DataBase будет завершать каждую контрольную точку немного раньше следующей запланированной контрольной точки (примерно на 90% длительности последней контрольной точки). Это максимально распределяет ввод-вывод, так что нагрузка на ввод-вывод от контрольной точки остается равномерной на протяжении всего интервала контрольных точек. Недостатком этого является то, что затягивание контрольных точек влияет на время восстановления, так как большему количеству сегментов журнала предварительной записи потребуется оставаться в наличии для возможного использования при восстановлении. Пользователь, обеспокоенный временем, необходимым для восстановления, может захотеть уменьшить checkpoint_timeout, чтобы контрольные точки происходили чаще, но при этом ввод-вывод все равно распределялся по интервалу контрольных точек. В качестве альтернативы можно было бы уменьшить checkpoint_completion_target, но это привело бы к периодам более интенсивного ввода-вывода (во время контрольной точки) и периодам меньшего ввода-вывода (после завершения контрольной точки, но до следующей запланированной), и поэтому не рекомендуется. Хотя checkpoint_completion_target может быть установлен до 1.0, обычно рекомендуется устанавливать его не выше 0.9 (по умолчанию), поскольку контрольные точки включают некоторые другие действия, помимо записи «грязных» буферов. Установка значения 1.0 с большой вероятностью приведет к тому, что контрольные точки не будут завершаться вовремя, что приведет к потере производительности из-за непредвиденного изменения количества необходимых сегментов журнала предварительной записи.

На платформах Linux и POSIX параметр checkpoint_flush_after позволяет принудительно сбрасывать на диск страницы ОС, записанные контрольной точкой, после достижения настраиваемого количества байт. В противном случае эти страницы могут удерживаться в кэше страниц ОС, вызывая задержку при выполнении fsync в конце контрольной точки. Эта настройка часто помогает уменьшить задержку транзакций, но она также может оказать неблагоприятное влияние на производительность, особенно при рабочих нагрузках, объем которых больше shared_buffers, но меньше кэша страниц ОС.

Количество файлов сегментов журнала предварительной записи в каталоге pg_wal зависит от min_wal_size, max_wal_size и количества журнала, сгенерированного в предыдущих циклах контрольных точек. Когда старые файлы сегментов журнала предварительной записи больше не нужны, они удаляются или утилизируются (то есть переименовываются, чтобы стать будущими сегментами в пронумерованной последовательности). Если из-за кратковременного пика скорости вывода в журнал предварительной записи будет превышен max_wal_size, ненужные файлы сегментов будут удаляться до тех пор, пока система не вернется в рамки этого лимита. Ниже этого лимита система утилизирует достаточное количество файлов журнала предварительной записи, чтобы покрыть расчетную потребность до следующей контрольной точки, и удаляет остальные. Оценка основана на скользящем среднем количестве файлов журнала предварительной записи, использованных в предыдущих циклах контрольных точек. Скользящее среднее немедленно увеличивается, если фактическое использование превышает оценку, поэтому оно в некоторой степени подстраивается под пиковое использование, а не под среднее. min_wal_size устанавливает минимум для количества файлов журнала предварительной записи, утилизируемых для будущего использования; такой объем журнала всегда утилизируется для будущего использования, даже если система простаивает и оценка использования журнала говорит о том, что его нужно немного.

Независимо от max_wal_size, всегда сохраняются последние wal_keep_size мегабайт файлов журнала предварительной записи плюс один дополнительный файл журнала. Также, если используется архивирование журнала предварительной записи, старые сегменты не могут быть удалены или утилизированы, пока они не будут заархивированы. Если архивирование журнала предварительной записи не успевает за темпами его генерации или если archive_command или archive_library постоянно дают сбои, старые файлы журнала предварительной записи будут накапливаться в pg_wal до разрешения ситуации. Медленный или вышедший из строя резервный сервер (standby), который использует слот репликации, вызовет тот же эффект (см. Раздел 3.11.2.6). Аналогично, если включено суммирование WAL, старые сегменты сохраняются до тех пор, пока они не будут суммированы.

В режиме восстановления из архива или в режиме ожидания (standby) сервер периодически выполняет точки рестарта (restartpoints), которые аналогичны контрольным точкам при обычной работе: сервер принудительно сбрасывает все свое состояние на диск, обновляет файл pg_control, чтобы указать, что уже обработанные данные журнала предварительной записи не нужно сканировать снова, а затем утилизирует все старые файлы сегментов журнала в каталоге pg_wal. Точки рестарта не могут выполняться чаще, чем контрольные точки на основном сервере, потому что они могут выполняться только на записях контрольных точек. Точка рестарта может потребоваться по расписанию или по внешнему запросу. Счетчик restartpoints_timed в представлении pg_stat_checkpointer учитывает первые, а restartpoints_req — вторые. Точка рестарта инициируется по расписанию при достижении записи контрольной точки, если с момента последней выполненной точки рестарта прошло не менее checkpoint_timeout секунд или когда предыдущая попытка выполнить точку рестарта потерпела неудачу. В последнем случае следующая точка рестарта будет запланирована через 15 секунд. Точка рестарта инициируется по запросу по причинам, аналогичным причинам контрольной точки, но в основном если размер журнала предварительной записи вот-вот превысит max_wal_size. Однако из-за ограничений на то, когда может быть выполнена точка рестарта, max_wal_size часто превышается во время восстановления, вплоть до объема журнала за один цикл контрольных точек. (В любом случае max_wal_size никогда не является жестким лимитом, поэтому вы всегда должны оставлять достаточный запас, чтобы избежать нехватки места на диске.) Счетчик restartpoints_done в представлении pg_stat_checkpointer учитывает точки рестарта, которые были действительно выполнены.

В некоторых случаях, когда размер журнала предварительной записи на основном сервере быстро растет, например, во время массовой вставки (INSERT), счетчик restartpoints_req на резервном сервере может демонстрировать пиковый рост. Это происходит потому, что запросы на создание новой точки рестарта из-за повышенного потребления XLOG не могут быть выполнены, так как безопасная запись контрольной точки с момента последней точки рестарта еще не была проиграна на резервном сервере. Такое поведение является нормальным и не приводит к росту потребления системных ресурсов. Только счетчик restartpoints_done среди связанных с точками рестарта указывает на то, что были затрачены заметные системные ресурсы.

Существует две часто используемые внутренние функции журнала предварительной записи (WAL): XLogInsertRecord и XLogFlush. XLogInsertRecord используется для размещения новой записи в буферы журнала предварительной записи в общей памяти. Если места для новой записи нет, XLogInsertRecord придется записать (переместить в кэш ядра) несколько заполненных буферов WAL. Это нежелательно, потому что XLogInsertRecord используется при каждой модификации низкого уровня базы данных (например, вставке строки) в тот момент, когда удерживается исключительная блокировка на затронутых страницах данных, поэтому операция должна быть максимально быстрой. Что еще хуже, запись буферов WAL может также форсировать создание нового сегмента журнала, что занимает еще больше времени. Обычно буферы WAL должны записываться и сбрасываться по запросу XLogFlush, который делается, по большей части, во время фиксации транзакции, чтобы гарантировать, что записи транзакции сброшены в постоянное хранилище. На системах с высоким выводом журнала предварительной записи запросы XLogFlush могут происходить недостаточно часто, чтобы предотвратить выполнение записи функцией XLogInsertRecord. На таких системах следует увеличить количество буферов WAL, изменив параметр wal_buffers. Когда установлен параметр full_page_writes и система сильно загружена, установка более высокого значения wal_buffers поможет сгладить время отклика в период, непосредственно следующий за каждой контрольной точкой.

Параметр commit_delay определяет, на сколько микросекунд процесс-лидер групповой фиксации будет засыпать после получения блокировки внутри XLogFlush, пока последователи групповой фиксации выстраиваются в очередь за лидером. Эта задержка позволяет другим серверным процессам добавить свои записи о фиксации в буферы журнала предварительной записи, чтобы все они были сброшены итоговой операцией синхронизации лидера. Засыпание не произойдет, если fsync не включен или если в данный момент в активных транзакциях находится менее commit_siblings других сессий; это позволяет избежать засыпания, когда маловероятно, что какая-либо другая сессия скоро зафиксируется. Обратите внимание, что на некоторых платформах дискретность запроса на засыпание составляет десять миллисекунд, поэтому любая ненулевая настройка commit_delay в диапазоне от 1 до 10000 микросекунд будет иметь тот же эффект. Также обратите внимание, что на некоторых платформах операции засыпания могут занимать немного больше времени, чем запрашивается параметром.

Поскольку целью commit_delay является распределение стоимости каждой операции сброса между одновременно фиксирующимися транзакциями (возможно, за счет задержки транзакции), необходимо оценить эту стоимость, прежде чем можно будет разумно выбрать настройку. Чем выше эта стоимость, тем более эффективным ожидается commit_delay в увеличении пропускной способности транзакций, до определенного предела. Программа pg_test_fsync может быть использована для измерения среднего времени в микросекундах, которое занимает одна операция сброса журнала предварительной записи. Значение, равное половине среднего времени, которое программа сообщает для сброса после одной операции записи объемом 8 КБ, часто является наиболее эффективной настройкой для commit_delay, поэтому это значение рекомендуется в качестве отправной точки при оптимизации для конкретной рабочей нагрузки. В то время как настройка commit_delay особенно полезна, когда журнал предварительной записи хранится на вращающихся дисках с высокой задержкой, преимущества могут быть значительными даже на носителях с очень быстрым временем синхронизации, таких как твердотельные накопители или RAID-массивы с кэшем записи с резервным питанием от батареи; но это обязательно должно быть проверено на представительной рабочей нагрузке. В таких случаях следует использовать более высокие значения commit_siblings, тогда как меньшие значения commit_siblings часто полезны на носителях с более высокой задержкой. Обратите внимание, вполне возможно, что слишком высокая настройка commit_delay может настолько увеличить задержку транзакции, что пострадает общая пропускная способность транзакций.

Когда commit_delay установлен в ноль (по умолчанию), все еще возможно возникновение формы групповой фиксации, но каждая группа будет состоять только из сессий, которые достигают точки, где им необходимо сбросить свои записи о фиксации в окне, в котором происходит предыдущая операция сброса (если таковая имеется). При большом количестве клиентов наблюдается «эффект сходни» (gangway effect), так что эффекты групповой фиксации становятся значительными, даже когда commit_delay равен нулю, и, следовательно, явная установка commit_delay, как правило, помогает меньше. Установка commit_delay может помочь только когда (1) есть несколько одновременно фиксирующихся транзакций и (2) пропускная способность ограничена в некоторой степени скоростью фиксации; но при высокой задержке вращения диска эта настройка может быть эффективна в увеличении пропускной способности транзакций даже при двух клиентах (то есть один фиксирующийся клиент с одной родственной транзакцией).

Параметр wal_sync_method определяет, как Digital Q.DataBase будет запрашивать у ядра принудительный вывод обновлений журнала предварительной записи (WAL) на диск. Все варианты должны быть одинаковыми с точки зрения надежности, за исключением fsync_writethrough, который иногда может форсировать сброс дискового кэша, даже когда другие варианты этого не делают. Однако, какой из них будет самым быстрым, сильно зависит от платформы. Вы можете проверить скорость различных вариантов с помощью программы pg_test_fsync. Обратите внимание, что этот параметр не имеет значения, если fsync был выключен.

Включение параметра конфигурации wal_debug (при условии, что Digital Q.DataBase был скомпилирован с поддержкой этой функции) приведет к тому, что каждый вызов функций XLogInsertRecord и XLogFlush будет записываться в лог сервера. Эта опция может быть заменена более общим механизмом в будущем.

Существует две внутренние функции для записи данных журнала предварительной записи на диск: XLogWrite и issue_xlog_fsync. Когда включен параметр track_wal_io_timing, общее время, которое XLogWrite тратит на запись, и issue_xlog_fsync тратит на синхронизацию данных журнала на диск, учитывается как wal_write_time и wal_sync_time в pg_stat_wal соответственно. XLogWrite обычно вызывается функцией XLogInsertRecord (когда в буферах журнала предварительной записи нет места для новой записи), XLogFlush и процессом записи журнала, чтобы записать буферы журнала на диск и вызвать issue_xlog_fsync. Функция issue_xlog_fsync обычно вызывается функцией XLogWrite для синхронизации файлов журнала на диске. Если wal_sync_method имеет значение либо open_datasync, либо open_sync, операция записи в XLogWrite гарантирует синхронизацию записанных данных на диск, и issue_xlog_fsync ничего не делает. Если wal_sync_method имеет значение либо fdatasync, fsync, либо fsync_writethrough, операция записи перемещает буферы журнала в кэш ядра, а issue_xlog_fsync синхронизирует их на диске. Независимо от настройки track_wal_io_timing, количество раз, когда XLogWrite записывает и issue_xlog_fsync синхронизирует данные журнала на диск, также учитывается как wal_write и wal_sync в pg_stat_wal соответственно.

Параметр recovery_prefetch может использоваться для уменьшения времени ожидания ввода-вывода во время восстановления, инструктируя ядро инициировать чтение дисковых блоков, которые скоро потребуются, но в данный момент отсутствуют в буферном пуле Digital Q.DataBase. Настройки maintenance_io_concurrency и wal_decode_buffer_size ограничивают параллелизм и дистанцию упреждающего чтения соответственно. По умолчанию установлено значение try, что включает эту функцию на системах, где доступна функция posix_fadvise.