Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4]      все
 Re: ANN: видео о мифе эффективности параллельной вставки  [new]
hvlad
Member

Откуда:
Сообщений: 10765
kdv
я бы добавил, но ты меня этим советом ввел в ступор
Выйди из ступора и добавь пустой триггер :)

kdv
там же написано, что в одноядерном режиме они почти эквивалентны.
Заборы - они такие, там тоже пишут.
А вот мегагерцы - их никто не отменял.

kdv
А вот 128 секунд и 65 секунд - не эквивалентны.
Ну так у вас и условия теста мало в чём совпадают
19 мар 17, 11:06    [20310234]     Ответить | Цитировать Сообщить модератору
 Re: ANN: видео о мифе эффективности параллельной вставки  [new]
Коваленко Дмитрий
Member

Откуда: Липецк
Сообщений: 559
hvlad
для начала добавь триггер :)

Да нет.

Для начала надо заставить восемь экземпляров isql отрабатывать в 4 раза быстрее.

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

Удобно же.

----
0. Тест был написан максимально корректно - в нем даже не учитывается время на инициализацию подключения/транзакции/запроса. Можно было бы исключить время на коммиты и завершение работы потоков, но мне это пришло в голову только сейчас.

И конечно же, каждый поток работает со своим подключением.

На 10 потоках и fb3_ss/cs/sc процессор (с HT) показывает загрузку на половину. То есть, можно считать, что все ядра загружены работой.

1. До RAM-диска там дело не доходит - потому что страничный кэш (3GB) больше чем база данных (600MB).

Собственно, можно и на RAID из HDD выполнить (у меня он, такой RAID, тоже есть) - но смысла в этом уже нет. Потому что ответ на вопрос "про параллельную вставку в одну таблицу" уже получен.

В начале я думал, что в тесте с isql затык связан с дисками. И индексом. Поэтому и применил эту "тяжелую артиллерию".

Результат согласуется с моим другим наблюдением - нагрузочное тестирование IBProvider-а в восемь потоков (10 часов) быстрее в полтора раза чем в четыре потока (15-16 часов). Кстати, как раз на восьми потоках RAM-диск и демонстрирует себя во всей красе.

2. Почему-то не возникает вопрос - почему на одном подключении fb25_ss работает на 25% быстрее чем fb3_ss.

Но вот почему "однопоточная" загрузка через isql работает быстрее чем через два (ДВА, Карл) провайдера (каждый из которых на порядки сложнее чем этот isql) - это мы не понимаем. Или делаем вид, что как не понимаем.

Ну хорошо, я объясню.

Как только isql начнет работать поставщиком данных, реализующим спецификации OLE DB + ADO.NET + сопутствующие требования к таким вещам, цифры выравняются.

3. Можно взять родной ADO.NET провайдер для FB и натянуть мой тест на него (там работы на 10 минут). Этот провайдер без претензий, поэтому работает ощутимо быстрее.

Впрочем, взять что угодно (FIB/IBO/IBX/ISC API) и проверить на них.

И меня смешит, что за четыре дня никто, из здесь отметившихся, этого не сделал.
19 мар 17, 11:53    [20310282]     Ответить | Цитировать Сообщить модератору
 Re: ANN: видео о мифе эффективности параллельной вставки  [new]
hvlad
Member

Откуда:
Сообщений: 10765
Коваленко Дмитрий
Для начала надо заставить восемь экземпляров isql отрабатывать в 4 раза быстрее.
Ты (и kdv) не правильно интерпретируете полученные результаты :)
На примере твоих данных: я, например, вижу, что движок в состоянии залить 1млн записей (в твою таблицу с индексом и триггером) за 31 сек.
Твой код имеет значительный оверхед, который хороо виден на одном потоке и который удаётся преодолеть где-то 4-8 потокам.
Что радует - при увеличении кол-ва потоков нет деградации производительности (хотя причины для неё вполне есть). Не знаю, как оно было бы для 32-64-128 потоков.
У isql оверхед другой, там и картина чуть другая. Вот и весь "секрет".
Коваленко Дмитрий
На 10 потоках и fb3_ss/cs/sc процессор (с HT) показывает загрузку на половину. То есть, можно считать, что все ядра загружены работой.
А какая загрузка у процесса FB и какая - у твоего теста ?
Коваленко Дмитрий
нагрузочное тестирование IBProvider-а в восемь потоков (10 часов) быстрее в полтора раза чем в четыре потока (15-16 часов)
А там что, тоже долбится одна и таже таблица ?
Коваленко Дмитрий
Почему-то не возникает вопрос - почему на одном подключении fb25_ss работает на 25% быстрее чем fb3_ss.
Потому что на него 100500 раз отвечали уже
19 мар 17, 12:55    [20310426]     Ответить | Цитировать Сообщить модератору
 Re: ANN: видео о мифе эффективности параллельной вставки  [new]
