Начало » Использование СУБД » Firebird, HQbird, InterBase » Параллельный restore - индексы (больше лучше)
Параллельный restore - индексы [сообщение #4271] |
Mon, 29 January 2024 14:51 |
shalamyansky
Сообщений: 150 Зарегистрирован: August 2022
|
Senior Member |
|
|
Firebird 5.0, Windows Server 2019.
Запустил параллельный restore на более, чем терабайтной базе. Наблюдаю за процессом со стороны посредством ProcessExplorer. Во время набивки таблиц все идет по заявленному плану - 8 сильно нагруженных потоков коллективно трудятся, картина радует масштабностью стройки. А вот когда перешли к созданию индексов, коих неимоверное количество, дело застопорилось - остался только один рабочий поток.
Я догадываюсь, что параллельное построение индекса - задача трудная, если вообще возможная. Но почему бы не запустить параллельно построение разных индексов, тем более на разных таблицах? Чего процессорам простаивать?
Это так, на уровне диванного бреда. Спасибо за продукт и его развитие!
[Обновления: Mon, 29 January 2024 14:53] Известить модератора
|
|
|
|
|
|
Re: Параллельный restore - индексы [сообщение #4276 является ответом на сообщение #4275] |
Mon, 29 January 2024 15:47 |
hvlad
Сообщений: 358 Зарегистрирован: August 2022
|
Senior Member |
|
|
shalamyansky писал(а) Mon, 29 January 2024 14:23MaxParallelWorkers и 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 - индексы [сообщение #4307 является ответом на сообщение #4271] |
Wed, 31 January 2024 17:50 |
ggreggory
Сообщений: 76 Зарегистрирован: July 2022
|
Member |
|
|
shalamyansky писал(а) Mon, 29 January 2024 14:51
Я догадываюсь, что параллельное построение индекса - задача трудная, если вообще возможная. Но почему бы не запустить параллельно построение разных индексов, тем более на разных таблицах? Чего процессорам простаивать?
Попробуйте ресторить без создания индексов, а потом запускать plume. Я пробовал - профит есть.
|
|
|
Переход к форуму:
Текущее время: Fri Nov 22 11:42:33 GMT+3 2024
Общее время, затраченное на создание страницы: 0.00929 секунд
|