9 Буферный кеш

9.1. Ввод-вывод и кеширование

Общие соображения

Операции ввода-вывода можно разделить на прямые и буферизованные.

Прямой ввод-вывод (Direct I/O) перемещает данные непосредственно между памятью пользовательского процесса и диском. Если при этом поддерживается прямой доступ к памяти (DMA), то такая операция даже не нагружает процессор.

Буферизованный ввод-вывод задействует операционную систему и ее кеш. Пользовательский процесс запрашивает данные с помощью системного вызова. Если нужные данные есть в кеше, операционная система возвращает результат немедленно; в противном случае она предварительно читает данные с диска. Так или иначе, данные сначала (возможно, заранее) помещаются в кеш в памяти ядра операционной системы, а затем копируются в память пользовательского процесса: в нашем случае — в буферный кеш PostgreSQL.

Операции ввода-вывода можно классифицировать и иначе.

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

При асинхронном вводе-выводе (Async I/O) процесс формирует и отправляет задание и продолжает работу. За результатом он возвращается позже, в удобный для себя момент. Если операция уже выполнилась, процесс получает результат сразу; если нет — блокируется до ее завершения, как при синхронном вводе-выводе.

Довольно очевидно, что прямой ввод-вывод может обеспечить более высокую пропускную способность и меньшую задержку получения данных, а асинхронный ввод-вывод позволяет меньше простаивать и выполнять больше полезной работы. Но с точки зрения программирования обычный синхронный буферизованный ввод-вывод гораздо проще, а проигрывает совсем не так сильно, как можно было бы подумать. PostgreSQL тридцать лет использовал именно синхронный буферизованный ввод-вывод. Дело в том, что хотя код СУБД при этом работает последовательно, ввод-вывод фактически выполняется асинхронно: операционная система во многих случаях предугадывает последовательность чтений и заранее, в фоновом для СУБД режиме, считывает нужные данные в свой кеш. На операционную систему перекладываются все заботы о предвыборке данных и об отложенной записи грязных страниц.

Мотивацией для собственной реализации асинхронного ввода-вывода является уменьшение зависимости от операционной системы: не все системы выполняют предвыборку одинаково хорошо, а СУБД в любом случае лучше знает, какие страницы ей понадобятся и когда. Кроме того, привлекает возможность асинхронно выполнять синхронизацию данных с диском (fsync).

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

Текущее положение дел

Работа над тем, чтобы отвязать PostgreSQL от файловой системы, началась уже несколько лет назад. (v. 18)

Прямой ввод-вывод включается параметром debug_io_direct, но пока не реализовано все необходимое, эта настройка имеет смысл только для разработчиков ядра. (по умолчанию: off) (v. 16)

Асинхронный ввод-вывод ¹ доступен пока только для чтения; запись и синхронизация по-прежнему остаются синхронными. Имеются несколько реализаций ввода-вывода, одна из которых указывается в параметре io_method: можно выбрать тот способ, который поддерживается на конкретной платформе и показывает лучшие результаты в конкретной системе. (по умолчанию: worker)

• При значении worker ввод-вывод выполняется отдельными рабочими процессами². Этот способ работает на любых платформах и выбирается по умолчанию.

Чтобы прочитать страницу или несколько подряд идущих страниц, процесс (обслуживающий или системный) помещает свой запрос в очередь, общую для всех рабочих процессов. В какой-то момент один из них выполнит запрошенную операцию, например прочитает требуемые страницы в буферный кеш.

Количество рабочих процессов постоянно и определяется параметром io_workers. На серверах с большим количеством ядер значение параметра имеет смысл увеличить (максимальное значение — 32). (по умолчанию: 3)

=> SELECT pid, backend_type
FROM pg_stat_activity
WHERE backend_type = 'io worker';
  pid  | backend_type
-------+--------------
 55418 | io worker
 55419 | io worker
 55420 | io worker
(3 rows)

• При значении io_uring ввод-вывод выполняется самим процессом с помощью одноименного интерфейса ядра Linux и работает только в этой операционной системе³.

Интерфейс io_uring использует два кольцевых буфера в памяти пользовательского процесса (отсюда и название — user-space ring): один для запросов на ввод-вывод, другой — для получения результата этих запросов. Поскольку буферы находятся в памяти процесса, взаимодействие с интерфейсом происходит без системных вызовов и не приводит к переключению контекста.

