Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Демон под линукс
|
|||
|---|---|---|---|
|
#18+
nagisa, как альтернативу линуксовым pipe можешь посмотреть на родные средства С++ : std::queue - очередь std::thread - создание потоков std::mutex - синхронизация доступа из разных потоков std::condition_variable - пробуждение потока ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2017, 14:14 |
|
||
|
Демон под линукс
|
|||
|---|---|---|---|
|
#18+
nagisa 1 : Create a direct path handle with OCI_DirPathCreate() 2 : Set (optional) some direct path load attributes 3 : Describe the columns to load with OCI_DirPathSetColumn() 4 : Populate data with OCI_DirPathSetEntry() 5 : Convert the data with OCI_DirPathConvert() 6 : Load the data into the database with OCI_DirPathLoad() 7 : Repeat step 4,5,6 + reset the stream with OCI_DirPathReset() until all rows has been loaded 8 : Commit the load with OCI_DirPathFinish() 9 : Free the direct path handle with OCI_DirPathFree()Ну и в каком месте тут требуется какая-то асинхронность, формирование пачек по хитровывернутому алгоритму? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2017, 16:07 |
|
||
|
Демон под линукс
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorovnagisa 1 : Create a direct path handle with OCI_DirPathCreate() 2 : Set (optional) some direct path load attributes 3 : Describe the columns to load with OCI_DirPathSetColumn() 4 : Populate data with OCI_DirPathSetEntry() 5 : Convert the data with OCI_DirPathConvert() 6 : Load the data into the database with OCI_DirPathLoad() 7 : Repeat step 4,5,6 + reset the stream with OCI_DirPathReset() until all rows has been loaded 8 : Commit the load with OCI_DirPathFinish() 9 : Free the direct path handle with OCI_DirPathFree()Ну и в каком месте тут требуется какая-то асинхронность, формирование пачек по хитровывернутому алгоритму? пройдите по ссылкам там и примеры есть размер пачки задается тут Код: plaintext 1. где NUM_COLS - количество колонок, а nb_rows - количество записей в пачке у меня, максимальная скорость достигается при размере пачки 4000 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2017, 04:15 |
|
||
|
Демон под линукс
|
|||
|---|---|---|---|
|
#18+
Dima Tnagisaя вообще правильно понял что это персональный буфер FIFO выделяемый под созданный сокет ? Нет. Я про sockfd из которого ты принимаешь пакеты Код: plaintext 1. Это прием из сети UDP пакетов, у sockfd есть буфер, в который входящий пакет сначала кладется, затем твоя прога его оттуда читает recvfrom(), если твоя прога не будет успевать читать и буфер переполнится, то новые пакеты будут просто удалятся, так устроен UDP. А твой FIFO это уже следующая цепочка, со своими буферами и прочими настройками. Как он работает я не знаю, но варианта всего два: либо будут потери, либо будет зависание на записи пока место не появится куда писать. спасибо. значит изначальная схема с тремя звеньями была верной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2017, 04:18 |
|
||
|
Демон под линукс
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovnagisaAPI DirectPath это специальный интерфейс для загрузки Проблема в том, что вы и к пределу скорости обычного интерфейса не подошли, что говорит о кривизне вашего приложения. Но вольному воля. да я как бы не претендую, поправьте меня примером который обычным интерфейсом грузит хотя бы 10К ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2017, 04:19 |
|
||
|
Демон под линукс
|
|||
|---|---|---|---|
|
#18+
nagisaпоправьте меня примером который обычным интерфейсом грузит хотя бы 10К Какое слово из "использовать Array DML и отключить autocommit" Вы не поняли? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2017, 12:36 |
|
||
|
Демон под линукс
|
|||
|---|---|---|---|
|
#18+
Какую скорость загрузки на Вашем оборудовании показывает SQLLoader без режима direct? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2017, 12:39 |
|
||
|
Демон под линукс
|
|||
|---|---|---|---|
|
#18+
nagisaзначит изначальная схема с тремя звеньями была верной. только неясно, зачем третье звено ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2017, 13:13 |
|
||
|
Демон под линукс
|
|||
|---|---|---|---|
|
#18+
nagisaDima Tпропущено... Нет. Я про sockfd из которого ты принимаешь пакеты Код: plaintext 1. Это прием из сети UDP пакетов, у sockfd есть буфер, в который входящий пакет сначала кладется, затем твоя прога его оттуда читает recvfrom(), если твоя прога не будет успевать читать и буфер переполнится, то новые пакеты будут просто удалятся, так устроен UDP. А твой FIFO это уже следующая цепочка, со своими буферами и прочими настройками. Как он работает я не знаю, но варианта всего два: либо будут потери, либо будет зависание на записи пока место не появится куда писать. спасибо. значит изначальная схема с тремя звеньями была верной. трудно сказать, что у тебя было верно, но задача эта решается так у тебя есть процесс (или тред) приемник, его задача - гарантированно принимать пакеты с заданным rate в память, это ок у тебя есть процесс (или тред) писатель пакетов в Oracle - гарантий там особых нет никаких, ибо завязано на дисковую подсистему, это понятно между двумя процессами должен быть буфер обмена, просто чтоб гасить задержки в обработке пакетов вторым процессом. делать обмен между процессами это через PIPE, сокеты и подобное - можно, но не нужно, ибо там на каждый пакет будет поход в ядро (переключение контекста), а это крайне не дешево как нужно? нужно работать через shm (shared memory) или memory mapped files. ну и lock free алгоритмы, простейший случай которых - circular buffer или LMAX Disruptor - можно в интернетах почитать, что это такое (там можно многоие миллионы сообщений передавать в секунду между процессами). и да, Oracle. для Direct Path уровень гранулярности - таблица. или партиция (субпартиция) - которая, по сути, является отдельной физической таблицей. т.е. если тебе нужно нарастить скорость записи в Oracle - то таблицу назначение нужно распартицировать и писать в каждую партицию отдельной сессией/процессом Oracle. практические замеры даже на commodity железе показали почти линейный рост вплоть до 10 параллельных писателей, хотя там все обычно ограничено дисковой подсистемой, но и коммуникационные издержки чисто у Oracle очень велики (отсюда и up to 10x рост) но главный мессадж данного поста - внутреннее межпроцессное взаимодействие нужно делать через mmap и lock free circular buffer / queue, это самый скоростной способ IPC ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2017, 15:01 |
|
||
|
Демон под линукс
|
|||
|---|---|---|---|
|
#18+
автору тебя есть процесс (или тред) приемник, его задача - гарантированно принимать пакеты с заданным rate в память, это ок Не факт, что и это ему нужно. Иногда можно просто читать исходные данные в том темпе, в котором их может обрабатывать писатель в Oracle. Т.е. хватить обычного SQLLOader, обрабатывающего linux pipe на входе. Уже наверное раз 10 сказали это ТС-у, но толку ноль... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2017, 16:03 |
|
||
|
Демон под линукс
|
|||
|---|---|---|---|
|
#18+
MasterZivавтору тебя есть процесс (или тред) приемник, его задача - гарантированно принимать пакеты с заданным rate в память, это ок Не факт, что и это ему нужно. Иногда можно просто читать исходные данные в том темпе, в котором их может обрабатывать писатель в Oracle. Т.е. хватить обычного SQLLOader, обрабатывающего linux pipe на входе. Уже наверное раз 10 сказали это ТС-у, но толку ноль... ну, если у него не UDP, то стандартные TCP nagle алгоритмы могут привести к очень неожиданным поведениям приложения. а так конечно да, можно просто буфер приемника привинтить гигантского размера и обойтись одним тредом. и даже если делать несколько писателей - собственно в отдельный тред можно отправлять только вызов OCI_DirPathLoad (ну или fork/spawn sqlldr), остальные вызовы работают относительно быстро. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2017, 17:30 |
|
||
|
Демон под линукс
|
|||
|---|---|---|---|
|
#18+
dbpatchну, если у него не UDP топикстартер замерял потери пакетов. 99.9% - у него UDP собсвенно и предлагается максимально увеличить размер буфера в ядре. мож второй демон и не понадобится как межпроцессное взаимодействие реализовано - топикстартер не сознался, подозреваю, что до этого ещё не дошло ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2017, 00:36 |
|
||
|
Демон под линукс
|
|||
|---|---|---|---|
|
#18+
Изопропилdbpatchну, если у него не UDP топикстартер замерял потери пакетов. 99.9% - у него UDP ну, на канальном уровне у TCP тоже потери бывают, и их вполне можно измерить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2017, 00:52 |
|
||
|
Демон под линукс
|
|||
|---|---|---|---|
|
#18+
Изопропилкак межпроцессное взаимодействие реализовано - топикстартер не сознался, подозреваю, что до этого ещё не дошло У меня таки теплится надежда, что ему и потоков хватит. Они между собой всё же попроще взаимодействуют... Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2017, 01:20 |
|
||
|
Демон под линукс
|
|||
|---|---|---|---|
|
#18+
dbpatchИзопропилпропущено... топикстартер замерял потери пакетов. 99.9% - у него UDP ну, на канальном уровне у TCP тоже потери бывают, и их вполне можно измерить. на это я 0.1% оставил ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2017, 02:12 |
|
||
|
Демон под линукс
|
|||
|---|---|---|---|
|
#18+
nagisaя сейчас принимаю пакеты при помощи bind(sockfd,(struct sockaddr *)&servaddr,sizeof(servaddr)) и затем recvfrom (sockfd,me .... Уже понятно что UDP ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2017, 07:02 |
|
||
|
Демон под линукс
|
|||
|---|---|---|---|
|
#18+
сам ты не читательnagisaпропущено... спасибо. значит изначальная схема с тремя звеньями была верной. трудно сказать, что у тебя было верно, но задача эта решается так у тебя есть процесс (или тред) приемник, его задача - гарантированно принимать пакеты с заданным rate в память, это ок у тебя есть процесс (или тред) писатель пакетов в Oracle - гарантий там особых нет никаких, ибо завязано на дисковую подсистему, это понятно между двумя процессами должен быть буфер обмена, просто чтоб гасить задержки в обработке пакетов вторым процессом. делать обмен между процессами это через PIPE, сокеты и подобное - можно, но не нужно, ибо там на каждый пакет будет поход в ядро (переключение контекста), а это крайне не дешево как нужно? нужно работать через shm (shared memory) или memory mapped files. ну и lock free алгоритмы, простейший случай которых - circular buffer или LMAX Disruptor - можно в интернетах почитать, что это такое (там можно многоие миллионы сообщений передавать в секунду между процессами). и да, Oracle. для Direct Path уровень гранулярности - таблица. или партиция (субпартиция) - которая, по сути, является отдельной физической таблицей. т.е. если тебе нужно нарастить скорость записи в Oracle - то таблицу назначение нужно распартицировать и писать в каждую партицию отдельной сессией/процессом Oracle. практические замеры даже на commodity железе показали почти линейный рост вплоть до 10 параллельных писателей, хотя там все обычно ограничено дисковой подсистемой, но и коммуникационные издержки чисто у Oracle очень велики (отсюда и up to 10x рост) но главный мессадж данного поста - внутреннее межпроцессное взаимодействие нужно делать через mmap и lock free circular buffer / queue, это самый скоростной способ IPC Полностью согласен с автором, но есть 5 копеек. Сетевой слушатель непрерывно заполняет области разделяемой памяти по факту заполнения область обрабатывает писатель в базу, а сетевой слушатель переходит к следующей области разделяемой памяти. Таким образом на один сетевой слушатель можно повесить несколько писателей в базу в зависимости от разности скоростей сетевого приема и записи в БД. В параноидальном случае нужно завести 2 сетевые карты на разных PCI шинах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2017, 12:59 |
|
||
|
|
start [/forum/topic.php?fid=57&gotonew=1&tid=2018306]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
33ms |
get topic data: |
8ms |
get first new msg: |
6ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 254ms |
| total: | 383ms |
| 0 / 0 |