hvlad
Member

Откуда:
Сообщений: 10765
Коваленко Дмитрий
И меня смешит, что за четыре дня никто, из здесь отметившихся, этого не сделал.
Здесь Дельфи не знают (c) (tm), а ты про какой-то ужасный Ц-шарп :)
19 мар 17, 12:56    [20310428]     Ответить | Цитировать Сообщить модератору
 Re: ANN: видео о мифе эффективности параллельной вставки  [new]
hvlad
Member

Откуда:
Сообщений: 10765
Коваленко Дмитрий
До RAM-диска там дело не доходит - потому что страничный кэш (3GB) больше чем база данных (600MB).
Тут ты тоже не прав, кстати. Т.к. ты не менял FileSystemCacheTreshold, то ты выключил кеширование на уровне FS и любой IO превратился в синхронный непосредственный обмен с RAM диском.
19 мар 17, 13:03    [20310440]     Ответить | Цитировать Сообщить модератору
 Re: ANN: видео о мифе эффективности параллельной вставки  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 28568
Коваленко Дмитрий
. До RAM-диска там дело не доходит - потому что страничный кэш (3GB) больше чем база данных (600MB).

если ты так веришь, что кэш фб работает на массовые вставки - зачем тогда суперу выставил здоровенный кэш? В конце-концов мог бы еще один раз запустить тест супера с дефолтным кэшем.
19 мар 17, 15:04    [20310713]     Ответить | Цитировать Сообщить модератору
 Re: ANN: видео о мифе эффективности параллельной вставки  [new]
Коваленко Дмитрий
Member

Откуда: Липецк
Сообщений: 559
kdv
Коваленко Дмитрий
. До RAM-диска там дело не доходит - потому что страничный кэш (3GB) больше чем база данных (600MB).

если ты так веришь, что кэш фб работает на массовые вставки - зачем тогда суперу выставил здоровенный кэш?

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

Я не стал его менять для этого теста с инсертами на суперсервере.

Какой смысл мне жадничать?

kdv
В конце-концов мог бы еще один раз запустить тест супера с дефолтным кэшем.

Меня не просили, я не запускал.

А сам я в последнее время недогадливый стал.
19 мар 17, 17:22    [20310986]     Ответить | Цитировать Сообщить модератору
 Re: ANN: видео о мифе эффективности параллельной вставки  [new]
Коваленко Дмитрий
Member

Откуда: Липецк
Сообщений: 559
hvlad
Коваленко Дмитрий
На 10 потоках и fb3_ss/cs/sc процессор (с HT) показывает загрузку на половину. То есть, можно считать, что все ядра загружены работой.
А какая загрузка у процесса FB и какая - у твоего теста ?

Прямо сейчас померил (2 раза) 1млн в один поток. Лучший вариант:
- Тест работал 138 секунд.
- Тестовый процесс 58 секунд (User Time: 34 секунды).

hvlad
Коваленко Дмитрий
нагрузочное тестирование IBProvider-а в восемь потоков (10 часов) быстрее в полтора раза чем в четыре потока (15-16 часов)
А там что, тоже долбится одна и таже таблица ?

Таблиц в базе много. Но в какой то момент времени, как правило, тесты мучают одну или две.