• При значении sync используется обычный синхронный ввод-вывод.

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

Асинхронный ввод-вывод настраивается, по сути, парой значений: количеством асинхронных операций ввода-вывода, которые могут выполняться одновременно, и количеством идущих подряд страниц, которые будут читаться одной операцией. Однако параметров несколько больше.

Параметром io_max_concurrency мы задаем максимальное количество асинхронных операций в расчете на один процесс. Размер структур данных, которые создаются для асинхронного ввода-вывода в разделяемой памяти при запуске экземпляра, зависит от произведения этого значения на максимальное число процессов в системе (включая служебные). При значении по умолчанию количество выбирается автоматически исходя из размеров буферного кеша, но не превышает 64⁴. (по умолчанию: -1)

Само по себе значение io_max_concurrency не ограничивает количество операций одного процесса. Такое ограничение устанавливают два других параметра: effective_io_concurrency для обычного чтения данных из таблиц и maintenance_io_concurrency для таких служебных задач, как, например, очистка. Установка этих параметров в ноль фактически отключает асинхронный ввод-вывод. Поскольку степень параллелизма зависит от возможностей устройства ввода-вывода, эти параметры можно устанавливать и на уровне табличных пространств. (по умолчанию: 16) (по умолчанию: 16)

Максимальный объем данных, который может быть прочитан одной операцией ввода-вывода, устанавливается параметром io_combine_limit; значение по умолчанию соответствует 16 стандартным 8-килобайтным страницам. Если операционная система поддерживает более крупные операции, увеличение значения может пойти на пользу OLAP-системам, в которых большие таблицы часто сканируются полностью. (по умолчанию: 128 kB)

Параметр io_combine_limit можно менять на лету, но в пределах, установленных другим параметром, io_max_combine_limit, изменение которого требует перезапуска сервера. (по умолчанию: 128 kB)

Пока асинхронно выполняются только следующие операции:

• последовательное чтение (Seq Scan); (с. 374)

• сканирование по битовой карте (Bitmap Heap Scan); (с. 427)

• очистка и анализ таблиц, а также очистка B-деревьев и индексов GiST и SP-GiST; (с. 125)

• прогрев буферного кеша (расширение pg_prewarm);

• проверка целостности отношений (функция verify_heapam расширения amcheck).

Если асинхронный ввод-вывод отключен, при этих операциях PostgreSQL старается подсказать операционной системе глубину желаемой предвыборки, ориентируясь на значение параметра effective_io_concurrency или maintenance_io_concurrency. Также есть пара операций, которые пока не охвачены асинхронным вводом-выводом, но тоже инициируют предвыборку:

• чтение индексных страниц при удалении строк из таблицы ⁵;

• чтение страниц журнала при восстановлении⁶.

Представление pg_aios показывает дескрипторы асинхронного ввода-вывода, которые определяют операции и хранят состояния этих операций, пока они выполняются. Впрочем, представление предназначено не для обычного мониторинга, а скорее для разработчиков ядра.

9.2. Устройство буферного кеша

Буферный кеш PostgreSQL ⁷ хранит страницы отношений, сглаживая разницу между временем доступа к оперативной памяти (наносекунды) и к дискам (миллисекунды).

Буферный кеш располагается в общей памяти сервера и доступен всем процессам. Он занимает бóльшую часть общей памяти и является одной из самых важных и сложных структур данных. Понимание принципа работы кеша важно само по себе; к тому же многие другие структуры (такие как вложенные транзакции, статусы транзакций clog, журнальные записи) используют похожее, хотя и более простое кеширование.

Кеш называется буферным, потому что представляет собой массив буферов. Каждый буфер резервирует фрагмент памяти, достаточный для одной страницы данных и ее заголовка⁸.

Заголовок содержит информацию о буфере и загруженной в него странице, такую как:

• физическое расположение страницы (идентификатор файла отношения, слой и номер блока в слое);

• признак того, что данные на странице изменились и рано или поздно должны быть записаны на диск (такую страницу называют грязной);

• число обращений к буферу (usage count);

• счетчик закреплений буфера (pin count или reference count).

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

Пока страница находится в буферном кеше, работа с ней не приводит к файловым операциям.

Внутрь буферного кеша позволяет заглянуть расширение pg_buffercache:

=> CREATE EXTENSION pg_buffercache;

Создадим таблицу и вставим в нее одну строку:

=> CREATE TABLE cacheme(
  id integer
) WITH (autovacuum_enabled = off);
=> INSERT INTO cacheme VALUES (1);

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

=> CREATE FUNCTION buffercache(rel regclass)
RETURNS TABLE(
  bufferid integer, relfork text, relblk bigint,
  isdirty boolean, usagecount smallint, pins integer
) AS $$
SELECT bufferid,
  CASE relforknumber
    WHEN 0 THEN 'main'
    WHEN 1 THEN 'fsm'
    WHEN 2 THEN 'vm'
  END,
  relblocknumber,
  isdirty,
  usagecount,
  pinning_backends
FROM pg_buffercache
WHERE relfilenode = pg_relation_filenode(rel)
AND relforknumber = 0 -- только main
ORDER BY relforknumber, relblocknumber;
$$ LANGUAGE sql;
=> SELECT * FROM buffercache('cacheme');
 bufferid | relfork | relblk | isdirty | usagecount | pins
----------+---------+--------+---------+------------+------
      355 | main    |      0 | t       |          1 |    0
(1 row)

Страница грязная (isdirty), поскольку изменена и еще не записана на диск. Счетчик обращений (usagecount) равен единице.

9.3. Попадание в кеш

Когда менеджеру буферов требуется прочитать страницу¹⁰, он сначала пытается найти ее в буферном кеше. Для быстрого поиска нужного буфера используется хеш-таблица ¹¹, хранящая номера буферов.

Известно много вариантов реализации хеш-таблиц. Для буферного кеша используется динамически расширяемая таблица c разрешением хеш-коллизий с помощью цепочек¹².

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

Если номер буфера найден в хеш-таблице, менеджер закрепляет этот буфер и возвращает его номер процессу. После этого процесс может работать со страницей в буферном кеше, и это не приводит к вводу-выводу. (с. 133)

Чтобы закрепить буфер, нужно увеличить счетчик pin count в его заголовке; один и тот же буфер могут одновременно закрепить несколько процессов.

Пока буфер закреплен (т. е. значение счетчика больше нуля), считается, что буфер используется и его содержимое не должно «радикально» измениться. Например, в странице может появиться новая версия строки (она не будет видна благодаря правилам видимости), но страница не может быть заменена на другую.

Команда EXPLAIN с параметрами analyze и buffers не просто показывает план запроса, но и выполняет его, а также выводит количество использованных буферов:

=> EXPLAIN (analyze, costs off, timing off, summary off)
  SELECT * FROM cacheme;
                   QUERY PLAN
------------------------------------------------
 Seq Scan on cacheme (actual rows=1.00 loops=1)
   Buffers: shared hit=1
 Planning:
   Buffers: shared hit=2 read=6
(4 rows)

Здесь hit=1 говорит о том, что потребовалось прочитать одну страницу и она была найдена в кеше.

Закрепление буфера увеличило счетчик обращений на единицу:

=> SELECT * FROM buffercache('cacheme');
 bufferid | relfork | relblk | isdirty | usagecount | pins
----------+---------+--------+---------+------------+------
      355 | main    |      0 | t       |          2 |    0
(1 row)

Теперь обновим строку, чтобы в странице были две версии: одна актуальная, а вторая — мертвая. Это понадобится нам чуть позже.

=> UPDATE cacheme SET id = 2;
UPDATE 1

Воспользуемся тем, что открытый курсор удерживает закрепление, чтобы иметь возможность быстро прочитать следующую строку выборки. Это позволит нам увидеть закрепление в процессе работы запроса:

=> BEGIN;
=> DECLARE c CURSOR FOR SELECT * FROM cacheme;
=> FETCH c;
 id
----
  2
(1 row)
=> SELECT * FROM buffercache('cacheme');
 bufferid | relfork | relblk | isdirty | usagecount | pins
----------+---------+--------+---------+------------+------
      355 | main    |      0 | t       |          4 |    1
(1 row)

В некоторых случаях, когда требуется именно закрепленный буфер, процесс встает в очередь и засыпает до того момента, когда он сможет получить монопольный доступ к буферу. Пример такой операции — заморозка ¹⁴. (с. 134)

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

