iBase.ru Forum

Привет!
D5, IBX, FB1.5.1.
Программа сливает в одну офисную базу инфу по дневным продажам от более чем трехсот удаленных торговых точек. Если принимать информацию одним потоком, то все проходит на ура, как только пытаюсь увеличить количество потоков, периодически начинает вываливается сабж.
В чем может быть причина ?

ЗЫ. В каждом потоке реализован персональный коннект, т.е. свои TIBDatabase и TIBTransaction.

ibx должен быть 5.04, не меньше. Потом, может быть ты как то не так работу с threads прописал. Ссылки на примеры есть в
www.ibase.ru/devinfo/ibx.htm

а вообще я бы не лил сразу в базу, а сначала лил просто в файл. И только потом файл импортировал. Ибо, я не знаю, что будет если твоя программа заливки вдруг брякнется - куда денутся непринятые или несохраненные по commit данные?

IBX 5.04

При работе с потоками учтены все рекомендации, какие нашел, как то: отдельный TIBDatabase c TIBTransaction, удаленный сервер, коннект в основном потоке посредством Synchronize. Кстати стабильности при коннекте последний пункт все таки не дает.

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

Ошибка возникает не постоянно. Программа может 150 файлов проглотить без проблем, но на следующей порции из 10 файлов глюкнуть.

Полный текст ошибки:
internal gds software consistency check (invalid SEND request(167))

Как только она возникает, сразу же за ней сыпятся
internal gds software consistency check (can't continue after bugcheck)

Вопрос собственно в том, какие действия могут вызвать этот злосчастный invalid SEND request ?

Вопрос собственно в том, какие действия могут вызвать этот злосчастный invalid SEND request ?

а это как раз что-то заколбасило в клиенте FB с тредами.
Контр-вопрос - если это файлики, то зачем их в потоках заливать, да еще потоки синхронизировать? Просто чтобы было "красиво", или как?

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

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

Вот заинтересовала одна фраза уважаемого модератора отсюда

dbhandle:=isc_attach_database ...
TThread.Create
работа в TThread с dbhandle

То есть, если TIBDatabase создавать и коннектиться в основном потоке, а затем создавать дочерний тред и передавать ему уже готовый коннект, то работать должно стабильнее?

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

если TIBDatabase создавать и коннектиться в основном потоке, а затем создавать дочерний тред и передавать ему уже готовый коннект, то работать должно стабильнее?

Не помогло.

Неужели не проще из программы диспетчера запускать внешний экзешник с одним параметром: "имя_файла_откуда_лить_данные"

Была такая мысль, придется у ней вернуться.

Morales писал(а):Есть мнение, что если эти файлы зачитывать параллельно, то на прием информации уйдет меньше времени

Это мнение чем-то подтверждено ? Если потоков > 2xCPU, то толку не будет.
FB 1.5.2, 1.5.3 пробовал ?
Тестовый пример есть ?

Это мнение чем-то подтверждено ? Если потоков > 2xCPU, то толку не будет.

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

FB 1.5.2, 1.5.3 пробовал ?

Пока нет, но кроме этого хочу попробовать еще и FIBPlus.

Чисто опытным путем.

и ... ? Не верю. Ну может быть разница процентов в 10. А FB классик или супер?

FB - super, но это на моем компе, клиентский сервер еще не прибыл. Как только появится будем на нем пробовать по-всякому.

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

Мне надо сейчас добиться стабильной работы. А доводка оптимальных настроек будет производиться уже у клиента.

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

Камнестроители активно двигают в массы дуалкоре чипы, если в серваке двухсокетная мамка и в ней 2 дуалкоре оптерона, прирост будет просто ураган (жаль проверить не на чем... ), разумеется сервер должен быть классик. Ну там еще дисковая должна успевать и памяти хватать...

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

прирост будет просто ураган

о чем ты... для двухядерных процов прирост однозначно меньше чем для двух отдельных процессоров. Для двух отдельных процессоров средний прирост производительности - 1.7. Если сугубо для вычислительных распараллеливаемых задач, то 1.9.

На том же ixbt уже давно полно всяких сравнений двухядерных процов с hyperthreading и раздельными процами.

Все равно если взять 4 полновесных ядра (2 чипа) и программа будет лить данные в дюжину потоков, должен прирост быть в 2-3 раза по сравнению с одним процом. Хотя могут быть другие бутылочные горлышки, кроме производительно процессора(ов)...
to Morales:
А сколько мегабайт и за какое время надо запихнуть в БД?

External tables (внешние таблицы) используются?

должен прирост быть в 2-3 раза по сравнению с одним процом

это предположение или уверенность? кому вообще надо лить данные в БД с такой скоростью, и кто и как потом будет обрабатывать эти данные? Вопросы риторические, потому что разработчик их должен себе задать.

Вот такой дурацкий у меня характер - любые излишне жизнерадостные идеи подвергаю сомнению.

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

А сколько мегабайт и за какое время надо запихнуть в БД?

Мегов 15 примерно. Со временем сложнее. Дело в том, что имеется около трехсот небольших киосков, что-то вроде "Союзпечати". Вечером продажи за день от кассовых аппаратов передаются в главный офис, они-то и заливаются в базу. Программа вкачки данных работает аналогично локальному кассовому аппарату, т.е. только регистрирует их в базе. Дальше вступает в дело основная программа, которая и занимается непосредственно учетом, списывает или возвращает на остаток, при необходимости производит товар, если это бутерброд какой-нть или кофе и т.д. На все про все - ночь. Да еще и бэкап надо успеть сделать. Поэтому чем меньше времени будет приниматься информация, тем лучше.

External tables (внешние таблицы) используются?

Нет.

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

Это где-то 4-5 гиг надо получить и залить? Хм... это какой канал надо в интернет держать и выделенку в каждую точку?