Например таблица TBL_CS__WIN1251 - на ней проверяются разные комбинации кодовой страницы подключения/кодовой страницы клиента/разные способы вставки и чтения/разные типы (CHAR/VARCHAR/BLOB/массивы). Для каждого символа кодовой страницы 1251.

Если прогонять эти проверки последовательно - уже никакой жизни не хватит.

Или ты мне хочешь сказать, что я неправильно работаю с Firebird?

Ну, неправильно, да.

Правильно было раньше.
19 мар 17, 18:08    [20311093]     Ответить | Цитировать Сообщить модератору
 Re: ANN: видео о мифе эффективности параллельной вставки  [new]
Коваленко Дмитрий
Member

Откуда: Липецк
Сообщений: 559
hvlad
Коваленко Дмитрий
До RAM-диска там дело не доходит - потому что страничный кэш (3GB) больше чем база данных (600MB).
Тут ты тоже не прав, кстати. Т.к. ты не менял FileSystemCacheTreshold, то ты выключил кеширование на уровне FS и любой IO превратился в синхронный непосредственный обмен с RAM диском.

FileSystemCacheTreshold, наверное, появился после того как я перестал интересоваться вопросом "как еще можно ускорить сервер собственными средствами?". После 2010?

Спасибо, попробую.
19 мар 17, 18:16    [20311108]     Ответить | Цитировать Сообщить модератору
 Re: ANN: видео о мифе эффективности параллельной вставки  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 28568
Коваленко Дмитрий,

твои тесты твоего же драйвера тут мало кого интересуют. Любые посторонние штуки делают тест "не чистым". Что за проблема создать пустую базу и туда уже положить таблицу для теста insert? Кого, нафиг, интересует тест вставки в таблицу из ОДНОГО столбца? Ну ей-богу...
Коваленко Дмитрий
Спасибо, попробую.

чего там пробовать-то. смотришь RAMMAP, есть твоя база в файловом кэше, или нет. Если нет, значит ты кэш ФБ в конфиге задул больше FileSystemCacheTreshold, и все. А там по умолчанию 64к страниц.
19 мар 17, 18:54    [20311200]     Ответить | Цитировать Сообщить модератору
 Re: ANN: видео о мифе эффективности параллельной вставки  [new]
Коваленко Дмитрий
Member

Откуда: Липецк
Сообщений: 559
kdv
Коваленко Дмитрий,

твои тесты твоего же драйвера тут мало кого интересуют.

Они и мне не очень интересны. До тех пор пока не найдут какую нибудь херню. Как правило - на стороне сервера.
19 мар 17, 19:42    [20311325]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: ANN: видео о мифе эффективности параллельной вставки  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10378
запилил свой вариант на OO API 4.0 с использование Batch API (по 100 записей)
id это просто номер записи в цикле, threadId номер потока. Заливалось 1 млн записей.
Процессор Inter Core i3-8100 3.6 GHz (4 физических ядра).
На каждый поток своё подключение по TCP на localhost.

1. Без индексов

recreate table t(id bigint, threadId int)


c:\Users\Denis\source\repos\threadtest\x64\Release>threadtest 1
Recreate table
Insert 1000000 with 1 threads
Insert time: 3848 ms
Count record after test: 1000000

c:\Users\Denis\source\repos\threadtest\x64\Release>threadtest 2
Recreate table
Insert 1000000 with 2 threads
Insert time: 3129 ms
Count record after test: 1000000

c:\Users\Denis\source\repos\threadtest\x64\Release>threadtest 4
Recreate table
Insert 1000000 with 4 threads
Insert time: 2632 ms
Count record after test: 1000000

c:\Users\Denis\source\repos\threadtest\x64\Release>threadtest 8
Recreate table
Insert 1000000 with 8 threads
Insert time: 2409 ms
Count record after test: 1000000

c:\Users\Denis\source\repos\threadtest\x64\Release>threadtest 16
Recreate table
Insert 1000000 with 16 threads
Insert time: 2400 ms
Count record after test: 1000000

c:\Users\Denis\source\repos\threadtest\x64\Release>threadtest 32
Recreate table
Insert 1000000 with 32 threads
Insert time: 2728 ms
Count record after test: 1000000

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

А вот если есть индексы картина кардинально меняется