=> VACUUM VERBOSE cacheme;
INFO:  vacuuming "internals.public.cacheme"
INFO:  finished vacuuming "internals.public.cacheme": index
scans: 0
pages: 0 removed, 1 remain, 1 scanned (100.00% of total), 0
eagerly scanned
tuples: 0 removed, 2 remain, 0 are dead but not yet removable
tuples missed: 1 dead from 1 pages not removed due to cleanup
lock contention
removable cutoff: 908, which was 0 XIDs old when operation ended
new relfrozenxid: 905, which is 1 XIDs ahead of previous value
frozen: 0 pages from table (0.00% of total) had 0 tuples frozen
visibility map: 0 pages set all-visible, 0 pages set all-frozen
(0 were all-visible)
index scan not needed: 0 pages from table (0.00% of total) had 0
dead item identifiers removed
avg read rate: 0.000 MB/s, avg write rate: 137.061 MB/s
buffer usage: 33 hits, 0 reads, 3 dirtied
WAL usage: 4 records, 3 full page images, 25030 bytes, 0 buffers
full
system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
VACUUM

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

=> COMMIT;
=> SELECT * FROM buffercache('cacheme') WHERE relfork = 'main';
 bufferid | relfork | relblk | isdirty | usagecount | pins
----------+---------+--------+---------+------------+------
      355 | main    |      0 | t       |          4 |    0
(1 row)

Так же закрепление работает и при изменении страницы. Например, добавим в таблицу еще одну строку (она попадет в ту же самую страницу):

=> INSERT INTO cacheme VALUES (2);
=> SELECT * FROM buffercache('cacheme') WHERE relfork = 'main';
 bufferid | relfork | relblk | isdirty | usagecount | pins
----------+---------+--------+---------+------------+------
      355 | main    |      0 | t       |          5 |    0
(1 row)

Страница не записывается на диск немедленно, а остается грязной в буферном кеше: происходит экономия и на чтении с диска, и на записи.

9.4. Промах кеша

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

Уберем страницу из буфера (вместо этого можно было бы очистить весь буферный кеш, перезапустив экземпляр): (v. 17)

=> SELECT pg_buffercache_evict(355);
 pg_buffercache_evict
----------------------
 (t,t)
(1 row)

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

=> EXPLAIN (analyze, costs off, timing off, summary off)
  SELECT * FROM cacheme;
                   QUERY PLAN
------------------------------------------------
 Seq Scan on cacheme (actual rows=2.00 loops=1)
   Buffers: shared read=1 dirtied=1
 Planning:
   Buffers: shared hit=2
(4 rows)

Теперь вместо hit команда показывает read, что означает промах кеша. При этом в результате запроса страница стала грязной (dirtied), так как запрос изменил биты-подсказки на странице. (с. 86)

Запрос к буферному кешу покажет, что счетчик использований только что добавленной страницы равен единице:

=> SELECT * FROM buffercache('cacheme');
 bufferid | relfork | relblk | isdirty | usagecount | pins
----------+---------+--------+---------+------------+------
      378 | main    |      0 | t       |          1 |    0
(1 row)

Общую статистику использования буферного кеша для таблицы можно получить из представления pg_statio_all_tables:

=> SELECT heap_blks_read, heap_blks_hit
FROM pg_statio_all_tables
WHERE relname = 'cacheme';
 heap_blks_read | heap_blks_hit
----------------+---------------
              1 |             9
(1 row)

Аналогичные представления есть для индексов и для последовательностей.

Поиск буфера и вытеснение

Поиск подходящего буфера ¹⁵ — непростая задача. Есть два варианта развития событий.

1. Сразу после запуска сервера кеш содержит только пустые, свободные буферы, и все они связаны в общий список.

Пока остаются свободные буферы, первый из них считается подходящим и убирается из списка.

Буфер может вернуться ¹⁶ в список свободных буферов только в том случае, когда страница исчезает, а не заменяется другой страницей. Это происходит при удалении (DROP), опустошении (TRUNCATE) или усечении хвостовой части таблиц во время очистки. (с. 133)

2. Рано или поздно свободные буферы заканчиваются (поскольку обычно размер базы данных превышает объем памяти, выделенной под кеш), и тогда менеджер должен выбрать один из занятых буферов и вытеснить находящуюся там страницу. Для этого используется «часовой» алгоритм (clock sweep). Имеется «часовая стрелка», указывающая на один из буферов. Стрелка пробегает буферный кеш по кругу, уменьшая счетчики обращений к страницам на единицу. Поиск завершается, когда стрелка доходит до незакрепленного буфера с нулевым счетчиком.

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

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

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

