ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / C++ [игнор отключен] [закрыт для гостей] / Демон под линукс
43 сообщений из 43, показаны все 2 страниц
  все  
Демон под линукс
    #39380500
nagisa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nagisa
Гость
Задача написать демон под линукс, задача демона - загрузка потока данных в Oracle

сейчас поток данных слабый - те до 1000 пакетов в секунду и хватает обычного двухпроцессного демона:
те демон контроллер и дочерний процесс-обработчик который принимает пакеты и кладет их в базу, периодически делая коммит

надо улучшить демон - те обеспечить возможность приема до 100'000 пакетов в секунду
соответственно получается надо выделить явно процессы приема и парсинга пакетов и процесса записи в базу с применением DirectPath

DirectPath уже оттестил, получается до 250К записей в секунду кладется без напряга

по схеме получается 3 части:
1. receiver
2. FIFO
3. writer

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

логика процессов будет такая
1. receiver принимает, парсит и кладет пакеты в очередь FIFO, попутно определяя скорость их поступления в секунду.
2. writer формирует пакет DirectPath размер которого определяется скоростью и осуществляет загрузку.

те к примеру пришло за последнюю секунду 1452 пакета
соответственно DirectPath формирует блок в 1452 записи - те явно загружая, что пришло за -1 секунду
те текущая секунда уже грузится в FIFO а предыдущая льется в базу


ps: на сях пишу эпизодически, соответственно прошу не пинать
...
Рейтинг: 0 / 0
08.01.2017, 14:45
| Ответить | Цитировать | Написать  
Демон под линукс
    #39380762
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
nagisa,
вряд ли это вообще надо так делать.
...
Рейтинг: 0 / 0
09.01.2017, 11:47
| Ответить | Цитировать | Написать  
Демон под линукс
    #39380782
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
Не понял зачем скорость определять? Для статистики разве что.
Обработка очереди должна начинаться сразу как только туда что-то попало. Т.е. поток обработки висит в ожидании, пишущий поток при каждой записи в очередь будит поток обработки, тот просыпается, все что есть в очереди отправляет пачкой в БД, и так работает пока очередь не опустеет, затем снова засыпает.
...
Рейтинг: 0 / 0
09.01.2017, 12:08
| Ответить | Цитировать | Написать  
Демон под линукс
    #39380853
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Dima T,

Про потоки автор как-то, видимо, скептически настроен...
...
Рейтинг: 0 / 0
09.01.2017, 14:14
| Ответить | Цитировать | Написать  
Демон под линукс
    #39380880
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
интересно, как receiver и writer данными обмениваются
...
Рейтинг: 0 / 0
09.01.2017, 14:48
| Ответить | Цитировать | Написать  
Демон под линукс
    #39380881
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
MasterZivDima T,

Про потоки автор как-то, видимо, скептически настроен...
Я в линуксах не силен, может там есть какое API чтобы между процессами очередь организовать, если не путаю в линуксе изначально вообще потоков не было, после добавили. Может он просто про них не в курсе.

Я так понял он отдельными процессами это решил сделать
nagisaвопрос в том как это правильно пишется - те организация FIFO и использование его процессами приема и записи ?
ИМХО с потоками проще.
...
Рейтинг: 0 / 0
09.01.2017, 14:51
| Ответить | Цитировать | Написать  
Демон под линукс
    #39380891
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
Dima Tможет там есть какое API чтобы между процессами очередь организовать
pipe самый обыкновенный что в никсах что в винде
...
Рейтинг: 0 / 0
09.01.2017, 15:04
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381003
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Далеко не факт, что вообще нужно разделать читателя источника и писателя в БД.
Поскольку обработка скорее всего будет никакая, то задача будет IO bound, и толку от введения в архитектуру двух потоков/процессов чтения и записи никакого не будет.
...
Рейтинг: 0 / 0
09.01.2017, 18:04
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381013
Фотография OoCc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OoCc
Участник
MasterZivПоскольку обработка скорее всего будет никакая, то задача будет IO bound, и толку от введения в архитектуру двух потоков/процессов чтения и записи никакого не будет.
Зависит от того умеет ли клиент оракла работать в асинхронном режиме
...
Рейтинг: 0 / 0
09.01.2017, 18:22
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381022
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Клиенту этого и не надо.
Умеет ли приложение, которому этого тоже не надо - вопрос уже к автору.
...
Рейтинг: 0 / 0
09.01.2017, 18:36
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381034
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
DirectPath сам внутри очередь имеет вроде как
...
Рейтинг: 0 / 0
09.01.2017, 19:04
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381083
nagisa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nagisa
Гость
Dima TНе понял зачем скорость определять? Для статистики разве что.
Обработка очереди должна начинаться сразу как только туда что-то попало. Т.е. поток обработки висит в ожидании, пишущий поток при каждой записи в очередь будит поток обработки, тот просыпается, все что есть в очереди отправляет пачкой в БД, и так работает пока очередь не опустеет, затем снова засыпает.

