Скільки часу займе операція вакуум / автовакуум?

Я керую великою базою (кілька сотень концертів), що містить таблиці з різними ролями, деякі з них містять мільйони записів. Деякі таблиці отримують лише велику кількість вставок та видалень, деякі інші кілька вставок та велику кількість оновлень.

База даних працює на PostgreSQL 8.4 в системі Debian 6.0 amd64 з 16 гігабайтами оперативної пам’яті.

Питання полягає в тому, що процес автовакууму на столі займає дуже багато часу (днів). Я хочу вміти приблизно сказати, скільки часу займе певна команда вакууму, щоб можна було вирішити, скасувати її чи ні. Крім того, якби був показник прогресу для вакуумних операцій після постгресу, було б дуже корисно.

Редагувати:

Я не шукаю кулезахисного рішення. Достатньо лише грубої підказки щодо кількості мертвих кортежів або необхідних байтів вводу / виводу. Це насправді прикро не мати поняття, коли VACUUMзакінчуватимеш.

Я бачив, що pg_catalog.pg_stat_all_tablesє стовпчик для кількості мертвих кортежів. Отож, можливо, мати оцінку, навіть якщо це означає, що треба до ANALYZEтаблиці. З іншого боку, autovacuum_vacuum_thresholdі autovacuum_vacuum_scale_factorнастройки в поодинці довести , що Postgres сам знає що - то про кількість змін на таблицях і , ймовірно , ставить його в руках DBA теж.

Я не впевнений, який запит потрібно запустити, бо коли я запускаю VACUUM VERBOSE, я бачу, що не тільки таблиці, але й індекси на них теж обробляються.

У моєму PostgreSQL (8.3) я використовую цей трюк:

1. Я отримую розмір диска таблиці за допомогою pg_total_relation_size()- це включає в себе індекси та розмір TOAST, що є VACUUMпроцесами. Це дає мені уявлення про те, скільки байтів VACUUMмає прочитати.
2. Я біжу VACUUMна стіл.
3. Я знаходжу pidв VACUUMпроцесі (в pg_catalog.pg_stat_activity).
4. У оболонці Linux я запускаю while true; do cat /proc/123/io | grep read_bytes; sleep 60; done(де 123pid) - це показує мені байти, прочитані процесом з диска до цих пір.

Це дає мені приблизне уявлення про те, скільки байтів обробляються (читаються) щохвилини VACUUM. Я припускаю, що VACUUMповинен прочитати всю таблицю (включаючи індекси та TOAST), розмір диска якої я знаю з кроку 1.

Я припускаю, що таблиця досить велика, так що більшість її сторінок повинні читатися з диска (їх немає в спільній пам'яті Postgres), тому read_bytesполе є досить хорошим, щоб використовувати його як лічильник прогресу.

Кожного разу, коли я робив це, загальна кількість байтів, прочитаних процесом, становила не більше 5% від загального розміру співвідношення, тому я думаю, що цей підхід може бути досить хорошим для вас.

Це дуже важко визначити. Ви можете налаштувати автовакуумування на більш агресивне або легке . Але коли встановлено м'який стан і воно відстає, а базове навантаження вводу / виводу занадто велике, може статися так, що він ніколи не досягає належного вакуумованого стану - тоді ви бачите процес, який працює і працює і працює. Крім того, пізніші видання PostreSQL мають значно покращені можливості автовакууму, цього лише може бути достатньо для переходу до однієї з них (бажано 9.2 як останньої).

Рядок прогресу здається гарною ідеєю, але я думаю, що це не так просто осмислено реалізувати. Оскільки у вас постійне навантаження на ваші таблиці, цілком можливо, що прогрес, очевидно, йде назад (я маю на увазі, що кількість / відсоток мертвих рядків збільшується, а не зменшується) - то який висновок ви робите?

У нашому виробництві одна з найбільших таблиць мала цей журнал:

pages: 0 removed, 1801722 remain
tuples: 238912 removed, 42582083 remain, 1396 are dead but not yet removable
buffer usage: 9477565 hits, 3834218 misses, 2220101 dirtied
avg read rate: 2.976 MB/s, avg write rate: 1.723 MB/s
system usage: CPU 68.47s/177.49u sec elapsed 10065.08 sec

Це, безумовно, найгірше споживання ресурсів, усі інші таблиці займають менше 2 с.

Щоб побачити ці типи журналів, слід виконати наступне:

alter system set log_autovacuum_min_duration TO 5; 

(протягом 5 мс), перезавантажте файл конфігурації.

Я вважаю цю публікацію і цією публікацією корисною, але, як уже згадували інші, підрахувати загальний хід вакууму може бути важко, оскільки процес включає кілька окремих операцій.

Цей запит я використовую для контролю за ходом сканування вакуумного столу, який, як видається, є основною роботою:

SELECT heap_blks_scanned/cast(heap_blks_total as numeric)*100 as heap_blks_percent, progress.*, activity.query
FROM pg_stat_progress_vacuum AS progress
INNER JOIN pg_stat_activity AS activity ON activity.pid = progress.pid;

Однак це не буде включати сканування індексів, яке відбувається згодом і може зайняти стільки ж часу, якщо не більше, якщо у вас є тонна індексів. На жаль, я не можу знайти спосіб моніторингу сканування / вакуумування індексів.