А вот бывалоча, RN сразу на русском языке публиковали.
И так ни шиша непонятно, а тут ещё и на ангельском.

Скажите кто в теме. При ресторе распараллеливание создания индексов идет в рамках одного индекса или нескольких? Т.е. работает ли ситуация, когда индексы (при ресторе) создаются параллельно, например, 10 потоков создают одновременно 10 индексов. Или же при восстановлении каждого индекса создается 10 потоков и пока работа не будет завершена к восстановлению следующего индекса не переходит?

Второе

Как понимаю, сейчас выигрыш рестора есть на базах с мега-индексами на мега-таблицах. Если ситуация обратная - много всяких разных таблиц и индексов, то выигрыша уже не наблюдается. Ну это мое наблюдение. Если у кого другие данные - делитесь, было бы интересно...

Как понимаю, сейчас выигрыш рестора есть на базах с мега-индексами на мега-таблицах. Если ситуация обратная - много всяких разных таблиц и индексов, то выигрыша уже не наблюдается. Ну это мое наблюдение. Если у кого другие данные - делитесь, было бы интересно...

Кратко результат ParallelWorkers эффективен при 3-4 потоках, при большом количестве потоков производительность падает.

neozx1984

Кратко результат ParallelWorkers эффективен при 3-4 потоках, при большом количестве потоков производительность падает.

И это, конечно же, совершенно не зависит от кол-ва ядер и св-в диска.

МорскойДесант писал(а) Mon, 02 October 2023 12:05

А вот бывалоча, RN сразу на русском языке публиковали.
И так ни шиша непонятно, а тут ещё и на ангельском.

дык LangRef есть, от 21.09.2023.
---

https://firebirdsql.org/en/firebird-rdbms/ - ?
В смысле - "где есть"?

Вай... а я уже и забыл про Айбэйз.

Тут сравнение двух подходов

Когда читается таблица с данными, её записи разделяются между потоками. Каждый поток читает записи со страниц данных, находящихся в выделенной ему POINTER PAGE. Обработав их, берёт следующую необработанную POINTER PAGE.

neozx1984 писал(а) Thu, 05 October 2023 08:36

Тут сравнение двух подходов

Там, помимо всего прочего, есть интересное утверждение:
Цитата:

Когда читается таблица с данными, её записи разделяются между потоками. Каждый поток читает записи со страниц данных, находящихся в выделенной ему POINTER PAGE. Обработав их, берёт следующую необработанную POINTER PAGE.

КАК, Холмс? gbak не имеет доступа на такой уровень. Или это работает для любого запроса, идущего по таблице натуралом?

SD писал(а) Tue, 10 October 2023 13:54

neozx1984 писал(а) Thu, 05 October 2023 08:36

Тут сравнение двух подходов

Там, помимо всего прочего, есть интересное утверждение:
Цитата:

Когда читается таблица с данными, её записи разделяются между потоками. Каждый поток читает записи со страниц данных, находящихся в выделенной ему POINTER PAGE. Обработав их, берёт следующую необработанную POINTER PAGE.

КАК, Холмс? gbak не имеет доступа на такой уровень. Или это работает для любого запроса, идущего по таблице натуралом?

MAKE_DBKEY

ggreggory писал(а) Mon, 02 October 2023 21:38

Как понимаю, сейчас выигрыш рестора есть на базах с мега-индексами на мега-таблицах. Если ситуация обратная - много всяких разных таблиц и индексов, то выигрыша уже не наблюдается. Ну это мое наблюдение. Если у кого другие данные - делитесь, было бы интересно...

Тут сравнение двух подходов - многопоточной активации индекса (ParallelWorkers) и многопоточной активации индексов (в разных коннектах). Тестировалось на РедБазе 3.0, но в Firebird 5 картина будет примерна такая же. Кратко результат ParallelWorkers эффективен при 3-4 потоках, при большом количестве потоков производительность падает.