recreate table t(id bigint, threadId int, constraint pk_t primary key(id))


c:\Users\Denis\source\repos\threadtest\x64\Release>threadtest 1
Recreate table
Insert 1000000 with 1 threads
Insert time: 22024 ms
Count record after test: 1000000

c:\Users\Denis\source\repos\threadtest\x64\Release>threadtest 2
Recreate table
Insert 1000000 with 2 threads
Insert time: 11534 ms
Count record after test: 1000000

c:\Users\Denis\source\repos\threadtest\x64\Release>threadtest 4
Recreate table
Insert 1000000 with 4 threads
Insert time: 5246 ms
Count record after test: 1000000

c:\Users\Denis\source\repos\threadtest\x64\Release>threadtest 8
Recreate table
Insert 1000000 with 8 threads
Insert time: 4833 ms
Count record after test: 1000000

c:\Users\Denis\source\repos\threadtest\x64\Release>threadtest 16
Recreate table
Insert 1000000 with 16 threads
Insert time: 4783 ms
Count record after test: 1000000

c:\Users\Denis\source\repos\threadtest\x64\Release>threadtest 32
Recreate table
Insert 1000000 with 32 threads
Insert time: 4737 ms
Count record after test: 1000000

Первоначально пробовал без использование batch API. Так вот там вставка в таблицу без индексов параллелилась прям на ура. Но потом я подумал и понял, что ускорение происходит за счёт преодоления оверхеда сетевого взаимодействия пусть даже по localhost.
13 фев 20, 22:59    [22079646]     Ответить | Цитировать Сообщить модератору
 Re: ANN: видео о мифе эффективности параллельной вставки  [new]
hvlad
Member

Откуда:
Сообщений: 10765
Симонов Денис
Первоначально пробовал без использование batch API. Так вот там вставка в таблицу без индексов параллелилась прям на ура
Интересно. А результатов не сохранил ? Сравнить с Batch API, да и вообще.

Насчёт индексов - как распределены ключи ?
Ну и - как часто делал коммит, чему равен FW, какая дисковая, что менял в конфиге ?
Интересно ещё повторить с xnet и embedded.
И с более широкой таблицей.
Тесты с блобами и обычным\BatchAPI тоже весьма интересны :)

Я не сильно губу раскатал ? ;)
14 фев 20, 00:00    [22079665]     Ответить | Цитировать Сообщить модератору
 Re: ANN: видео о мифе эффективности параллельной вставки  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 28568
Симонов Денис,

архитектура-то какая?
14 фев 20, 02:28    [22079687]     Ответить | Цитировать Сообщить модератору
 Re: ANN: видео о мифе эффективности параллельной вставки  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10378
kdv,

SS

hvlad
Интересно. А результатов не сохранил ? Сравнить с Batch API, да и вообще.


там в табличке не было поля threadId. В одном потоке скорость была примерно в 10 раз хуже. Batch API рулит :)
Постараюсь вечером повторить на новой таблице. Да и вообще оставить в коде оба варианта с переключением через аргументы консоли.

hvlad
Насчёт индексов - как распределены ключи ?


В одном потоке id=1, 2, 3, 4, 5 ... 1000000
Если потоков несколько то я просто разбиваю на одинаковые диапазоны. Т.е. для 2 потоков 1...500000 и 500001...1000000
Но в саму таблицу они конечно попадают как random пошлёт. Из одного потока всегда нарастают, но потоки могут чередоваться как захотят.

FW=ON, обычный SATA диск

xnet и embedded попробую. Вообще я пока не делал тест настраиваемым. Надо бы входные параметры в аргументы командной строки перенести.

hvlad
И с более широкой таблицей.
Тесты с блобами и обычным\BatchAPI тоже весьма интересны :)


а вот это настройками сделать сложнее, ибо я использую в коде макросы FB_MESSAGE. Т.е. придётся на каждый вариант таблицы свою процедуру заливки делать. С блобами там вообще в BatchAPI аж 4 варианта.

hvlad
Я не сильно губу раскатал ?


