ReSQL.ru
     
powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / ANN: видео о мифе эффективности параллельной вставки
16 сообщений из 91, страница 4 из 4
  4  все
ANN: видео о мифе эффективности параллельной вставки
    #39422412
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
kdvя бы добавил, но ты меня этим советом ввел в ступорВыйди из ступора и добавь пустой триггер :)

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

kdvА вот 128 секунд и 65 секунд - не эквивалентны.Ну так у вас и условия теста мало в чём совпадают
...
Рейтинг: 0 / 0
19.03.2017, 11:06
| Ответить | Цитировать | Написать  
ANN: видео о мифе эффективности параллельной вставки
    #39422420
Коваленко Дмитрий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Коваленко Дмитрий
Участник
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) и проверить на них.

И меня смешит, что за четыре дня никто, из здесь отметившихся, этого не сделал.
...
Рейтинг: 0 / 0
19.03.2017, 11:53
| Ответить | Цитировать | Написать  
ANN: видео о мифе эффективности параллельной вставки
    #39422443
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Коваленко ДмитрийДля начала надо заставить восемь экземпляров 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 раз отвечали уже
...
Рейтинг: 0 / 0
19.03.2017, 12:55
| Ответить | Цитировать | Написать  
ANN: видео о мифе эффективности параллельной вставки
    #39422444
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Коваленко ДмитрийИ меня смешит, что за четыре дня никто, из здесь отметившихся, этого не сделал.Здесь Дельфи не знают (c) (tm), а ты про какой-то ужасный Ц-шарп :)
...
Рейтинг: 0 / 0
19.03.2017, 12:56
| Ответить | Цитировать | Написать  
ANN: видео о мифе эффективности параллельной вставки
    #39422447
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Коваленко ДмитрийДо RAM-диска там дело не доходит - потому что страничный кэш (3GB) больше чем база данных (600MB).Тут ты тоже не прав, кстати. Т.к. ты не менял FileSystemCacheTreshold, то ты выключил кеширование на уровне FS и любой IO превратился в синхронный непосредственный обмен с RAM диском.
...
Рейтинг: 0 / 0
19.03.2017, 13:03
| Ответить | Цитировать | Написать  
ANN: видео о мифе эффективности параллельной вставки
    #39422504
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Коваленко Дмитрий. До RAM-диска там дело не доходит - потому что страничный кэш (3GB) больше чем база данных (600MB).
если ты так веришь, что кэш фб работает на массовые вставки - зачем тогда суперу выставил здоровенный кэш? В конце-концов мог бы еще один раз запустить тест супера с дефолтным кэшем.
...
Рейтинг: 0 / 0
19.03.2017, 15:04
| Ответить | Цитировать | Написать  
ANN: видео о мифе эффективности параллельной вставки
    #39422568
Коваленко Дмитрий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Коваленко Дмитрий
Участник
kdvКоваленко Дмитрий. До RAM-диска там дело не доходит - потому что страничный кэш (3GB) больше чем база данных (600MB).
если ты так веришь, что кэш фб работает на массовые вставки - зачем тогда суперу выставил здоровенный кэш?
Это размер кэша, в который целиком помещается база после нагрузочного тестирования на FB3_SS.

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

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

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

А сам я в последнее время недогадливый стал.
...
Рейтинг: 0 / 0
19.03.2017, 17:22
| Ответить | Цитировать | Написать  
ANN: видео о мифе эффективности параллельной вставки
    #39422599
Коваленко Дмитрий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Коваленко Дмитрий
Участник
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?

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

Правильно было раньше.
...
Рейтинг: 0 / 0
19.03.2017, 18:08
| Ответить | Цитировать | Написать  
ANN: видео о мифе эффективности параллельной вставки
    #39422602
Коваленко Дмитрий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Коваленко Дмитрий
Участник
hvladКоваленко ДмитрийДо RAM-диска там дело не доходит - потому что страничный кэш (3GB) больше чем база данных (600MB).Тут ты тоже не прав, кстати. Т.к. ты не менял FileSystemCacheTreshold, то ты выключил кеширование на уровне FS и любой IO превратился в синхронный непосредственный обмен с RAM диском.
FileSystemCacheTreshold, наверное, появился после того как я перестал интересоваться вопросом "как еще можно ускорить сервер собственными средствами?". После 2010?

Спасибо, попробую.
...
Рейтинг: 0 / 0
19.03.2017, 18:16
| Ответить | Цитировать | Написать  
ANN: видео о мифе эффективности параллельной вставки
    #39422621
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Коваленко Дмитрий,

