Я використовую програмне забезпечення, яке створює велику базу даних PostgreSQL (є таблиця з мільйонам рядків), і розробники кажуть, що слід VACUUMі ANALYZEперіодично. Але за замовчуванням бази даних PostgreSQL autovacuumувімкнено.
Чи потрібно взагалі пилососити / аналізувати? Які переваги? Яка різниця між автоматичним та ручним вакуумом
Наприклад, у Pgadmin3 у мене є таке:
Відповіді:
Я погоджуюся з ETL, що короткої відповіді немає. Розмір - не єдине, що має значення - ми запускаємо досить великі бази даних PostgreSQL OLTP (з деякими таблицями> 100 000 000 рядків) під великим навантаженням, і в даний час ми покладаємося лише на автовакуум.
Однак дві речі здаються мені важливими:
Здається, існує консенсус, що автовакуум ніколи не слід вимикати, якщо ви не маєте чітко визначеного навантаження в своїй базі даних і не знаєте, що саме робите. Але, природно, ви можете зробити додаткові VACUUMта / або ANALYZEпробіжки.
Перш ніж розглянути додаткові VACUUMпробіжки, я перевірив би, як підтримує автовакуум. Ви можете перевірити, чи будь-які таблиці перевищують поріг автовакууму за допомогою запиту pg_stat_user_tablesта pg_class. Я розмістив такий запит на іншій темі, яка може зацікавити: Aggressive Autovacuum на PostgreSQL .
На жаль, не так просто (тобто наразі це неможливо) зробити аналогічну перевірку порогів автоаналізу. Однак автоаналіз починає задовго до автовакууму за замовчуванням, і це значно дешевше. Таким чином, якщо ваша база даних може йти в ногу з автовакуумом, можливо, це буде добре і з автоматичним аналізом. Останні дати самоаналізу можна також запитувати pg_stat_user_tables.
Деякі частини (найвищої) документації на PostgreSQL, які мені здаються корисними:
Autovacuum повинен досить добре покривати його, якщо ви щось неправильно не налаштували. Інші відповіді це вже висвітлюють.
Існує один чітко визначений випадок для посібника VACUUM (і що ще важливіше: посібник ANALYZE), хоча: тимчасові таблиці , їх не враховує демон автовакууму. Цитую посібник CREATE TABLEтут :
Автовакуумінг демон не може отримати доступ і , отже , не може пилососити або аналізувати тимчасові таблиці. З цієї причини слід виконувати відповідні операції вакууму та аналізу за допомогою сеансових команд SQL. Наприклад, якщо тимчасова таблиця буде використовуватися в складних запитах, розумно запустити її
ANALYZEна тимчасову таблицю після її заповнення.
На це немає короткої відповіді, оскільки це залежить від безлічі факторів. Система повільна? Чи справді авто-вакуум торкається цієї таблиці? тощо.
Ось кілька хороших посилань на цю тему:
Для прийняття чіткого рішення потрібно розуміти саму базу даних та більше деталей щодо того, що відбувається.
Я не думаю, що вам не потрібно вручну пилососити, якщо ви не почнете спостерігати зниження продуктивності. Однак я настійно рекомендую переглянути налаштування вакууму та автовакууму та налаштувати їх під свої потреби
Щоб побачити ваші поточні налаштування, запустіть цей запит:
SELECT *
FROM pg_settings
WHERE name LIKE '%vacuum%'Більшість полів не є зрозумілими, але ось документація щодо них: https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html
Я б сказав, що вашою метою має бути налаштування автовакууму для послідовного очищення сміття, але не запускайте автовакуум постійно
Найважливіші налаштування:
Поріг допомагає запобігти занадто частому запуску процесу очищення для невеликих столів.
Налаштування за замовчуванням працюють нормально, якщо у вас дуже великі таблиці. Простіше кажучи, якщо у вас є стіл, який займає 100 Гб, ви збираєтесь 20 Гб сміття, перш ніж буде запущена автовакуум. Таким чином, я зазвичай рекомендую встановити низький коефіцієнт масштабу. Наскільки низько вам слід визначити для себе. Я використовую 0,05 у своєму поточному проекті
Порогові значення можна також збільшити. У багатьох додатках є кілька таблиць, які часто оновлюються, а 50 кортежів не так вже й багато. Підвищення того, що до 1000, не повинно спричинити жодних проблем, але, звичайно, слід враховувати власну справу
Ви також можете налаштувати автовакуум і мати різні налаштування для деяких своїх таблиць
ALTER TABLE your_table SET (autovacuum_vacuum_scale_factor = 0.05);Якщо ви налаштуєте scale_factor та порогові значення, вам слід добре. Ви також можете збільшити autovacuum_vacuum_cost_limit, що за замовчуванням дорівнює vacuum_cost_limit200, яке встановлено в 200. Це дуже важлива особливість вакууму, яка не дозволяє йому з'їдати всі ресурси та дозволяє вашій програмі працювати з даними навіть під час процесу вакуумування. , але значення за замовчуванням занадто низьке. Підвищення його до 1000 не повинно призвести до значних затримок, але дозволить вакуумному процесу закінчитися набагато швидше
Звичайно, можна також запускати вакуум вручну. У найпростішому випадку, ви можете мати просту роботу з кроном, яка здійснюватиме повне очищення щовечора, коли до вашої БД не часто звертаються.
Сподіваюся, що це допомагає!