сейчас оно почти так и сделано - те пакет пришел и тут же в базу
потом коммит каждую секунду. но потолок этой технологии 3500 записей в секунду.

соответственно надо использовать другой подход - те API DirectPath
и это требует сразу явного объявления объема блока загрузки.
...
Рейтинг: 0 / 0
09.01.2017, 20:29
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381085
nagisa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nagisa
Гость
MasterZivDima T,

Про потоки автор как-то, видимо, скептически настроен...
да я никак еще не настроен, как я уже сказал - пишу эпизодически и соответственно какие-то вещи могу просто не знать тк не сталкивался.

сейчас хочу оттестить штатное FIFO - cм http://www.intuit.ru/studies/courses/2249/52/lecture/1554?page=6

просто хочу советов - те каких ошибок делать не стоит
тк подозреваю что при больших скоростях вылезут какие-то ньюансы, которые в начале были совсем не заметны...
...
Рейтинг: 0 / 0
09.01.2017, 20:34
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381086
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
nagisaпросто хочу советов - те каких ошибок делать не стоит
сначала без выпендрёжу сделать через DirectPath в одном процессе.

если будет плохо справляться - тогда и искать узкое место.

Главная потенциальная ошибка - преждевременная оптимизация
...
Рейтинг: 0 / 0
09.01.2017, 20:45
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381116
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Изопропилсначала без выпендрёжу сделать через DirectPath в одном процессе.

Но перед этим - использовать Array DML и отключить autocommit.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
09.01.2017, 22:02
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381244
nagisa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nagisa
Гость
Изопропилnagisaпросто хочу советов - те каких ошибок делать не стоит
сначала без выпендрёжу сделать через DirectPath в одном процессе.
если будет плохо справляться - тогда и искать узкое место.
Главная потенциальная ошибка - преждевременная оптимизация

вот смотрите:

1. тк мы не знаем сколько пакетов придет то мы накапливаем пакеты в буфер в течении 1с
их может придти 100 а может 100000 или больше, рассмотрим плохой случай со 100к пакетов

2. по итогам получили количество:
далее
затраты на подготовку сессии DirectPath - ~350мкс
затраты на загрузку - ~400мс
затраты на завершение сессии DirectPath - ~750мкс

если интенсивность поступления пакетов прежняя - те 100к в секунду, то мы потеряем ~40к пакетов


соответственно необходимость в разделении процессов приема пакетов и их записи явная