Но если буфер оказался грязным, то есть содержит измененные данные, старую страницу нельзя просто выбросить — сначала менеджер буферов сохраняет ее на диск. (с. 226)

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

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

9.5. Массовое вытеснение

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

Чтобы этого избежать, для массовых операций в буферном кеше используются относительно небольшие буферные кольца (buffer ring), и вытеснение происходит в их пределах, не затрагивая остальные буферы.

Буферное кольцо заданного размера представляет собой массив буферов, которые используются «по кругу», один за другим. Сначала буферное кольцо пусто, и буферы набираются в него из буферного кеша обычным образом. А затем начинает действовать вытеснение, но только внутри кольца¹⁷.

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

Существует три стратегии вытеснения¹⁸.

Стратегия массового чтения (bulkread) применяется при последовательном сканировании больших таблиц, размер которых превышает четверть буферного кеша. (с. 374)

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

Если в момент начала сканирования таблицы процесс обнаруживает, что эта таблица уже сканируется, он присоединяется к существующему буферному кольцу и получает часть таблицы без избыточного ввода-вывода¹⁹. Когда первый процесс заканчивает сканирование, второй отдельно дочитывает пропущенное начало таблицы.

Кольцо должно быть достаточно большим, чтобы буферы успевали освобождаться до того, как потребуются повторно, и задерживались в кольце достаточно долго, чтобы несколько читающих процессов могли синхронизироваться. При асинхронном вводе-выводе одновременно могут выполняться effective_io_concurrency операций, каждая из которых может читать io_combine_limit байт, что и определяет необходимый размер. Если асинхронный ввод-вывод отключен, произведение обратится в ноль; на этот случай добавляется еще 256 Кбайт (32 стандартные страницы). Но чтобы кольцо не получилось уж слишком большим, его размер ограничен отношением объема буферного кеша к максимальному количеству процессов в системе: кеша должно хватить на всех. (v. 18) (с. 183) (по умолчанию: 16) (по умолчанию: 128K)

Таким образом, с настройками по умолчанию — при достаточном большом буферном кеше — размер кольца будет составлять 32 + 16 ⋅ 16 = 288 буферов.

Стратегия массовой записи (bulkwrite) применяется для операций COPY FROM, CREATE TABLE AS SELECT, CREATE MATERIALIZED VIEW и тех вариантов ALTER TABLE, которые вызывают перезапись таблицы. Выделяется довольно большое кольцо размером 16 Мбайт (2048 стандартных страниц), но не больше $\frac18$ от размера всего буферного кеша.

Стратегия очистки (vacuum) применяется процессами очистки и анализа при полном сканировании таблиц без учета карты видимости. Размер кольца определяется параметром vacuum_buffer_usage_limit, но может быть переопределен в команде VACUUM или ANALYZE. (по умолчанию: 2MB) (v. 16)

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

Другой важный случай — хранение в базе данных больших значений, для которых используется TOAST. Доступ к toast-таблице всегда происходит по индексу, несмотря на потенциально большой объем читаемых данных, и, следовательно, не использует буферное кольцо. (с. 33)

Посмотрим теперь на стратегию массового чтения. Для упрощения расчетов создадим таблицу так, чтобы при вставке одна строка занимала целую страницу. Размер буферного кеша по умолчанию — 16 384 страницы по 8 Кбайт. Значит, чтобы сканирование таблицы использовало буферное кольцо, таблица должна занимать больше 4096 страниц.

=> CREATE TABLE big(
  id integer PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
  s char(1000)
) WITH (fillfactor = 10);
=> INSERT INTO big(s) SELECT 'FOO' FROM generate_series(1,4096+1);

Проанализируем таблицу:

=> ANALYZE big;
=> SELECT relname, relfilenode, relpages
FROM pg_class
WHERE relname IN ('big', 'big_pkey');
 relname  | relfilenode | relpages
----------+-------------+----------
 big      |       16569 |     4097
 big_pkey |       16575 |       14
(2 rows)

Очистим кеш от табличных страниц, прочитанных во время анализа, после чего прочитаем всю таблицу: (v. 18)

=> SELECT pg_buffercache_evict_relation('big'::regclass);
 pg_buffercache_evict_relation
-------------------------------
 (4101,4099,0)
(1 row)
=> EXPLAIN (analyze, costs off, timing off, summary off, buffers off)
SELECT * FROM big;
                  QUERY PLAN
-----------------------------------------------
 Seq Scan on big (actual rows=4097.00 loops=1)
