Базы данных
VACUUM, bloat и autovacuum
Таблица orders занимает 180 ГБ вместо ожидаемых 80 ГБ. Autovacuum запускался 14 раз за ночь. Диск полон к 7 утра. Почему VACUUM не помог — и как остановить это в следующий раз?
Откуда берётся bloat
Каждый UPDATE создаёт новую версию tuple плюс помечает старую мёртвой — оба на диске. До коммита оба существуют. После коммита мёртвая версия остаётся на диске, пока VACUUM не решит, что она больше никому не нужна.
Модель затрат:
| Операция | Heap | Индексы |
|---|---|---|
| INSERT | +1 tuple | +1 запись на индекс |
| UPDATE (не HOT) | +1 живой + 1 мёртвый tuple | +1 запись на индекс |
| UPDATE (HOT) | +1 живой + 1 мёртвый tuple | 0 новых записей |
| DELETE | +1 мёртвый tuple | (запись остаётся до VACUUM) |
Пока VACUUM не уберёт мёртвые tuple, каждый sequential scan пробегает мимо них, каждый индексный lookup может на них наткнуться, и каждая страница больше необходимого минимума.
Правило большого пальца: целевая доля мёртвых tuple менее 20% для таблиц больше 50 ГБ.
Три варианта уборки
| Операция | Что делает | Блокировка | Диск |
|---|---|---|---|
VACUUM | Помечает мёртвые tuple переиспользуемыми | SHARE UPDATE EXCLUSIVE (чтения/записи продолжаются) | Файл не сокращается |
VACUUM FULL | Переписывает всю таблицу | ACCESS EXCLUSIVE (блокирует всё) | Возвращает диск ОС |
pg_repack | Переписывает онлайн | Только короткий ACCESS EXCLUSIVE на финальный swap | Возвращает диск ОС |
Как autovacuum решает запускаться
Autovacuum — фоновый пул процессов (3 воркера по умолчанию), просыпающийся каждую минуту и проверяющий каждую таблицу на пороговое условие:
autovacuum_vacuum_threshold + autovacuum_vacuum_scale_factor × n_live_tupДефолт: 50 + 20% живых tuple. Когда таблица переходит порог, autovacuum посылает воркера.
Шаги одного прогона autovacuum:
Поставь шаги одного прогона autovacuum в правильном порядке:
- 1 Планировщик просыпается; проверяет n_dead_tup против threshold + scale_factor × n_live_tup
- 2 Воркер подключается; берёт SHARE UPDATE EXCLUSIVE (параллельные чтения и записи продолжаются)
- 3 Вычисляет глобально старейший xmin по всем сессиям — только tuple старше можно убирать
- 4 Скан heap: обходит каждую страницу, выявляет мёртвые tuple с t_xmax < oldest xmin
- 5 Помечает слоты мёртвых tuple переиспользуемыми; перестраивает free-space map
- 6 Чистка индексов: удаляет записи, ссылающиеся на освобождённые heap-слоты
- 7 Обновляет pg_class.relfrozenxid + счётчики pg_stat_all_tables; отпускает блокировку
Oldest xmin: почему долгие транзакции блокируют уборку
Autovacuum может убирать только tuple, чей t_xmax старше глобально старейшего xmin по всем сессиям. Если одна транзакция держится открытой, её backend_xmin пинит oldest-xmin.
Диагностика:
SELECT pid, backend_xmin,
now() - xact_start AS duration,
state, query
FROM pg_stat_activity
WHERE backend_xmin IS NOT NULL
ORDER BY backend_xmin
LIMIT 5;Самый старый backend_xmin — это то, что блокирует уборку.
Нюанс hot_standby_feedback
Стриминговые реплики можно настроить с hot_standby_feedback = on, которая отсылает primary старейший активный xmin реплики. Без неё долгий аналитический запрос на реплике может упасть с canceling statement due to conflict with recovery.
С ней bloat primary — заложник самого долгого запроса реплики. Большинство production-сетапов выбирают off на аналитической реплике и принимают периодические отмены запросов — закрепление bloat primary навсегда хуже.
Числа
- Bloat-цель (>50 ГБ)
- <20% мёртвых tuple
- Дефолты autovacuum
- 3 воркера, 60с naptime, 20% scale
- Блокировка VACUUM FULL
- ACCESS EXCLUSIVE
- Размер заголовка tuple
- 23 Б (+ выравнивание)
- XID ширина
- 32 бита; заморозка на 2^31
- pg_repack онлайн-стоимость
- временно 2x disk
Проверь себя
Таблица orders занимает 180 ГБ. Ты запустил VACUUM и он завершился без ошибок. Теперь df показывает... что?
Autovacuum запускался 10 раз за ночь, но n_dead_tup не падает. Какая самая вероятная причина?
Когда hot_standby_feedback = on на реплике, что происходит с primary?
- 01Почему обычный VACUUM не возвращает место ОС, даже если убрал миллионы мёртвых tuple?
- 02Долгая батч-задача накопила 10 ГБ мёртвых tuple на таблице orders. Autovacuum запускался, но n_dead_tup не падает. Что вероятная причина и как её подтвердить?
- 03Когда стоит выбрать VACUUM FULL вместо pg_repack?
- Каждый UPDATE пишет новый tuple + помечает старый мёртвым; mёртвые версии накапливаются до прохода VACUUM
- VACUUM помечает слоты переиспользуемыми; не сокращает файл и не возвращает диск ОС
- VACUUM FULL возвращает диск под ACCESS EXCLUSIVE (блокирует всё); pg_repack — онлайн аналог
- Autovacuum запускается по threshold + scale_factor × n_live_tup; cost-based rate-limit контролирует IO
- Oldest-xmin — потолок уборки; долгая транзакция или orphan slot пинит его для всей базы
- hot_standby_feedback = on на реплике → primary bloat заложник самого долгого запроса реплики
встречается в140
- Почему GraphQL получает N+1junior
- Механика DataLoader: батчинг на границе тикаmiddle
- Контракты batch-функции: порядок, формы, ошибкиmiddle
- Federation и lookahead: батчинг за пределами DataLoadermiddle
- Защита сложности запросов: depth, cost, persisted queriesmiddle
- Senior GraphQL API: scheduling-контракт, изоляция арендаторов, наблюдаемостьsenior
- Зачем идемпотентность: безопасные retryjunior
- Серверный state machine: четыре состояния idempotency keymiddle
- Outbox и inbox: effectively-once через dual-write границуmiddle
- Конкурентность и архитектура кеша для идемпотентности на масштабеsenior
- Наблюдаемость, production-инциденты и дизайн для глобального масштабаsenior
- Event loop: один поток, три очередиjunior
- Задачи, микрозадачи и scheduler.yield()middle
- Голодание микрозадач, длинные задачи и LoAFsenior
- Event loop Node.js: фазы, nextTick и задержка циклаsenior
- React, Vue и наблюдаемость INP в продакшенеsenior
- Render pipeline: шесть стадий от байтов до пикселейjunior
- Цена стадий и модель процесса рендерераmiddle
- Инвалидация, dirty-биты и containmiddle
- Слои композитора: продвижение, перекрытие и память GPUmiddle
- Флейм-стрип DevTools и жизненный цикл кадраmiddle
- Layout thrash: форсированная синхронная компоновкаsenior
- BeginMainFrame, анимации на потоке compositor и память GPUsenior
- Observability в проде: LoAF, INP и полная поверхность атакиsenior
- Что такое V8 и почему производительность различается в 100 разjunior
- Четырёхуровневый JIT-конвейер V8 и профилированная тиеризацияmiddle
- Hidden classes, деревья переходов и расположение в памятиmiddle
- Inline caches, состояния IC и деоптимизацияmiddle
- Orinoco GC: параллельный scavenger, конкурентная разметка и барьеры записиmiddle
- Спекулятивный движок TurboFan и ловушка deopt-loopsenior
- V8 в production: Isolates, сжатие указателей и реальные аварииsenior
- Жизненный цикл service worker и стратегии кешированияmiddle
- Граничные случаи service worker: version skew, долговременность и ловушка навигацииsenior
- Что делает реконсилер: render vs commitjunior
- Объект fiber и дерево с двойной буферизациейmiddle
- Чистота фазы render и подшаги фазы commitmiddle
- Реконсиляция: эвристики диффа и ловушка ключейmiddle
- Приоритетные lanes, time-slicing и useTransitionmiddle
- Bailout, мемоизация и tearingsenior
- React Profiler, компилятор и продакшн-наблюдаемостьsenior
- Стратегии рендеринга: SSG, SSR, ISR, streaming и гидратацияjunior
- SSG, SSR, ISR, streaming и RSC — как работает каждая стратегияmiddle
- Цена гидратации: selective, progressive, острова, resumabilitymiddle
- Hydration mismatch: причины, обнаружение и правило детерминизмаsenior
- RSC, стратегия на маршрут и production-наблюдаемостьsenior
- Core Web Vitals: что измеряют LCP, INP и CLSjunior
- CLS: почему происходят сдвиги лейаута и как их остановитьmiddle
- Трейдоффы метрик, RUM-атрибуция и цикл CI+полеsenior
- Общая картина: от URL до LCP до INP как эстафетаjunior
- Восемь слоёв трассировки: от service worker до второй навигацииmiddle
- Пять канонических поломок: где производство стабильно ломаетсяsenior
- Метод трёх треков: чтение трасс и построение системы мониторингаsenior
- Что такое cache stampede и почему он делает всё хужеjunior
- Лок и single-flight: ограничение параллельных rebuildmiddle
- XFetch: вероятностное раннее истечение без координацииmiddle
- Stale-while-revalidate и CDN request coalescingmiddle
- Детектирование stampede и дизайн TTL для продакшенаmiddle
- Метастабильный сбой, fencing-токены и production-постмортемыsenior
- Роли Raft, term и почему majority-кворум предотвращает split brainjunior
- Как Raft реплицирует log entry и решает, что его безопасно коммититьmiddle
- Выборы лидера в Raft: таймауты, правила голосования и четыре свойства безопасностиmiddle
- Raft в реальном мире: partition, медленный диск и клиентская маршрутизацияmiddle
- Расширения Raft: pre-vote, learner, snapshot и линеаризуемые чтенияsenior
- Raft в production: membership change, Multi-Raft и observabilitysenior
- Где происходит data fetching — и почему это решает LCPjunior
- Fetch waterfall''''ы — диагностика и лечение через Promise.allmiddle
- React Server Components и Suspense streamingmiddle
- Клиентский кэш: TanStack Query, SWR и stale-while-revalidatemiddle
- LCP, prefetch и race conditions в интерактивном fetchingmiddle
- Senior internals: RSC payload, слои кэша и production паденияsenior
- Трёхстороннее рукопожатие TCPjunior
- Номера последовательности и состояние соединенияmiddle
- DNS: что делает и зачем существуетjunior
- Обход резолвера: перенаправления, типы записей и gluemiddle
- TTL, кеширование и распространение DNSmiddle
- Рукопожатие за 1 RTT: key share и ECDHEmiddle
- Возобновление сессии и 0-RTTmiddle
- WebSocket: HTTP-апгрейд до постоянного соединенияjunior
- Формат WebSocket-фрейма: opcodes, маскирование, фрагментацияmiddle
- Backpressure в WebSocket: когда клиенты не успеваютmiddle
- Реконнект: jittered backoff, thundering herd, восстановление сообщенийsenior
- WebSocket в масштабе: HTTP/2 мультиплексирование, permessage-deflate, C10Msenior
- WebSocket в production: прокси, безопасность и распределённая архитектураsenior
- Что делают обратные проксиjunior
- Health checks, connection draining и slow startmiddle
- Session affinity, consistent hashing и правильное решениеmiddle
- Retry-бури, circuit breakers и load sheddingsenior
- Устойчивая архитектура LB: anycast, zone-aware маршрутизация и observabilitysenior
- Почему QUIC, а не TCP+TLSjunior
- Connection ID и миграция сетиmiddle
- Возобновление 0-RTT и шифрование пакетовsenior
- DDoS: что это и почему работаетjunior
- Атаки усиления и истощение состоянияmiddle
- Ограничение скорости: алгоритмы и архитектураmiddle
- WAF, межсетевые экраны, mTLS и HSTSmiddle
- Отравление DNS-кэша и BGP-перехватsenior
- Эшелонированная защита и экономика атакsenior
- DNS, TCP, TLS по очереди: куда уходят миллисекундыmiddle
- Перехват прокси и шлюзы безопасности: rate limiter, WAF, mTLSmiddle
- Альтернативные пути: QUIC 0-RTT, WebSocket upgrade, миграция соединенияmiddle
- Наблюдаемость: распределённые трейсы, USE/RED и семплированиеsenior
- Устойчивость: каскадные повторы, circuit breakers и error budgetsenior
- Что такое три сигнала: метрики, логи, трейсыjunior
- Зачем нужны структурные логи: дневник против таблицыjunior
- Схема продакшн-лога: поля, которые несёт каждая строкаmiddle
- PII-редакция и log injectionsenior
- OTel Logs Data Model и audit-логи как подсистемаsenior
- SLI, SLO и error budget: надёжность в числахjunior
- Error budget policy, latency SLO и составные journeysmiddle
- Продакшн-отказы SLO, самонаблюдаемость, безопасность и общая картинаsenior
- Петля инцидента: от пейджера до постмортема до предотвращенияmiddle
- Cache lines и false sharing: когда параллелизм замедляет кодmiddle
- SIMD и data layout: AoS vs SoA и разница в 4–8xmiddle
- Cache-oblivious алгоритмы, PGO и production failuressenior
- GC в production: наблюдаемость, безопасность, edge cases и управление флотомsenior
- Batching: амортизируй фиксированную цену каждой операцииjunior
- Окно батчинга: размер и время ожиданияmiddle
- Batching в Kafka и Postgresmiddle
- io_uring и наблюдаемость пакетированияmiddle
- От Nagle до io_uring: эволюция пакетированияmiddle
- Backpressure, изоляция сбоев и безопасность батчей в продакшенеsenior
- CI enforcement и RUM: делаем бюджеты рабочимиmiddle
- V8 JIT-пайплайн, HTTP-приоритеты и безопасность bundlesenior
- Цикл performance: дисциплина, а не проектjunior
- Классификация и исправление: сопоставление family bottleneck с методамиmiddle
- Observability-стек и CI gates: ловить регрессии до выпускаmiddle
- От инцидента к enforcement: SLO burn до верифицированного исправления за 35 минутmiddle
- Культура, экономика и масштаб performancesenior
- At-most-once, at-least-once, exactly-once: три контракта доставкиjunior
- Три ножки сбоя — где реально происходят дубликаты и потериmiddle
- Consumer-side dedup: самый дешёвый путь к exactly-once processingmiddle
- Kafka exactly-once semantics: idempotent producer и транзакцииmiddle
- SQS visibility timeout, DLQ и outbox patternmiddle
- Exactly-once в production: impossibility-доказательство, гибридные паттерны и реальные инцидентыsenior
- Что такое OAuth и почему пароли — не ответjunior
- Authorization code flow с PKCEmiddle
- Валидация ID-токена и управление JWKS-кешемmiddle
- Ротация refresh-токенов и scope-based least privilegemiddle
- Sender-constrained токены: DPoP и mTLSsenior
- OAuth в production: audience атаки, observability и реальные провалыsenior