Буферный кеш

Буферный кеш - это область разделяемой памяти, нарезанная на слоты («буферы») размером ровно со страницу, 8 КБ. Её размер задаёт shared_buffers. Все процессы-бэкенды работают с одним и тем же кешем: если один поднял страницу, второй найдёт её там же, а не будет читать с диска заново.

Логика обращения всегда одна:

1. бэкенду нужна страница - он ищет её в кеше;
2. нашёл - работает с ней в памяти (это попадание, hit);
3. не нашёл - читает с диска в свободный буфер (это промах, read);
4. если свободных буферов нет - сначала надо кого-то выселить.

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

Удобно смотреть на работу с кешем через четыре исхода. Любое обращение к данным сводится к одному из них:

• hit - страница уже в кеше, диск не нужен. Самый дешёвый исход;
• read - страницы в кеше нет, читаем с диска в свободный буфер;
• dirtied - буфер изменили в памяти; теперь он «грязный» и отличается от того, что на диске;
• written - грязный буфер сбросили на диск.

Видеть эти исходы числом - значит понимать, что происходит с базой. Простой срез - в pg_statio_user_tables (heap_blks_hit против heap_blks_read); подробный, с PostgreSQL 16, - в pg_stat_io. Разбор состояний - в buffer-states.

Грязный буфер не сбрасывается на диск сразу после изменения - иначе терялся бы весь смысл кеша. На диск его относят три участника:

• bgwriter (background writer) - фоновый процесс, который потихоньку сбрасывает грязные буферы заранее, чтобы бэкендам было куда селить новые страницы;
• checkpointer - сбрасывает все грязные буферы во время контрольной точки (глава 19);
• сам бэкенд - если ему нужен свободный буфер, а под рукой только грязные, он вынужден сбросить один сам, прямо в ходе запроса.

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

Когда все буферы заняты, а нужен новый, PostgreSQL должен кого-то выселить. Наивно было бы выкидывать «давно не использованный» (LRU), но честный LRU дорого поддерживать под высокой конкуренцией. Вместо этого используется приближённый алгоритм - clock-sweep («часовая стрелка»).

У каждого буфера есть счётчик популярности usage_count. При каждом обращении он растёт (до небольшого потолка). Стрелка ходит по буферам по кругу:

• если у буфера usage_count > 0 - стрелка уменьшает счётчик на единицу и идёт дальше («ты популярен, поживёшь ещё круг»);
• если usage_count = 0 и буфер никем не «прибит» (не pinned) - его выселяют, на его место читают новую страницу.

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

Кеш - не чёрный ящик. Расширение pg_buffercache показывает каждый занятый буфер: какой странице какого отношения он принадлежит, грязный ли он, какой у него usage_count.

CREATE EXTENSION IF NOT EXISTS pg_buffercache;

-- сколько буферов занимает таблица flights

SELECT count(*) AS buffers,

       count(*) FILTER (WHERE isdirty) AS dirty

FROM pg_buffercache

WHERE relfilenode = pg_relation_filenode('flights');

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

В PostgreSQL 16 появился дешёвый сводный вид pg_buffercache_summary

• он не сканирует весь кеш построчно, а отдаёт агрегат (сколько буферов занято, сколько грязных, средний usage_count). Удобно для мониторинга. Детали - в buffer-cache.

Представьте SELECT count(*) по таблице в десятки гигабайт. Если бы он читал все страницы в обычном порядке, он вытеснил бы из кеша вообще всё полезное, набив его данными, которые после прохода больше не нужны. Один отчёт - и кеш «холодный» для всех.

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

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

Кольцо включается, когда таблица больше четверти shared_buffers. Свои кольца есть и у VACUUM, и у массовых записей (COPY). Это объясняет неожиданное на первый взгляд: большой отчёт может быть медленным каждый раз, потому что его данные намеренно не оседают в кеше. Подробнее про устройство кольца - в buffer-ring.

Копнуть глубже: сканы умеют объединяться. Если две сессии одновременно последовательно сканируют одну большую таблицу, PostgreSQL может пристроить вторую к уже идущему скану первой - они читают страницы «паровозиком» с одной позиции. Один проход по диску обслуживает оба запроса. Управляется это параметром synchronize_seqscans.

Буферный кеш хранит страницы таблиц и индексов. Но у PostgreSQL есть и служебные структуры - статусы транзакций (clog), multixact, subtransactions. Их держат отдельные маленькие кеши - SLRU (Simple Least Recently Used).

Они невелики и обычно не привлекают внимания, но на специфических нагрузках (много мелких транзакций, обилие блокировок строк) могут стать узким местом - так называемое «SLRU contention». В PostgreSQL 17 их размеры стали настраиваемыми (*_buffers-параметры), а pg_stat_slru показывает по ним статистику. Знать про их существование полезно: когда обычные метрики кеша в норме, а база тормозит, иногда причина именно здесь.

Главное следствие всей этой главы - зазор между памятью и диском. Изменённая страница какое-то время живёт только в кеше; на диске пока старая версия. Если сервер упадёт в этот момент, изменение, казалось бы, потеряно.

Но мы знаем, что PostgreSQL переживает сбои без потери закоммиченных данных. Значит, есть что-то, что фиксирует изменение раньше, чем оно доходит до файла данных. Это журнал предзаписи - WAL, и именно он закрывает зазор. Следующая глава - о нём.