Гость
Войти | Профиль | Очистить
Действия ...
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Параллельное создание большого количества PK и FK / 25 сообщений из 44, страница 1 из 2
  1  все
20.01.2019, 06:21
    #39761976
sysdba22
sysdba22
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
Добрый день,

Предстоит апгрейд больших бд, где не обойтись без пересоздания первичных и внешних ключей (переход с 32 битных ключей на 64 бита).

Хочу создать утилиту, которая скинет структуру бд в спец таблицы. Затем удалит констрэйнты, проведет операции с бд и восстановит PK и FK.

Вопрос, собственно, такой:

Я планирую восстановление делать в параллельных конектах, одновременно.

Даст ли это прирост производительности? ( уменьшение времени по сравнению с gbak)

Безопасно ли это с т.зр. внутренней работы сервера фб? Т.е. не приведет ли к повреждению бд.

На сервере 40 физических ядер и 512 гб озу. База 200 Гб. Кэш выставляется в размер базы. Страница 8192 байт.

Сервер: фб 3.0.4.

Я планирую использовать 20-30 параллельных конектов при восстановлении.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.01.2019, 11:56
    #39761993
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
sysdba22Безопасно ли это с т.зр. внутренней работы сервера фб?

да

sysdba22Даст ли это прирост производительности?

возможно.

sysdba22Я планирую использовать 20-30 параллельных конектов при восстановлении.

вот здесь надо аккуратней.
При создании индексов создаются файлы сортировки, которые могут быть очень большими, это надо учитывать при планировании свободного пространства.
Создавать 30 индексов параллельно ИХМО перебор. Можно уже упереться в IO а не ядра.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.01.2019, 12:37
    #39762005
sysdba22
sysdba22
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
Я настраиваю файреберду под буфер сортировки 256 Гб памяти. Еще 200 Гб под кэш БД. Ну, и остаток под ОС, процессы и т.п.

Т.е. по идее даже 30 одновременных индексов это где-то по 8 Гб в буфере сортировки в оперативной памяти. Должно хватить, чтобы не валилось на диск.

Или я не прав?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.01.2019, 12:45
    #39762009
sysdba22
sysdba22
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
т.е. идея такая, что все данные находятся в оперативной памяти и вся сортировка идет в оперативной памяти, да еще и параллельно. Только полученный итог скидывается на диск. Но там, для этого мощная SSD система от Intel га прямом подключении к PCI Express с бешенной производительностью.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.01.2019, 13:50
    #39762027
Dimitry Sibiryakov
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
sysdba22т.е. идея такая, что все данные находятся в оперативной памяти и вся сортировка идет в
оперативной памяти

то есть база у тебя игрушечная и на её быстродействие тебе наплевать. Делай что хочешь, о
результатах не забудь написать.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.01.2019, 13:56
    #39762032
YuRock
YuRock
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
sysdba22База 200 ГбЭто небольшая база.
При эксклюзивном доступе (для обновления) можно выполнить все операции в последовательном порядке за несколько минут, мне кажется.
Изобретать велосипед для одноразового обновления, чтоб выиграть (возможно) пару минут как-то странно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.01.2019, 14:04
    #39762041
kdv
kdv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
sysdba22Т.е. по идее даже 30 одновременных индексов это где-то по 8 Гб в буфере сортировки в оперативной памяти
во-первых, даже в InterBase параллельно рекомендуют создавать столько индексов, сколько на сервере ядер минус 1.
8 ядер - 7 потоков, и т.д.

во-вторых, если ты выделяешь N гиг под сортировку, то никакого "равенства" для 30ти сортировок там не будет. Памяти под сортировку (построение) конкретного индекса надо будет столько, сколько столбцов и записей индексируется. И если один индекс сожрет половину памяти под сортировки, то на остальные индексы останется ... вторая половина :-)