(1 row)

Размер буферного кольца ограничен из-за небольшого объема буферного кеша — табличными страницами в нем занято только 94 буфера вместо ожидаемых 288:

=> SELECT count(*)
FROM pg_buffercache
WHERE relfilenode = pg_relation_filenode('big'::regclass);
 count
-------
    94
(1 row)

Если же таблица читается с помощью индекса, то буферное кольцо не используется:

=> EXPLAIN (analyze, costs off, timing off, summary off, buffers off)
SELECT * FROM big
ORDER BY id;
                           QUERY PLAN
----------------------------------------------------------------
 Index Scan using big_pkey on big (actual rows=4097.00 loops=1)
   Index Searches: 1
(2 rows)

В результате в буферном кеше оказывается вся таблица и весь индекс:

=> SELECT relfilenode, count(*)
FROM pg_buffercache
WHERE relfilenode IN (
  pg_relation_filenode('big'), pg_relation_filenode('big_pkey')
)
GROUP BY relfilenode;
 relfilenode | count
-------------+-------
       16569 |  4097
       16575 |    14
(2 rows)

9.6. Настройка размера

Размер буферного кеша определяется параметром shared_buffers. Значение по умолчанию заведомо занижено; имеет смысл увеличить его сразу же после установки PostgreSQL. Изменение параметра требует перезапуска, поскольку общая память выделяется под кеш при старте сервера. (по умолчанию: 128MB)

Из каких соображений выбирать подходящее значение?

Даже самая большая база имеет ограниченный набор «горячих» данных, с которыми ведется активная работа в каждый момент времени. В идеале именно этот набор и должен помещаться в буферный кеш (конечно, с запасом под неизбежные «одноразовые» данные). Если размер кеша будет меньше, то активно используемые страницы будут постоянно вытеснять друг друга, создавая избыточный ввод-вывод. Но и бездумно увеличивать кеш тоже неправильно, поскольку это повышает накладные расходы на его поддержание, а оперативная память требуется и для других нужд.

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

Надо также принимать во внимание, что — пока не включен прямой ввод-вывод — промах кеша PostgreSQL не обязательно приводит к физическому вводу-выводу. При небольшом буферном кеше свободное место будет задействовано под кеш операционной системы, что может в определенной степени сглаживать проблему. Но, в отличие от СУБД, операционная система ничего не знает о смысле прочитанных данных, поэтому использует другую стратегию вытеснения.

Стандартная рекомендация — взять в качестве первого приближения $\frac14$ оперативной памяти, а дальше смотреть по ситуации.

Лучше всего провести эксперименты: увеличить или уменьшить размер кеша и сравнить характеристики системы. Конечно, для этого надо иметь тестовый стенд, аналогичный производственной системе, и уметь воспроизводить типовую нагрузку.

Но некоторый анализ все же возможен.

Во-первых, с помощью уже знакомого расширения pg_buffercache можно смотреть на текущее состояние кеша под разными углами. Например, изучить распределение буферов по степени их использования:

=> SELECT usagecount, count(*)
FROM pg_buffercache
GROUP BY usagecount
ORDER BY usagecount;
 usagecount | count
------------+-------
          1 |  4148
          2 |   146
          3 |    21
          4 |    15
          5 |   209
            | 11845
(6 rows)

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

Можно посмотреть, какая часть каждого из отношений закеширована и насколько активно используются эти данные (в этом запросе активными считаются страницы со счетчиком использования больше единицы):

=> SELECT c.relname,
  count(*) blocks,
  round( 100.0 * 8192 * count(*) /
    pg_table_size(c.oid) ) AS "% of rel",
  round( 100.0 * 8192 * count(*) FILTER (WHERE b.usagecount > 1) /
    pg_table_size(c.oid) ) AS "% hot"
FROM pg_buffercache b
  JOIN pg_class c ON pg_relation_filenode(c.oid) = b.relfilenode
WHERE b.reldatabase IN (
  0, -- общие объекты кластера
  (SELECT oid FROM pg_database
   WHERE datname = current_database())
)
AND b.usagecount IS NOT NULL
GROUP BY c.relname, c.oid
ORDER BY 2 DESC
LIMIT 5;
   relname    | blocks | % of rel | % hot
--------------+--------+----------+-------
 big          |   4097 |      100 |     2
 pg_attribute |     58 |       94 |    50
 pg_proc      |     24 |       20 |    15
 pg_class     |     17 |       94 |    67
 big_pkey     |     14 |      100 |   100