нормально. Мне же самому интересно, иначе бы я тест делать не стал. :)
14 фев 20, 09:54    [22079761]     Ответить | Цитировать Сообщить модератору
 Re: ANN: видео о мифе эффективности параллельной вставки  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10378
Результаты тестов для разных протоколов.
Варианты с широкой таблицей и BLOB не тестировались.

Потоков/подключенийINETINET batchINET indexINET index batchXNETXNET batchXNET indexXNET index batchEmbEmb batchEmb index
139.1353.56945.75512.91919.5663.55832.08413.3524.4653.42713.922
220.6813.42431.9828.68811.3762.90228.6878.2333.7893.09611.093
415.3202.70218.8615.8069.5592.60614.6665.2293.6802.9555.870
814.8762.42018.0354.9458.2442.49312.7844.6492.8672.7476.167
1615.0852.43317.8964.9178.2262.45211.4915.0373.0932.6115.743


+ статистика для 1 потока


Analyzing database pages ...
T (191)
Primary pointer page: 2044, Index root page: 2045
Total formats: 1, used formats: 1
Average record length: 13.93, total records: 1000000
Average version length: 0.00, total versions: 0, max versions: 0
Average fragment length: 0.00, total fragments: 0, max fragments: 0
Average unpacked length: 20.00, compression ratio: 1.44
Pointer pages: 5, data page slots: 6624
Data pages: 6624, average fill: 57%
Primary pages: 6624, secondary pages: 0, swept pages: 0
Empty pages: 1, full pages: 6622
Fill distribution:
0 - 19% = 1
20 - 39% = 1
40 - 59% = 6622
60 - 79% = 0
80 - 99% = 0

Index PK_T (0)
Root page: 3272, depth: 3, leaf buckets: 1485, nodes: 1000000
Average node length: 11.87, total dup: 0, max dup: 0
Average key length: 9.04, compression ratio: 1.00
Average prefix length: 2.96, average data length: 6.04
Clustering factor: 6623, ratio: 0.01
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 24
60 - 79% = 0
80 - 99% = 1460


+ статистика для 4 потоков


Analyzing database pages ...
T (192)
Primary pointer page: 8338, Index root page: 8339
Total formats: 1, used formats: 1
Average record length: 13.93, total records: 1000000
Average version length: 0.00, total versions: 0, max versions: 0
Average fragment length: 0.00, total fragments: 0, max fragments: 0
Average unpacked length: 20.00, compression ratio: 1.44
Pointer pages: 5, data page slots: 6624
Data pages: 6624, average fill: 57%
Primary pages: 6624, secondary pages: 0, swept pages: 0
Empty pages: 1, full pages: 6622
Fill distribution:
0 - 19% = 1
20 - 39% = 1
40 - 59% = 6622
60 - 79% = 0
80 - 99% = 0

Index PK_T (0)
Root page: 2369, depth: 3, leaf buckets: 2522, nodes: 1000000
Average node length: 11.88, total dup: 0, max dup: 0
Average key length: 9.04, compression ratio: 1.00
Average prefix length: 2.96, average data length: 6.04
Clustering factor: 21662, ratio: 0.02
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 2154
60 - 79% = 1
80 - 99% = 366


выводы:
1. Массовая заливка данных в таблицы по сетевым протоколам (INET,WNET,XNET) при использовании Batch API существенно быстрее.
2. Batch API с Embedded даёт небольшой прирост производительности, что ожидаемо.
3. Параллельная вставка в одну таблицу без индексов не даёт существенного выигрыша (при использовании сетевых протоколов может сложится впечатление, что операция хорошо масштабируется, однако на самом деле это преодоление оверхеда сетевых протоколов, что хорошо видно при использовании Batch API или Embedded )
4. Параллельная вставка в одну таблицу с индексами масштабируется существенно лучше. Однако учтите, что при параллельной вставке записи будут попадать в таблицу не в том порядке в котором они были изначально, а потому индексы станут менее компактными. Кроме того их фактор кластеризации будет существенно хуже.

Сообщение было отредактировано: 15 фев 20, 16:08
15 фев 20, 16:08    [22080521]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4]      все
Все форумы / Firebird, InterBase Ответить