SQLRU.net
Разработка приложений баз данных

Начало » Использование СУБД » Firebird, HQbird, InterBase » Параллельный restore - индексы (больше лучше)
Параллельный restore - индексы [сообщение #4271] Mon, 29 January 2024 14:51 Переход к следующему сообщению
shalamyansky в настоящее время не в онлайне  shalamyansky
Сообщений: 150
Зарегистрирован: August 2022
Senior Member
Firebird 5.0, Windows Server 2019.

Запустил параллельный restore на более, чем терабайтной базе. Наблюдаю за процессом со стороны посредством ProcessExplorer. Во время набивки таблиц все идет по заявленному плану - 8 сильно нагруженных потоков коллективно трудятся, картина радует масштабностью стройки. А вот когда перешли к созданию индексов, коих неимоверное количество, дело застопорилось - остался только один рабочий поток.

Я догадываюсь, что параллельное построение индекса - задача трудная, если вообще возможная. Но почему бы не запустить параллельно построение разных индексов, тем более на разных таблицах? Чего процессорам простаивать?

Это так, на уровне диванного бреда. Спасибо за продукт и его развитие!

[Обновления: Mon, 29 January 2024 14:53]

Известить модератора

Re: Параллельный restore - индексы [сообщение #4272 является ответом на сообщение #4271] Mon, 29 January 2024 14:53 Переход к предыдущему сообщениюПереход к следующему сообщению
hvlad в настоящее время в онлайне  hvlad
Сообщений: 358
Зарегистрирован: August 2022
Senior Member
MaxParallelWorkers в конфиге увеличен ?
Варнинги в начале рестора были ?
Re: Параллельный restore - индексы [сообщение #4274 является ответом на сообщение #4272] Mon, 29 January 2024 15:23 Переход к предыдущему сообщениюПереход к следующему сообщению
SD в настоящее время в онлайне  SD
Сообщений: 411
Зарегистрирован: August 2022
Senior Member
Разные индексы на разных таблицах это всего лишь сделает диск узким местом и переполнит временный каталог. А вот одновременное построение нескольких индексов одной таблицы за один проход я обдумываю.
Re: Параллельный restore - индексы [сообщение #4275 является ответом на сообщение #4272] Mon, 29 January 2024 15:23 Переход к предыдущему сообщениюПереход к следующему сообщению
shalamyansky в настоящее время не в онлайне  shalamyansky
Сообщений: 150
Зарегистрирован: August 2022
Senior Member
MaxParallelWorkers и ParallelWorkers в конфиге умолчальные (=1?). Число потоков задал командной строкой
gbak ... -parallel 8 se localhost:service_mgr
Ворнингов не было, или я их просмотрел - в момент улетели за край экрана консоли.

А что, индексы должны были тоже создаваться параллельно, и это я что-то не подкрутил? Надежда затеплилась.
Re: Параллельный restore - индексы [сообщение #4276 является ответом на сообщение #4275] Mon, 29 January 2024 15:47 Переход к предыдущему сообщениюПереход к следующему сообщению
hvlad в настоящее время в онлайне  hvlad
Сообщений: 358
Зарегистрирован: August 2022
Senior Member
shalamyansky писал(а) Mon, 29 January 2024 14:23
MaxParallelWorkers и ParallelWorkers в конфиге умолчальные (=1?). Число потоков задал командной строкой
gbak ... -parallel 8 se localhost:service_mgr
Ворнингов не было, или я их просмотрел - в момент улетели за край экрана консоли.

А что, индексы должны были тоже создаваться параллельно, и это я что-то не подкрутил? Надежда затеплилась.
Ключ -parallel для рестора имеет две роли:
1. указывает сколько потоков\коннектов создавать gbak для заливки данных
2. передаётся движку (engine) для указания кол-ва рабочих потоков\коннектов для создания индексов (индексы создаёт не gbak, "сюрприз")

Нужно понимать простую вещь: движок - не gbak, движок читает firebird.conf и соблюдает правила, заданные параметрами,
в частности MaxParallelWorkers и ParallelWorkers. Т.е. значение ключа -parallel проверяется движком (не не gbak'ом!)
на соответствие ограничениям заданным ДБА.

Если значение ключа -parallel (переданное gbak'ом в движок при создании новой БД) превышает значение MaxParallelWorkers,
то движок использует значение MaxParallelWorkers и выдаёт соотв. warning.

Изначально, кстати, на этом месте была ошибка и рестор прерывался. Но некоторые этому сильно сопротивлялись и ошибку
пришлось превратить в предупреждение - со всеми вытекающими последствиями.

PS всё это уже неоднократно объяснялось и более-менее описано в документации, возможно не в одном месте... но кто же
может заранее предусмотреть что именно вот это вот окажется настолько сложным для понимания...
Re: Параллельный restore - индексы [сообщение #4277 является ответом на сообщение #4274] Mon, 29 January 2024 15:51 Переход к предыдущему сообщениюПереход к следующему сообщению
hvlad в настоящее время в онлайне  hvlad
Сообщений: 358
Зарегистрирован: August 2022
Senior Member
SD писал(а) Mon, 29 January 2024 14:23
Разные индексы на разных таблицах это всего лишь сделает диск узким местом и переполнит временный каталог. А вот одновременное построение нескольких индексов одной таблицы за один проход я обдумываю.
Это, конечно, никак не повлияет на использование диска, да и временный каталог расширит до невиданной ширины.
Это я не про принципиальную возможность, если что. Это я про уровень аргументации. Ну да ладно, привык уже.
Re: Параллельный restore - индексы [сообщение #4278 является ответом на сообщение #4276] Mon, 29 January 2024 18:23 Переход к предыдущему сообщениюПереход к следующему сообщению
shalamyansky в настоящее время не в онлайне  shalamyansky
Сообщений: 150
Зарегистрирован: August 2022
Senior Member
hvlad писал(а) Mon, 29 January 2024 15:47
Ключ -parallel для рестора имеет две роли:
1. указывает сколько потоков\коннектов создавать gbak для заливки данных
2. передаётся движку (engine) для указания кол-ва рабочих потоков\коннектов для создания индексов (индексы создаёт не gbak, "сюрприз")
Красиво, но уж больно мудрено получается. Удержать это в памяти нет никакой возможности. Ключ -parallel действует на заливку таблиц, и MaxParallelWorkers ему по барабану, но для параллельного создания индексов надо еще идти в firebird.conf и править там. На практике быстро наполнять таблицы и потом долго ждать индексов смысла нет, поэтому резюме - для параллельной работы restore задайте ключ и обязательно настройте конфиг.

Было бы приятно узнать об этом от gbak -help. Но от самого разработчика еще приятнее, конечно. Спасибо!
Re: Параллельный restore - индексы [сообщение #4281 является ответом на сообщение #4278] Tue, 30 January 2024 13:00 Переход к предыдущему сообщениюПереход к следующему сообщению
basid в настоящее время не в онлайне  basid
Сообщений: 162
Зарегистрирован: June 2022
Географическое положение: Asia/Irkutsk
Senior Member
firebird.conf
# ============================
# Settings for parallel work
# ============================

# ----------------------------
# Limits the total number of parallel workers that can be created within a
# single Firebird process for each attached database.
# Workers are accounted for each attached database independently.
#
# Valid values are from 1 (no parallelism) to 64. All other values
# silently ignored and default value of 1 is used.
# Per-process.
#
# Type: integer
#
#MaxParallelWorkers = 1

# ----------------------------
# Default number of parallel workers for a single connection. For more details
# see doc/README.parallel_features.
#
# Valid values are from 1 (no parallelism) to MaxParallelWorkers (above).
# Values less than 1 are silently ignored and default value of 1 is used.
# Per-process.
#
# Type: integer
#
#ParallelWorkers = 1
Внезапно.
Re: Параллельный restore - индексы [сообщение #4288 является ответом на сообщение #4281] Tue, 30 January 2024 13:52 Переход к предыдущему сообщениюПереход к следующему сообщению
sim_84 в настоящее время не в онлайне  sim_84
Сообщений: 330
Зарегистрирован: June 2022
Senior Member
Для ParallelWorkers значение логично, ибо оно используется движком (создание индексов, автосвип). Слишком большое значение может навредить.
А вот MaxParallelWorkers это скорее админ себя от неприятностей огорождает, чтобы некоторые нерадивые товарищи не забрали все ресурсы себе.

Не вижу ничего страшного, ибо параллелизм обычно на больших БД нужен, а там есть админ, который в состоянии конфиг поправить.
Re: Параллельный restore - индексы [сообщение #4307 является ответом на сообщение #4271] Wed, 31 January 2024 17:50 Переход к предыдущему сообщению
ggreggory в настоящее время не в онлайне  ggreggory
Сообщений: 76
Зарегистрирован: July 2022
Member
shalamyansky писал(а) Mon, 29 January 2024 14:51

Я догадываюсь, что параллельное построение индекса - задача трудная, если вообще возможная. Но почему бы не запустить параллельно построение разных индексов, тем более на разных таблицах? Чего процессорам простаивать?

Попробуйте ресторить без создания индексов, а потом запускать plume. Я пробовал - профит есть.
Предыдущая тема: RDB$DESCRIPTION
Следующая тема: Новые возможности Firebird 5.0: Часть 4, параллельные возможности
Переход к форуму:
  


Текущее время: Mon Nov 25 17:58:10 GMT+3 2024

Общее время, затраченное на создание страницы: 0.00615 секунд