(5 rows)

Здесь видно, что таблица big и ее индекс полностью закешированы, но их страницы не используются активно.

Стоит учитывать, что запросы к pg_buffercache:

• надо повторять несколько раз, так как цифры будут меняться в определенных пределах;

• не надо выполнять непрерывно, потому что представление блокирует, хоть и кратковременно, просматриваемые буферы.

Поэтому для мониторинга лучше пользоваться другими функциями расширения — pg_buffercache_summary и pg_buffercache_usage_counts, — которые требуют меньше блокировок и за счет этого позволяют быстро оценить общую (хотя, возможно, немного рассогласованную) картину происходящего. (v. 16)

Во-вторых, подробная информация о вводе-выводе, проходящем через буферный кеш, накапливается в представлении pg_stat_io. Например, можно изучить количество операций ввода-вывода в разбивке по стратегиям использования буферных колец (контекст normal соответствует обычным операциям без кольца): (v. 16)

=> SELECT context,
  sum(reads) AS reads, sum(writes) AS writes,
  sum(hits) AS hits, sum(evictions) AS evictions, sum(reuses) AS reuses
FROM pg_stat_io
WHERE object = 'relation'
  AND context in ('normal','bulkread','bulkwrite','vacuum')
GROUP BY context;
  context  | reads  | writes |   hits   | evictions | reuses
-----------+--------+--------+----------+-----------+--------
 vacuum    | 138091 | 539140 |    89134 |      1846 | 656633
 normal    |  95057 | 342503 | 71883823 |    271326 |
 bulkwrite |      0 |      0 |        8 |         0 |      0
 bulkread  |  30506 | 155238 |    77778 |    175469 |  99285
(4 rows)

Запрос также показывает число попаданий в кеш (hits) и вытеснений из кеша: «обычные» вытеснения учитываются в поле evictions, а вытеснения страниц из буферного кольца — в поле reuses. Из этих цифр можно сделать определенные выводы о характере использования кеша.

Кроме количества операций чтения и записи (reads и writes), из представления можно узнать и объем ввода-вывода (read_bytes и write_bytes) в байтах: (v. 18)

=> SELECT context,
  pg_size_pretty(read_bytes) AS read_bytes,
  round(read_bytes/reads/8192, 1) AS pages_per_read,
  pg_size_pretty(write_bytes) AS write_bytes,
  round(write_bytes/writes/8192, 1) AS pages_per_write
FROM (
  SELECT context,
    sum(reads) AS reads,
    sum(read_bytes) AS read_bytes,
    sum(writes) AS writes,
    sum(write_bytes) AS write_bytes
  FROM pg_stat_io
  WHERE object = 'relation'
  GROUP BY context
  HAVING sum(reads) + sum(writes) > 0
);
 context  | read_bytes | pages_per_read | write_bytes | pages_per_write
----------+------------+----------------+-------------+-----------------
 vacuum   | 5147 MB    |            4.8 | 4212 MB     |             1.0
 normal   | 760 MB     |            1.0 | 2676 MB     |             1.0
 bulkread | 2155 MB    |            9.0 | 1213 MB     |             1.0
(3 rows)

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

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

Представление pg_stat_io показывает данные, сгруппированные по типам процессов. Детализацию до конкретного обслуживающего процесса (пока он работает) можно получить функцией pg_stat_get_backend_io, которая возвращает таблицу с тем же набором полей. (v. 18)

Изучение данных pg_buffercache и pg_stat_io в различных разрезах может дать полезную информацию для размышлений.

9.7. Прогрев кеша

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

=> CREATE EXTENSION pg_prewarm;

Кроме обычного чтения таблиц в буферный кеш (или только в кеш операционной системы), расширение позволяет сохранять актуальное состояние кеша на диск и восстанавливать его же после перезагрузки сервера. Для этого надо добавить библиотеку расширения в параметр shared_preload_libraries и перезагрузить сервер:

=> ALTER SYSTEM SET shared_preload_libraries = 'pg_prewarm';
postgres$ pg_ctl restart -l /home/postgres/logfile

После перезапуска, если значение параметра pg_prewarm.autoprewarm не менялось, будет автоматически запущен фоновый процесс autoprewarm leader, который раз в pg_prewarm.autoprewarm_interval единиц времени будет сбрасывать на диск список страниц, находящихся в кеше (этот процесс использует один из слотов max_parallel_processes). (по умолчанию: on) (по умолчанию: 300s)