я сейчас принимаю пакеты при помощи
bind(sockfd,(struct sockaddr *)&servaddr,sizeof(servaddr))
и затем
recvfrom(sockfd,me ....

я правильно понимаю, размер FIFO при приеме данных тут ограничен системными настройками ? и в данной задаче рассчитывать на него точно не стоит ?
...
Рейтинг: 0 / 0
10.01.2017, 09:50
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381268
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
nagisaя правильно понимаю, размер FIFO при приеме данных тут ограничен системными настройками ? и в данной задаче рассчитывать на него точно не стоит ?
не совсем

системные настройки ограничивают максимальный размер буфера, изменяется или в конфиге или командой
sysctl -w net.core.rmem_max=

а для сокета можно выставить значение опции SO_RCVBUF

PS какие препятствия для тьюнинга хорошо нагруженной системы?
...
Рейтинг: 0 / 0
10.01.2017, 10:43
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381299
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
nagisaзатраты на подготовку сессии DirectPath - ~350мкс
затраты на загрузку - ~400мс
затраты на завершение сессии DirectPath - ~750мкс

если интенсивность поступления пакетов прежняя - те 100к в секунду, то мы потеряем ~40к пакетов

соответственно необходимость в разделении процессов приема пакетов и их записи явнаяВы точно не путаете транзакции и сессии?
...
Рейтинг: 0 / 0
10.01.2017, 11:24
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381350
nagisa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nagisa
Гость
Basil A. Sidorovnagisaзатраты на подготовку сессии DirectPath - ~350мкс
затраты на загрузку - ~400мс
затраты на завершение сессии DirectPath - ~750мкс

если интенсивность поступления пакетов прежняя - те 100к в секунду, то мы потеряем ~40к пакетов

соответственно необходимость в разделении процессов приема пакетов и их записи явнаяВы точно не путаете транзакции и сессии?
нет - API DirectPath это специальный интерфейс для загрузки
те в нем нет ни Insert-ов ни commit-a в традиционном понимании
как следствие нельзя использовать сиквенсы (их просто нет) и прочие ограничения, но зато офигенная скорость

см http://docs.oracle.com/cd/B19306_01/appdev.102/b14250/oci12obn.htm#i433129
https://vrogier.github.io/ocilib/doc/html/group___ocilib_c_apidirect_path.html


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()
...
Рейтинг: 0 / 0
10.01.2017, 12:08
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381359
nagisa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nagisa
Гость
Изопропилnagisaя правильно понимаю, размер FIFO при приеме данных тут ограничен системными настройками ? и в данной задаче рассчитывать на него точно не стоит ?
не совсем

системные настройки ограничивают максимальный размер буфера, изменяется или в конфиге или командой
sysctl -w net.core.rmem_max=

а для сокета можно выставить значение опции SO_RCVBUF

PS какие препятствия для тьюнинга хорошо нагруженной системы?
спасибо за пояснение

посмотрел
Код: plaintext
1.
2.
getsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, &rcvBufferSize, &sockOptSize);
printf("initial socket receive buf %d\n", rcvBufferSize);


Код: plaintext
initial socket receive buf 262144
я правильно понял что это это выделение памяти на каждый открываемый сокет ?

тогда должно хватить для задачи с головой - пакет <300 байт
и можно не парится что что-то пропадет во время слива массива в базу
...
Рейтинг: 0 / 0
10.01.2017, 12:13
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381371
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
nagisa
Код: plaintext
initial socket receive buf 262144
я правильно понял что это это выделение памяти на каждый открываемый сокет ?

тогда должно хватить для задачи с головой - пакет <300 байт
и можно не парится что что-то пропадет во время слива массива в базу
Сомневаюсь, тут всего 800-900 пакетов в буфер поместится. При скорости 100к/сек буфер заполнится за 8-9 мс, т.е. если твой процесс будет приостановлен на большее время - у тебя начнутся потери.

Сделай хотя бы 15 Мб, чтобы на полсекунды простоя хватало.
...
Рейтинг: 0 / 0
10.01.2017, 12:32
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381390
nagisa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nagisa
Гость
Dima Tnagisa
Код: plaintext
initial socket receive buf 262144
я правильно понял что это это выделение памяти на каждый открываемый сокет ?

тогда должно хватить для задачи с головой - пакет <300 байт
и можно не парится что что-то пропадет во время слива массива в базу
Сомневаюсь, тут всего 800-900 пакетов в буфер поместится. При скорости 100к/сек буфер заполнится за 8-9 мс, т.е. если твой процесс будет приостановлен на большее время - у тебя начнутся потери.

Сделай хотя бы 15 Мб, чтобы на полсекунды простоя хватало.
да, конечно, я так и хотел
но вот сейчас начал крутить параметр и ... обнаружил потолок в виде 8`388`608 - те 8МБ

я вообще правильно понял что это персональный буфер FIFO выделяемый под созданный сокет ?
...
Рейтинг: 0 / 0
10.01.2017, 12:52
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381399
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
nagisaAPI DirectPath это специальный интерфейс для загрузки

Проблема в том, что вы и к пределу скорости обычного интерфейса не подошли, что говорит о
кривизне вашего приложения. Но вольному воля.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
10.01.2017, 13:01
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381433
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
nagisaя вообще правильно понял что это персональный буфер FIFO выделяемый под созданный сокет ?
Нет.