• в одном потоке - 36 секунд;
  
• -par 4 - 32 секунды.
  

• в одном потоке - 35 секунд;
  
• -par 4 - 18 секунд.
  

При восстановлении параллельная обработка реализована только при построении индексов.

gbak -c "d:\fbdata\5.0\mydb.fbk" "c:\fbdata\5.0\mydb.fdb" -se localhost/3055:service_mgr -user sysdba -pas masterkey -par 4 -v -stat td -Y "d:\fbdata\5.0\restore-par-4.log"

hvlad,

я при тестировании заметил что если бекап идёт с переключателем -zip, то параллельные потоки уже мало влияют на картину. Видимо на сжатии данных какая-то сериализация есть
...
Вопрос с эти можно что-то сделать? Если нет то неплохо бы отразить в документации.

Как будет время, глянь пожалуйста.

sim_84 писал(а) Sun, 15 October 2023 13:07

Как будет время, глянь пожалуйста.

Это не сложно. И не долго.
Вот что я вижу для БД TPCC размером 8.75GB. БД и бекап на одном и том же быстром NVMe SSD.

par 1, no zip :  80 sec
par 1, zip    : 195 sec
par 4, no zip :  21 sec
par 4, zip    : 198 sec

Очевидно, проблема в zip. Но дело не в сериализации, а в том, что он полностью занимает то ядро,
которое выполняет запись в файл - даже когда мы читаем БД в один поток. Т.е. алгоритм не справляется
с нагрузкой и работает сильно медленнее чем данные пишутся на диск. С более медленным диском картина
будет другой ("лучше").

Сжимать в не несколько потоком сам zip не умеет, насколько я знаю. Мы не можем сжимать каждый прочитанный
из БД блок в отдельном потоке, т.к. потом эту кучку отдельно сжатых блоков никто не распакует. Чтобы этого
достичь, нужно менять формат файла бекапа.

это я так понимаю уже через перенаправление потока? Встроен только zip же

ggreggory,

Цитата:

При восстановлении параллельная обработка реализована только при построении индексов.

Вот это для Firebird 5.0 уже не правда. Заливка данных в таблицу тоже параллелиться. В этом легко убедится

gbak -c "d:\fbdata\5.0\mydb.fbk" "c:\fbdata\5.0\mydb.fdb" -se localhost/3055:service_mgr -user sysdba -pas masterkey -par 4 -v -stat td -Y "d:\fbdata\5.0\restore-par-4.log"

Просто в лог посмотри, там видно будет.

Правда plume на Release Candidate сыпется с ошибками. Сравнить создание индексов двумя разными способами не удалось.

ggreggory писал(а) Thu, 19 October 2023 21:55

Правда plume на Release Candidate сыпется с ошибками. Сравнить создание индексов двумя разными способами не удалось.

Что пишет?

Сначала "Warning trouble on index ...", потом "invalid database handle (no active connection)"

neozx1984,

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

MaxStatementCacheSize = 0

Дело в том, что любой DDL сбрасывает этот кеш. А здесь одни сплошные DDL операторы.
В трекере уже был тикет с багом по поводу кеша подготовленных запросов, вроде Влад его пофиксил, но не факт что до конца.

Кроме того я не уверен, что plume выбирает индексы корректно для одновременной активации.
Смотри может попасться 4 мелких индекса, а может 4 больших. А большие начнут жрать temp одновременно, кроме того если
ещё и многопоточная активация индекса включена, то эти 4 больших индекса начнут совсем другое кол-во потоков задействовать, но не больше, чем MaxParallelWorkers.

На БД employee многопоточная активация на фиг не упала

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

MaxStatementCacheSize = 0

Поставил свежий снапшот WI-V5.0.0.1249 - та же фигня.

Но на 3.0.11 на той же базе plume нормально работает. Наверное, какие-то фиксы 3-ей версии в 5-ую еще не перенесены...