postgres$ ps -o pid,command \
--ppid `head -n 1 /usr/local/pgsql/data/postmaster.pid` | \
grep prewarm
  57518 postgres: autoprewarm leader

Сейчас, после перезагрузки, таблица big в кеше отсутствует:

=> SELECT count(*)
FROM pg_buffercache
WHERE relfilenode = pg_relation_filenode('big'::regclass);
 count
-------
     0
(1 row)

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

=> SELECT pg_prewarm('big');
 pg_prewarm
------------
       4097
(1 row)
=> SELECT count(*)
FROM pg_buffercache
WHERE relfilenode = pg_relation_filenode('big'::regclass);
 count
-------
  4097
(1 row)

Список страниц сбрасывается в файл PGDATA/autoprewarm.blocks. Можно подождать, пока процесс autoprewarm leader отработает в первый раз, но мы инициируем запись вручную:

=> SELECT autoprewarm_dump_now();
 autoprewarm_dump_now
----------------------
                 4262
(1 row)

Число сброшенных страниц больше 4097, поскольку включает все занятые буферы. Файл записывается в текстовом формате и содержит идентификаторы базы данных, табличного пространства и файла, номер слоя и номер блока:

postgres$ head -n 10 /usr/local/pgsql/data/autoprewarm.blocks
<<4262>>
0,1664,1262,0,0
0,1664,1260,0,0
16391,1663,1259,0,0
16391,1663,1259,0,1
16391,1663,1259,0,2
16391,1663,1259,0,3
16391,1663,1259,0,4
16391,1663,1259,0,5
16391,1663,1259,0,6

Теперь снова перезапустим сервер.

postgres$ pg_ctl restart -l /home/postgres/logfile

Таблица сразу же оказывается в кеше:

=> SELECT count(*)
FROM pg_buffercache
WHERE relfilenode = pg_relation_filenode('big'::regclass);
 count
-------
  4097
(1 row)

Это обеспечивается тем же самым процессом autoprewarm leader: он читает файл, разделяет страницы по базам данных, сортирует их (чтобы чтение с диска было по возможности последовательным) и передает отдельному рабочему процессу autoprewarm worker для обработки.

9.8. Локальный кеш

Исключением из общего правила являются временные таблицы. Поскольку временные данные видны только одному процессу, им нечего делать в общем буферном кеше. Поэтому для временных данных используется кеш в локальной памяти процесса, владеющего таблицей²⁰.

В целом локальный буферный кеш устроен так же, как и общий:

• для поиска страниц используется собственная хеш-таблица;

• страницы вытесняются по обычному алгоритму (но без использования буферных колец);

• страницы могут закрепляться, чтобы избежать вытеснения.

Однако его реализация серьезно упрощается, поскольку отпадает необходимость в блокировках в оперативной памяти (так как доступ к буферам имеет только один процесс) и в защите данных от сбоя (так как данные в любом случае существуют максимум до конца сеанса). (с. 306) (с. 211)

Память под локальный кеш выделяется постепенно, по мере необходимости, поскольку временные таблицы используются далеко не во всех сеансах. Максимальный объем кеша одного сеанса ограничен параметром temp_buffers. (по умолчанию: 8MB)

В выводе команды EXPLAIN обращения к локальному буферному кешу отмечаются словом local вместо shared:

=> CREATE TEMPORARY TABLE tmp AS SELECT 1;
=> EXPLAIN (analyze, costs off, timing off, summary off)
  SELECT * FROM tmp;
                 QUERY PLAN
--------------------------------------------
 Seq Scan on tmp (actual rows=1.00 loops=1)
   Buffers: local hit=1
 Planning:
   Buffers: shared hit=12 read=7
(4 rows)

Данные о вводе-выводе страниц локальных кешей процессов позволяет получить уже знакомое нам представление pg_stat_io: (v. 16)

=> SELECT context, sum(reads) reads, sum(writes) writes,
  sum(hits) hits, sum(evictions) evictions, sum(reuses) reuses
FROM pg_stat_io
WHERE object = 'temp relation'
GROUP BY context;
 context | reads | writes | hits | evictions | reuses
---------+-------+--------+------+-----------+--------
 normal  |     0 |      0 |    1 |         0 |
(1 row)