Я напомню, для создания индекса в базе tpc-c, который в базе занимал 29 гиг, потребовался файл сортировки 182 гига.
В принципе, для индексов по int/bigint можно посчитать объем сортировки, зная размер таблицы.
sysdba22 База 200 Гб. Кэш выставляется в размер базы. Страница 8192 байт
по идее, для такой базы надо бы страницу 16к.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.01.2019, 22:06
    #39762155
sysdba22
sysdba22
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
1) ядер там 48
2) с размером буфера под сортировку индекса учту.
3) в том то всё и дело, что проовернуть цикл бэкап рестор там проблема из за занимаемого времени. а из вашего опыта насколько может подрасти производительность?

если есть хотя бы приблизительная формула вычисления объёма буфера для создания индекса, если известно количество записей и тип данных, то буду признателен.

как я понимаю, размер будет отличаться в зависимости от того идет сортировка в озу или на диске.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.01.2019, 01:11
    #39762179
kdv
kdv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
sysdba22а из вашего опыта насколько может подрасти производительность?
производительность рестора? Рестор состоит из наливки данных и создания индексов. Про это было тут:
http://www.ibase.ru/restorespeed/
создание индексов может занимать половину времени рестора. при параллельном создании индексов можно ускориться ... допустим впополам. А значит итогово где-то на четверть. Но такого опыта нет.
sysdba22если есть хотя бы приблизительная формула вычисления объёма буфера для создания индекса
да блин, отсортируй таблицу по какому-нибудь столбцу, получишь конкретный результат.
select field from table order by 1
так, чтобы индекс не использовался (если он есть по столбцу). И будет файл сортировки в temp и его размер.
sysdba22как я понимаю, размер будет отличаться в зависимости от того идет сортировка в озу или на диске.
в смысле? размер сортировки равен размеру сортировки в памяти плюс размер файла сортировки. Ни по каким другим причинам "размер" отличаться не будет.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.01.2019, 05:28
    #39762193
sysdba22
sysdba22
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
я где то читал, что механизм сортировки в фб работает по разному для файла и для сортировки в памяти. я имею ввиду внутренний буфер фб под сортировку, а не кэш файловой системы, который дает операционная система. поэтому и спрашиваю про размер.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.01.2019, 08:21
    #39762210
Vlad F
Vlad F
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
sysdba22,

Думаю, было бы крайне полезно для сообщества выполнить означенные манипуляции сравнительно, в последовательном и параллельном режимах. Но это при наличии такой технической возможности (ну и интереса), естественно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.01.2019, 09:38
    #39762227
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
sysdba22я где то читал, что механизм сортировки в фб работает по разному для файла и для сортировки в памяти. я имею ввиду внутренний буфер фб под сортировку, а не кэш файловой системы, который дает операционная система. поэтому и спрашиваю про размер.

Там примерно так, сначала сортируются маленькие порции QuickSort это в памяти, потом эти отсортированные порции сливаются многопроходным алгоритмом сортировки слиянием, если данные помещаются в память, то в памяти, если нет то образуется файлы сортировок. Их суммарный объём довольно сложно посчитать. Очень приближённо размер распакованных полей + RDB$KEY для всех таблиц, но наверное есть какой-то ещё оверхед.
Файлы сортировок которые образуются на диски помечены как временные, поэтому сама ОСь, по факту тоже может держать их в памяти без сброса на диск.

Подробнее об это может Влад рассказать.
Ещё кое что есть тут https://www.ibase.ru/news/materialy-vebinara-effektivnoe-ispol-zovanie-pamati-subd-firebird/
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.01.2019, 09:55
    #39762233
sysdba22
sysdba22
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
а вот размер этих "маленьких порций" нельзя увеличить? а то памяти хватает, чтобы весь индекс в озу за раз отсортировать. очень бы мне кажется это помогло.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.01.2019, 12:08
    #39762289
kdv
kdv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
sysdba22,

