Архитектура PostgreSQL: процессы, страницы, WAL, shared buffers
↑ 2.1 PostgreSQL: индексы, транзакции, оптимизация · → Следующая
Зачем это на собесе
Понимание внутренностей помогает диагностировать проблемы производительности и надёжности.
Процессная модель
PostgreSQL создаёт отдельный процесс на каждое соединение (не поток). Поэтому соединения дороги (порядка 5–10 МБ на каждое) и нужен пул.
| Процесс | Роль |
|---|---|
postmaster | принимает соединения, порождает процессы |
| backend | обслуживает одно клиентское соединение |
checkpointer | сбрасывает грязные страницы на диск при контрольных точках |
background writer | плавно записывает грязные страницы |
WAL writer | сбрасывает WAL-буфер |
autovacuum launcher/workers | очистка мёртвых версий строк, статистика |
walsender / walreceiver | репликация |
archiver | архивация WAL |
Хранение на диске
- каждая таблица и индекс — файлы в каталоге данных (
base/<oid>/<relfilenode>), сегменты по 1 ГБ; - данные хранятся в страницах (pages) по 8 КБ; в странице — заголовок, массив указателей, кортежи (tuples);
- адрес строки — ctid
(номер страницы, номер элемента); - большие значения выносятся в TOAST (сжатие и хранение вне строки при > ~2 КБ);
- карта видимости (VM) и карта свободного места (FSM) — служебные слои.
Память
| Область | Параметр | Рекомендации |
|---|---|---|
| Общий кэш страниц | shared_buffers | около 25% ОЗУ как отправная точка |
| Память на операцию (сортировки, хэш) | work_mem | умножается на число операций и соединений, осторожно |
| Обслуживание | maintenance_work_mem | для VACUUM, CREATE INDEX |
| Подсказка планировщику | effective_cache_size | ≈ 50–75% ОЗУ (включая кэш ОС) |
PostgreSQL опирается также на кэш ОС (двойное кэширование).
WAL (Write-Ahead Log)
Правило: сначала записать изменение в журнал, потом в файлы данных.
- Изменение вносится в страницу в
shared_buffers(страница становится «грязной»). - Запись описания изменения в WAL, при
COMMIT—fsyncWAL на диск. - Страницы данных записываются позже (bgwriter, checkpointer).
- При аварии — redo: проигрывание WAL от последней контрольной точки.
Что даёт WAL: долговечность (Durability), быстрое подтверждение (последовательная запись), репликацию (передача WAL), PITR (восстановление на момент времени), логическую репликацию.
Параметры: wal_level (replica / logical), synchronous_commit, max_wal_size, checkpoint_timeout, full_page_writes.
Контрольная точка (checkpoint)
Сброс всех грязных страниц на диск и фиксация позиции в WAL. Слишком частые — всплески I/O, слишком редкие — долгое восстановление. Мониторинг: pg_stat_bgwriter / pg_stat_checkpointer.
Жизненный цикл запроса
- Parser: разбор SQL → дерево.
- Analyzer/Rewriter: проверка объектов, применение правил (представления).
- Planner/Optimizer: выбор плана по статистике (
pg_statistic,ANALYZE). - Executor: выполнение узлов плана.
Полезные представления
pg_stat_activity, pg_stat_database, pg_stat_user_tables, pg_locks, pg_stat_statements, pg_stat_wal.
Вопросы с ответами
Почему PostgreSQL нужен PgBouncer?
Каждое соединение — отдельный процесс с накладными расходами. Сотни и тысячи соединений от приложений истощают память и замедляют работу. Пулер мультиплексирует много клиентских соединений на малое число серверных.
Что такое WAL и зачем он?
Журнал упреждающей записи: изменения сначала фиксируются в нём. Гарантирует долговечность, восстановление после сбоя, репликацию и PITR.
Что такое TOAST?
Механизм хранения больших значений: они сжимаются и/или выносятся в отдельную таблицу, а в основной остаётся ссылка.