Чому налаштування autovacuum у PostgreSQL не встигає за навантаженням
Першим симптомом майже ніколи не буває відмова — спочатку зростає час відгуку на піках.
Таблиці розростаються швидше, ніж їх встигає обробити фонове очищення: мертві версії рядків залишаються в сторінках, місце під них не повертається в обіг, і кожен запит читає помітно більше сторінок, ніж у них корисних даних.
Окремо тривожно, що зовні це виглядає як штатна робота — індекси використовуються, плани запитів не змінюються, а деградація накопичується місяцями.
Заводські пороги розраховані на інший профіль навантаження. Поріг у п'яту частину від розміру таблиці для великої таблиці означає, що очищення увімкнеться після десятків мільйонів змінених рядків — а на цей момент змін набігає ще стільки ж.
Обмеження кількості паралельних воркерів призводить до того, що один важкий прохід тримає чергу і решта таблиць чекають; затримки між проходами за замовчуванням занадто великі для бази з постійним записом.
У підсумку фонове очищення не встигає не через помилку налаштування, а через те, що параметри ніхто не перераховував під реальний потік змін.
Далі підключається зворотний зв'язок: чим сильніше роздування таблиць, тим довше триває очищення, тим рідше воно завершується і тим швидше зростає база.
Планове обслуговування перетворюється на аварійне — ручний запуск очищення в робочі години, блокування, деградація на час проходу, ризик упертися у вільне місце на диску.
Розбираємо, як це закривається: як рахувати пороги під фактичний профіль запису і як повернути обслуговуванню регулярність.
Що дає кероване очищення таблиць: ефект у цифрах
Роздування та обсяг зберігання
Поріг спрацьовування за замовчуванням прив'язаний до частки таблиці, тому на великій таблиці autovacuum чекає, поки наберуться мільйони мертвих рядків, — і файли зростають швидше, ніж очищення встигає їх повертати.
Ми опускаємо поріг до прийнятної кількості рядків, додаємо запас вільного місця на сторінках під майбутні версії рядків і задаємо окремі правила для «гарячих» таблиць замість одного глобального.
За системними лічильниками видно, що частка мертвих рядків скорочується в рази, а розмір відношення перестає зростати між циклами очищення.
Відгук і стійкість
Звичайна картина під навантаженням — довге очищення витягує дисковий ввід-вивід і тримає блокування саме тоді, коли надходять пікові запити: час відповіді зростає стрибками, а черга запитів накопичується.
Ми обмежуємо інтенсивність очищення, розподіляємо його по воркерах і виводимо важкі прогони у вікна низького навантаження, залишаючи автозапуск увімкненим для решти таблиць.
У результаті пікові запити перестають упиратися в очищення, відгук залишається передбачуваним, а ручні аварійні прогони за розкладом зникають як клас відмов.
Режими VACUUM: порівняння підходів і оптимізація розкладу
Мертві рядки накопичуються за будь-якого режиму — різниця в тому, хто і коли запускає очищення. Нижче чотири робочі альтернативи та умови, за яких кожна з них доречна.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Порогове автоочищення | Рівний потік змін, таблиці передбачуваного розміру | Поріг за часткою від розміру спрацьовує пізно: між проходами накопичуються мертві рядки |
| Ручне очищення за вікном | Пакетні завантаження, нічні розрахунки, масові оновлення | Потрібен зовнішній планувальник; потрапляння вікна в пік трафіку дає зростання затримок |
| Очищення за секціями | Партиціоновані журнали та події з відсіканням старих секцій | Прохід по батьківській таблиці секції не очищає — обслуговувати потрібно кожну |
| Відкладена заморозка | Таблиці з рідкими оновленнями та старими версіями рядків | Запуск не прив'язаний до вікна обслуговування, прохід іде по всій таблиці |
Як вибрати режим під профіль навантаження
Дивіться на частку мертвих рядків до живих, швидкість зростання лічильника транзакцій і наявність вікна із просіданням трафіку.
Глобальні пороги задають поведінку за замовчуванням, але для гарячих таблиць їх перевизначають на рівні самої таблиці — велика таблиця перестає чекати загальної черги автоочищення і не накопичує мертві рядки між рідкими проходами.
Обмеження: блокування, реплікація, відставання копій
Очищення не блокує читання та запис, але конфліктує зі зміною структури таблиці та індексів. Паралельно воно пише в журнал попереднього запису: на репліках зростає потік змін, і копія може відставати на важких проходах.
Темп обмежують затримками вартості, а повні проходи та відкладену заморозку виносять у вікно низького навантаження, щоб обслуговування не збіглося зі звітами чи вивантаженнями.
Порядок робіт: від інвентаризації баз до регламенту обслуговування
Роботу будуємо від факту, а не від типового набору параметрів: спочатку знімаємо стан бази, потім змінюємо конфігурацію. Шість етапів нижче дають перевірюваний артефакт на кожному кроці, тому рішення про включення в робочий контур ухвалюється до правок, а не після.
Підготовка та безпечний пілот
- Знімаємо статистику очищення: скільки мертвих рядків накопичилося по таблицях, як часто проходить автоочищення, де лічильник мертвих рядків зростає найшвидше.
- Збираємо профіль навантаження і зростання таблиць: пікові години запису й оновлення, добовий і тижневий приріст, довгі транзакції, які утримують знімок і заважають очищенню.
- Проєктуємо пороги та вікна: окремі коефіцієнти для великих і активних таблиць, розклад примусового очищення в міжпікові інтервали, ліміт навантаження на дискову підсистему.
- Відпрацьовуємо схему на копії: розгортаємо копію бази, відтворюємо реальне навантаження, дивимося поведінку очищення під конкурентним записом і заміряємо тривалість блокувань.
Як перевіряємо результат
- Проводимо контрольні заміри до і після: частка мертвих рядків, час важких запитів, розмір файлів, частота аварійного очищення.
- Передаємо регламент: карта таблиць із порогами, правила перегляду при зростанні даних, набір запитів для самоперевірки та порядок дій при аномаліях.
Конфігурації, схеми вікон і регламенти обслуговування на виході
Ми передаємо не набір разових команд, а робочу конфігурацію: правила, за якими база підтримує себе, і процедури для випадків, коли автоочищення не справляється.
Усе лежить у репозиторії конфігурації та в документації — налаштування відтворюються на стенді й у проді без розбіжностей.
Що налаштовуємо в базі
- Пороги автоочищення за групами таблиць: для гарячих частка змінених рядків спрацьовує раніше, для великих архівів інтервали розширені, щоб планове очищення не витісняло термінове.
- Схема вікон обслуговування: важкі операції лише в години низького навантаження, з обмеженням тривалості та прив'язкою до чергувань.
- Перелік винятків: таблиці та великі архіви з окремим сценарієм — разові вставки, партиції під відсікання, дані лише для читання.
- Контрольні запити й оповіщення: частка мертвих рядків, давність останнього очищення, наближення до граничного лічильника транзакцій, швидкість зростання файлів.
Що залишається у вашої команди
- Порядок планового обслуговування: хто відкриває вікно, що перевіряється до і після, де фіксується результат.
- Регламент ескалації: за якими показниками черговий піднімає задачу, кому передає і що встигає зробити до відкату.
- Доступи та журнал ручних операцій: окремі облікові записи для обслуговування, обмеження і слід виконання.
- Документація з обґрунтуванням кожного порога — при зростанні даних правила перераховуються, а не підбираються заново.
Кейс: роздування скоротили втричі без зупинки сервісу
Вступні дані та обмеження проєкту
Кластер PostgreSQL обслуговував сервіс із безперервним потоком запису: кілька таблиць-журналів постійно оновлювалися, а автоочищення працювало на стандартних порогах спрацьовування.
Роздування зростало швидше, ніж очищення встигало його підбирати, — частка мертвих рядків у найгарячіших таблицях наблизилася до 40%, а обсяг зберігання розрісся майже втричі проти корисних даних. Вікна простою не було: сервіс працює цілодобово, зупиняти базу заради ручного очищення ми не могли.
Друге обмеження — аварійні прогони очищення. Їх запускали вручну, коли роздування перевалювало за критичну позначку; кожен прогон просідав відгук і тримав інженерів у напрузі.
Результат і що змінилося в обслуговуванні
Пороги спрацьовування та вартість очищення перерахували під профіль запису конкретних таблиць, а перехід робили на працюючій базі: спочатку прогін нових налаштувань на репліці, звірка планів і навантаження, потім плавне перемикання без вікна простою.
Частка мертвих рядків упала з 38% до 11%, обсяг зберігання скоротився втричі, відгук на піку став рівнішим — просідання на очищенні перестали бути помітні в метриках.
Число аварійних прогонів знизилося з кількох на місяць до одного-двох на квартал, і то з планових причин.
Обслуговування перейшло з режиму «гасимо пожежу» в спостереження: роздування, частота очищень і вік найстаріших транзакцій тепер на панелі метрик, а пороги переглядаються при зміні профілю запису.
Чим порогові політики відрізняються від розкладу за вікнами?
Порогові політики спираються на кількість змінених рядків: частка мертвих рядків у таблиці перевищує заданий відсоток — збирання запускається, не чекаючи календарної дати.
Це дає реакцію на сплески: пакетне видалення або масова заливка одразу піднімають лічильник, і застарілі версії рядків не встигають роздути файли.
Зворотний бік — непередбачуваність за навантаженням. На великій таблиці відсотковий поріг досягається рідко й пізно, на малій — збирання йде майже безперервно.
Піки вводу-виводу припадають на моменти, коли система й без того зайнята, а узгодити їх із резервним копіюванням та оновленням не можна: розкладу просто немає.
Планові вікна обслуговування знімають цю невизначеність. Запуск чищення прив'язаний до нічного інтервалу, інженер заздалегідь знає, коли база витратить ресурси на збирання сміття, і поєднує це з іншими регламентними роботами.
Ціна — запізнення: між вікнами таблиця накопичує мертві рядки, і сплеск у невдалий момент встигає надути файли швидше, ніж прийде розклад.
Гібридна схема очищення бере реактивність порогів і передбачуваність вікон: фонове чищення йде за розкладом, для таблиць із високим записом знижуються пороги й виставляється агресивніший режим, а заморозка та переіндексація залишаються у вікні.
Для баз, які вже обслуговуються вручну, це робочий варіант: ручний запуск зберігається як точка контролю, а пороги страхують від пропущеного вікна.
Автоочищення під навантаженням: блокування, великі таблиці, перевірка
Автоочищення вмикається саме і на навантаженій базі регулярно упирається в блокування, великі таблиці та нестачу часу на прохід. Нижче — відповіді на сумніви, які найчастіше звучать перед зміною цих налаштувань.
Усі вони про експлуатацію без простою: що можна правити на живій базі, а що потребує вікна.
Очищення заблокує таблиці та покладе сервіс?
Штатний прохід бере слабке блокування і не заважає ні читанню, ні запису. Монопольне тримають лише повне перезбирання таблиці та перебудування індексів — їх виносимо у вікно обслуговування.
Чи можна змінювати параметри без перезапуску?
Пороги та затримки задаються для конкретної таблиці й набирають чинності для наступних проходів — перезапуск не потрібен. Налаштування загального пулу пам'яті застосовуються при старті, їх плануємо заздалегідь.
Що робити з великими таблицями та архівами?
На таблиці в сотні гігабайт частка змінених рядків довго не доходить до порога, і вона залишається необробленою. Розбиваємо її на розділи за часом, пороги задаємо окремо, а старі архіви обслуговуємо своїм регламентом поза автоочищенням.
Як переконатися, що обробка йде?
Дивимося системні представлення та журнал: час останнього проходу, число мертвих рядків, лічильники заморозки. За ними налаштовуємо оповіщення — про застій дізнаємося до того, як виросте файл.
База обслуговується роками, усе запущено — з чого почати?
З обстеження: де накопичується мертве, які довгі транзакції тримають очищення, де лічильник ідентифікаторів близький до межі. Зміни проганяємо на копії і лише потім переносимо в робочий контур.
Обговоримо задачу: зберемо профіль навантаження та план робіт
Щоб оцінка спиралася на факти, а не на припущення, нам потрібні вихідні дані по вашій базі. Зібрати їх можна за один прохід по системних представленнях і журналах — на цій основі ми порахуємо обсяг робіт і порядок змін.
- статистика очищення: скільки мертвих рядків накопичується, які таблиці випадають з обробки, як часто спрацьовує автоочищення і де воно не встигає за записом;
- динаміка зростання таблиць та індексів — скільки обсягу додається за добу і на яких об'єктах зростання випереджає очищення;
- вікна навантаження: коли пік запису, в які години можна запускати важкі операції без впливу на користувачів;
- обмеження щодо простоїв: допустима тривалість недоступності, наявність реплік і можливість перемикання на них;
- уже застосовані налаштування — змінені пороги автоочищення, ручні розклади, обхідні правила, які хтось уводив раніше;
- параметри сервера та версія гілки: обсяг пам'яті, число ядер, тип диска, конфігурація журналу транзакцій;
- історія інцидентів: коли востаннє розростався журнал або просідала швидкість запитів після масового оновлення.
Опишіть задачу та додайте те, що є, — повернемося з оцінкою та планом робіт. У плані буде видно, що змінюємо в порогах, що переносимо в регулярний регламент і на яких контрольних замірах підтверджуємо результат.