ничего там не надо увеличивать. Если сортировка влазит в память, то она остается в памяти. Если нет - идет в файл сортировки, причем, к примеру, если SortMemSize 2 гига, а сортируется 4 гига, то 2 гига сортировки будут в памяти, остальное пойдет во временный файл сортировки.
Сам файл сортировки временный, поэтому его операционная система старается разместить в памяти, на винде это видно как файл нулевого размера, реальный размер видно только если свойства файла посмотреть.
И, если у ОС не хватает памяти, то тогда временный файл выгружается на диск.

По моим тестам, если у ОС хватает памяти для временного файла, нет никакой разницы по времени между сортировкой в памяти ФБ и во временном файле.
http://www.ibase.ru/files/articles/performance/Firebird Optimizer - ORDER vs SORT.pdf
страница 9.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.01.2019, 12:17
    #39762294
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
sysdba22,

я же вроде написал, что слияния тоже в памяти могут происходить. Кроме того как и сказал Дмитрий временные файлы зачастую тоже в памяти находятся.

Реально там есть проблема только с совсем гигантскими индексами, которая вылезла на террабайтной базе, когда памяти не хватало, и которая решалась только спецбилдом. Там вроде надо было размер и количество групп менять. Насколько я знаю она до сих пор не решена. Там вроде предлагалась их динамически менять от объёма сортировки. Кстати насколько я помню из обсуждения в ряде случаев можно было ускорить совсем маленькие сортировки.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.01.2019, 12:33
    #39762306
sysdba22
sysdba22
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
а эта проблема планируется к устранению?

потому что мы тоже будем идти к террабайтной бд.

не хотелось бы с ней столкнуться.

она есть в багтреккере, чтобы посмотреть на ее описание?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.01.2019, 12:39
    #39762307
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
sysdba22,

всё есть тут и ссылки на трекер тоже https://www.ibase.ru/fb1tbtech/
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.01.2019, 12:40
    #39762308
kdv
kdv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
sysdba22она есть в багтреккере, чтобы посмотреть на ее описание?
Конечно есть
http://www.ibase.ru/fb1tbtech/

http://tracker.firebirdsql.org/browse/CORE-2525
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.01.2019, 13:20
    #39762330
sysdba22
sysdba22
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
насколько я вижу в описании, там проблема в выделении памяти и она проявилась на 32 бит файреберде и на 32 бит винде. можно ли сделать предположение, что ее не будет на 64 бит ос и фб?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.01.2019, 13:31
    #39762337
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
sysdba22,

нет, там проблема гораздо глубже. Читай комменты в тикете внимательней
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.01.2019, 13:38
    #39762341
kdv
kdv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
sysdba22,

при чем тут 32 бита....
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.01.2019, 13:38
    #39762343
Dimitry Sibiryakov
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
sysdba22а вот размер этих "маленьких порций" нельзя увеличить?

Можно. Читай firebird.conf на предмет Temp* параметров.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.01.2019, 20:04
    #39762532
dimitr
dimitr
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
Dimitry SibiryakovМожно. Читай firebird.conf на предмет Temp* параметров.
он хочет, чтобы ранов совсем не было. Один единственный буфер в ОЗУ на 100500МБ и квиксорт в нем.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.01.2019, 08:22
    #39762637
Vlad F
Vlad F
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
dimitr,

А это можно, технически, сделать?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.01.2019, 13:54
    #39762815
sysdba22
sysdba22
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Параллельное создание большого количества PK и FK
dimitrон хочет, чтобы ранов совсем не было. Один единственный буфер в ОЗУ на 100500МБ и квиксорт в нем.

только не на 100500, а на 256 Гб пока ))

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

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

одну проблему мы решаем переходом на 64 бит ИД.

остается проблема скорости и роста базы. резать данные категорически не хочется...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Параллельное создание большого количества PK и FK / 25 сообщений из 44, страница 1 из 2
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 574ms
Закрыть
start [/forum/topic.php?fid=40&mobile=1&tid=1560830]:
 0ms
get settings:
 9ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 158ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 66ms
get tp. blocked users:
 2ms
others: 301ms
total:  574ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]