Postgresql 13: Параллельный Вакуум

На днях Амит Капила зафиксировал патч Масахико Савады, позволяющий выполнять очистку параллельно.

Сама таблица по-прежнему очищается одним (главным) процессом, но для очистки индексов теперь можно запускать фоновые рабочие процессы, по одному для каждого индекса.

В ручном режиме это позволяет ускорить очистку больших таблиц с несколькими индексами; Автоматическая очистка пока не использует эту функцию.

Ссылки по теме:
Как известен Процесс уборки стола состоит из нескольких этапов.

Сначала таблица сканируется и в памяти собираются ссылки на ненужные («мертвые») версии строк.

Память ограничена параметром Maintenance_work_mem , поэтому все ссылки могут не поместиться сразу.

Затем последовательно (как это было раньше) просматриваются все индексы и из них очищаются указатели на мертвые версии найденных строк.

Затем уже просканированная часть таблицы сканируется повторно и из нее удаляются мертвые версии строк.

Если не удалось обработать все мертвые версии строк за один раз, то память очищается и весь процесс повторяется снова с того места, на котором мы остановились в прошлый раз.

Вся эта схема осталась без изменений, но теперь индексы можно очищать параллельно.

Для этого главный процесс запускает несколько рабочих процессов, которые анализируют существующие индексы и обрабатывают их.

Один индекс обрабатывается только одним процессом.

После очистки всех индексов рабочие процессы завершаются, и главный переходит к следующему этапу.

Для примера возьмем полетную таблицу

  
  
  
  
  
  
  
  
  
   

ticket_flights

демобазы .

На нем есть один индекс, но можно создать еще парочку.



demo=# CREATE index on ticket_flights (fare_conditions); demo=# CREATE index on ticket_flights (amount);

В параллельной обработке участвуют только те индексы, размер которых превышает значение параметра.

min_parallel_index_scan_size .

Наши индексы подходят:

demo=# SHOW min_parallel_index_scan_size;



min_parallel_index_scan_size ------------------------------ 512kB (1 row)



demo=# SELECT pg_size_pretty(pg_relation_size(indexname::regclass)) FROM pg_indexes WHERE tablename = 'ticket_flights';



pg_size_pretty ---------------- 325 MB 187 MB 180 MB (3 rows)

Давайте обновим половину строк, чтобы очистка заработала:

demo=# UPDATE ticket_flights SET amount = amount + 1 WHERE random() > 0.5;



UPDATE 4194262

Идти.



demo=# VACUUM VERBOSE ticket_flights;



INFO: vacuuming "bookings.ticket_flights" INFO: launched 2 parallel vacuum workers for index vacuuming (planned: 2) INFO: scanned index "ticket_flights_fare_conditions_idx" to remove 4194262 row versions by parallel vacuum worker DETAIL: CPU: user: 1.84 s, system: 0.41 s, elapsed: 11.82 s INFO: scanned index "ticket_flights_amount_idx" to remove 4194262 row versions by parallel vacuum worker DETAIL: CPU: user: 2.31 s, system: 0.44 s, elapsed: 12.95 s INFO: scanned index "ticket_flights_pkey" to remove 4194262 row versions .

INFO: "ticket_flights": found 4194262 removable, 8391852 nonremovable row versions in 104885 out of 104885 pages DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 630 There were 0 unused item identifiers. Skipped 0 pages due to buffer pins, 0 frozen pages. 0 pages are entirely empty. CPU: user: 9.91 s, system: 4.40 s, elapsed: 121.40 s. VACUUM

Здесь видно, что ведущий процесс запустил двух воркеров, а один индекс забрал себе.

Количество рабочих процессов можно указать явно (в любом случае оно, конечно, не будет превышать max_parallel_maintenance_workers , что не превышает max_worker_processes ).

Явное указание можно использовать, в частности, для отключения параллелизма:

demo=# VACUUM (PARALLEL 0, VERBOSE) ticket_flights;

Надеюсь, что эта тема получит дальнейшее развитие.

Таблицу можно было сканировать параллельно несколькими процессами (это было в исходном патче Савады, но не было включено в финальную версию), и каждый индекс также мог очищаться параллельно.

Обязательно научите автоматическую очистку использовать параллелизм.

P.S. Кстати, нам нужен кто-то в нашу образовательную команду.

Чтобы он мог и любил понимать и объяснять.

Мы точно знаем, что он где-то есть, но пока он скрывается.

Теги: #postgresql #sql #параллелизм #вакуум #вакуум
Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.