Я про sockfd из которого ты принимаешь пакеты
Код: plaintext
1.
recvfrom(sockfd,me ....


Это прием из сети UDP пакетов, у sockfd есть буфер, в который входящий пакет сначала кладется, затем твоя прога его оттуда читает recvfrom(), если твоя прога не будет успевать читать и буфер переполнится, то новые пакеты будут просто удалятся, так устроен UDP.

А твой FIFO это уже следующая цепочка, со своими буферами и прочими настройками. Как он работает я не знаю, но варианта всего два: либо будут потери, либо будет зависание на записи пока место не появится куда писать.
...
Рейтинг: 0 / 0
10.01.2017, 13:24
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381442
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
nagisaно вот сейчас начал крутить параметр и ... обнаружил потолок в виде 8`388`608 - те 8МБ
ну дык sysctl надо подкрутить - net.core.rmem_max, net.ipv4.udp_mem
...
Рейтинг: 0 / 0
10.01.2017, 13:32
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381497
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
nagisa, как альтернативу линуксовым pipe можешь посмотреть на родные средства С++ :
std::queue - очередь
std::thread - создание потоков
std::mutex - синхронизация доступа из разных потоков
std::condition_variable - пробуждение потока
...
Рейтинг: 0 / 0
10.01.2017, 14:14
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381626
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
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()Ну и в каком месте тут требуется какая-то асинхронность, формирование пачек по хитровывернутому алгоритму?
...
Рейтинг: 0 / 0
10.01.2017, 16:07
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381945
nagisa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nagisa
Гость
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.
dp = OCI_DirPathCreate(tbl, NULL, NUM_COLS, nb_rows);


где NUM_COLS - количество колонок, а nb_rows - количество записей в пачке
у меня, максимальная скорость достигается при размере пачки 4000
...
Рейтинг: 0 / 0
11.01.2017, 04:15
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381946
nagisa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nagisa
Гость
Dima Tnagisaя вообще правильно понял что это персональный буфер FIFO выделяемый под созданный сокет ?
Нет.

Я про sockfd из которого ты принимаешь пакеты
Код: plaintext
1.
recvfrom(sockfd,me ....


Это прием из сети UDP пакетов, у sockfd есть буфер, в который входящий пакет сначала кладется, затем твоя прога его оттуда читает recvfrom(), если твоя прога не будет успевать читать и буфер переполнится, то новые пакеты будут просто удалятся, так устроен UDP.

А твой FIFO это уже следующая цепочка, со своими буферами и прочими настройками. Как он работает я не знаю, но варианта всего два: либо будут потери, либо будет зависание на записи пока место не появится куда писать.
спасибо.
значит изначальная схема с тремя звеньями была верной.
...
Рейтинг: 0 / 0
11.01.2017, 04:18
| Ответить | Цитировать | Написать  
Демон под линукс
    #39381947
nagisa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nagisa
Гость
Dimitry SibiryakovnagisaAPI DirectPath это специальный интерфейс для загрузки

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

да я как бы не претендую, поправьте меня примером который обычным интерфейсом грузит хотя бы 10К
...
Рейтинг: 0 / 0
11.01.2017, 04:19
| Ответить | Цитировать | Написать  
Демон под линукс
    #39382197
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
nagisaпоправьте меня примером который обычным интерфейсом грузит хотя бы 10К

Какое слово из "использовать Array DML и отключить autocommit" Вы не поняли?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
11.01.2017, 12:36
| Ответить | Цитировать | Написать  
Демон под линукс
    #39382202
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Какую скорость загрузки на Вашем оборудовании показывает SQLLoader без режима direct?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
11.01.2017, 12:39
| Ответить | Цитировать | Написать  
Демон под линукс
    #39382245
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
nagisaзначит изначальная схема с тремя звеньями была верной.
только неясно, зачем третье звено
...
Рейтинг: 0 / 0
11.01.2017, 13:13
| Ответить | Цитировать | Написать  
Демон под линукс
    #39382336
сам ты не читатель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
сам ты не читатель
Гость
nagisaDima Tпропущено...

Нет.

Я про sockfd из которого ты принимаешь пакеты
Код: plaintext
1.
recvfrom(sockfd,me ....


Это прием из сети 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
...
Рейтинг: 0 / 0
11.01.2017, 15:01
| Ответить | Цитировать | Написать  
Демон под линукс
    #39382414
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
автору тебя есть процесс (или тред) приемник, его задача - гарантированно принимать пакеты с заданным rate в память, это ок

Не факт, что и это ему нужно.
Иногда можно просто читать исходные данные в том темпе, в котором их может обрабатывать писатель в Oracle.
Т.е. хватить обычного SQLLOader, обрабатывающего linux pipe на входе.
Уже наверное раз 10 сказали это ТС-у, но толку ноль...
...
Рейтинг: 0 / 0
11.01.2017, 16:03
| Ответить | Цитировать | Написать  
Демон под линукс
    #39382531
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbpatch
Участник
MasterZivавтору тебя есть процесс (или тред) приемник, его задача - гарантированно принимать пакеты с заданным rate в память, это ок

Не факт, что и это ему нужно.
Иногда можно просто читать исходные данные в том темпе, в котором их может обрабатывать писатель в Oracle.
Т.е. хватить обычного SQLLOader, обрабатывающего linux pipe на входе.
Уже наверное раз 10 сказали это ТС-у, но толку ноль...

ну, если у него не UDP, то стандартные TCP nagle алгоритмы могут привести к очень неожиданным поведениям приложения.
а так конечно да, можно просто буфер приемника привинтить гигантского размера и обойтись одним тредом.

и даже если делать несколько писателей - собственно в отдельный тред можно отправлять только вызов OCI_DirPathLoad (ну или fork/spawn sqlldr), остальные вызовы работают относительно быстро.
...
Рейтинг: 0 / 0
11.01.2017, 17:30
| Ответить | Цитировать | Написать  
Демон под линукс
    #39382790
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
dbpatchну, если у него не UDP
топикстартер замерял потери пакетов. 99.9% - у него UDP

собсвенно и предлагается максимально увеличить размер буфера в ядре.
мож второй демон и не понадобится

как межпроцессное взаимодействие реализовано - топикстартер не сознался,
подозреваю, что до этого ещё не дошло
...
Рейтинг: 0 / 0
12.01.2017, 00:36
| Ответить | Цитировать | Написать  
Демон под линукс
    #39382795
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbpatch
Участник
Изопропилdbpatchну, если у него не UDP
топикстартер замерял потери пакетов. 99.9% - у него UDP

ну, на канальном уровне у TCP тоже потери бывают, и их вполне можно измерить.
...
Рейтинг: 0 / 0
12.01.2017, 00:52
| Ответить | Цитировать | Написать  
Демон под линукс
    #39382807
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Изопропилкак межпроцессное взаимодействие реализовано - топикстартер не сознался, подозреваю, что
до этого ещё не дошло

У меня таки теплится надежда, что ему и потоков хватит. Они между собой всё же попроще
взаимодействуют...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
12.01.2017, 01:20
| Ответить | Цитировать | Написать  
Демон под линукс
    #39382817
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
dbpatchИзопропилпропущено...

топикстартер замерял потери пакетов. 99.9% - у него UDP

ну, на канальном уровне у TCP тоже потери бывают, и их вполне можно измерить.
на это я 0.1% оставил
...
Рейтинг: 0 / 0
12.01.2017, 02:12
| Ответить | Цитировать | Написать  
Демон под линукс
    #39382843
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
nagisaя сейчас принимаю пакеты при помощи
bind(sockfd,(struct sockaddr *)&servaddr,sizeof(servaddr))
и затем
recvfrom (sockfd,me ....
Уже понятно что UDP
...
Рейтинг: 0 / 0
12.01.2017, 07:02
| Ответить | Цитировать | Написать  
Демон под линукс
    #39385365
д0kХ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
д0kХ
Гость
сам ты не читатель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 шинах.
...
Рейтинг: 0 / 0
16.01.2017, 12:59
| Ответить | Цитировать | Написать  
Демон под линукс
    #39390725
nagisa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nagisa
Гость
Коллеги д0kХ и сам ты не читатель !
Спасибо за советы!

C использованием shm разобрался, сделал кольцевой буфер, автоподстройку под количество пакетов итд итп
короче все вышло отлично!
...
Рейтинг: 0 / 0
25.01.2017, 05:37
| Ответить | Цитировать | Написать  
43 сообщений из 43, показаны все 2 страниц
  все  
Форумы / C++ [игнор отключен] [закрыт для гостей] / Демон под линукс
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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