твои тесты твоего же драйвера тут мало кого интересуют. Любые посторонние штуки делают тест "не чистым". Что за проблема создать пустую базу и туда уже положить таблицу для теста insert? Кого, нафиг, интересует тест вставки в таблицу из ОДНОГО столбца? Ну ей-богу...
Коваленко ДмитрийСпасибо, попробую.
чего там пробовать-то. смотришь RAMMAP, есть твоя база в файловом кэше, или нет. Если нет, значит ты кэш ФБ в конфиге задул больше FileSystemCacheTreshold, и все. А там по умолчанию 64к страниц.
...
Рейтинг: 0 / 0
19.03.2017, 18:54
| Ответить | Цитировать | Написать  
ANN: видео о мифе эффективности параллельной вставки
    #39422643
Коваленко Дмитрий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Коваленко Дмитрий
Участник
kdvКоваленко Дмитрий,

твои тесты твоего же драйвера тут мало кого интересуют.
Они и мне не очень интересны. До тех пор пока не найдут какую нибудь херню. Как правило - на стороне сервера.
...
Рейтинг: 0 / 0
19.03.2017, 19:42
| Ответить | Цитировать | Написать  
Период между сообщениями больше года.
ANN: видео о мифе эффективности параллельной вставки
    #39926487
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
запилил свой вариант на OO API 4.0 с использование Batch API (по 100 записей)
id это просто номер записи в цикле, threadId номер потока. Заливалось 1 млн записей.
Процессор Inter Core i3-8100 3.6 GHz (4 физических ядра).
На каждый поток своё подключение по TCP на localhost.

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

Код: sql
1.
recreate table t(id bigint, threadId int)



Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
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

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

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

Код: sql
1.
recreate table t(id bigint, threadId int, constraint pk_t primary key(id))



Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
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.
...
Рейтинг: 0 / 0
13.02.2020, 22:59
| Ответить | Цитировать | Написать  
ANN: видео о мифе эффективности параллельной вставки
    #39926503
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Симонов Денис
Первоначально пробовал без использование batch API. Так вот там вставка в таблицу без индексов параллелилась прям на ура
Интересно. А результатов не сохранил ? Сравнить с Batch API, да и вообще.

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

Я не сильно губу раскатал ? ;)
...
Рейтинг: 0 / 0
14.02.2020, 00:00
| Ответить | Цитировать | Написать  
ANN: видео о мифе эффективности параллельной вставки
    #39926518
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Симонов Денис,

архитектура-то какая?
...
Рейтинг: 0 / 0
14.02.2020, 02:28
| Ответить | Цитировать | Написать  
ANN: видео о мифе эффективности параллельной вставки
    #39926563
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
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Я не сильно губу раскатал ?

нормально. Мне же самому интересно, иначе бы я тест делать не стал. :)
...
Рейтинг: 0 / 0
14.02.2020, 09:54
| Ответить | Цитировать | Написать  
ANN: видео о мифе эффективности параллельной вставки
    #39927028
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Результаты тестов для разных протоколов.
Варианты с широкой таблицей и BLOB не тестировались.

Потоков/подключенийINETINET batchINET indexINET index batchXNETXNET batchXNET indexXNET index batchEmbEmb batchEmb index139.1353.56945.75512.91919.5663.55832.08413.3524.4653.42713.922220.6813.42431.9828.68811.3762.90228.6878.2333.7893.09611.093415.3202.70218.8615.8069.5592.60614.6665.2293.6802.9555.870814.8762.42018.0354.9458.2442.49312.7844.6492.8672.7476.1671615.0852.43317.8964.9178.2262.45211.4915.0373.0932.6115.743

 
статистика для 1 потока
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
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 потоков
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
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. Параллельная вставка в одну таблицу с индексами масштабируется существенно лучше. Однако учтите, что при параллельной вставке записи будут попадать в таблицу не в том порядке в котором они были изначально, а потому индексы станут менее компактными. Кроме того их фактор кластеризации будет существенно хуже.
...
Рейтинг: 0 / 0
15.02.2020, 16:08
| Ответить | Цитировать | Написать  
16 сообщений из 91, страница 4 из 4
  4  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / ANN: видео о мифе эффективности параллельной вставки
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=39422643&tid=1560443]:
 0ms
get settings:
 8ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 128ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 47ms
get tp. blocked users:
 1ms
others: 263ms
total:  478ms
созд. / загр.: 478ms
x
x
Закрыть


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