Страница 2 из 3
Re: Странное поведение сервера FB
Добавлено: 14 апр 2009, 16:21
DmitryBelkevich
Убрал slepp'ы, добавил 3 Event'а для синхронизации. Добавил Read в транзакцию. Всё без изменений. Скорость добавления достаточно быстро деградирует - с 8-9 фпс до 1-2.
Можно ли как-то узнать в каком состоянии находится база? Происходит сборка мусора, sweep, или еще каки-то внутренние механизмы?
Re: Странное поведение сервера FB
Добавлено: 14 апр 2009, 18:21
kdv
Можно ли как-то узнать в каком состоянии находится база? Происходит сборка мусора, sweep, или еще каки-то внутренние механизмы?
IBAnalyst, mon$
Re: Странное поведение сервера FB
Добавлено: 27 апр 2009, 15:04
DmitryBelkevich
IBAnalyst пока никакой особенной крамолы не показал, хотя я пока сильно им базу не гонял. Mon$, к сожалению, не нашел. Название плохо поддающееся поиску.
Сегодня при очередном тесте вылезла чудная ошибка:
Dynamic SQL Error SQL error code = -804 SQLDA missing or incorrect version, or incorrect number/type of variables
Статью
http://www.ibase.ru/devinfo/ibstp.htm прочитал.
У меня используется одна IBStoredProc в треде. Может быть из-за неё проблемы?
Версия IBX'ов - 7.11. Использую последний FB, как уже писал. Prepare/unprepare не делаю. Эта процедура внутри себя вызывает другую - GET_SHARE_SIZE. В конце неё стоит suspend. Сразу после процедуры пишущая транзакция (на ней в т.ч. и эта IBStoredProc 'висит') коммитится.
Re: Странное поведение сервера FB
Добавлено: 01 май 2009, 18:30
kdv
Mon$, к сожалению, не нашел. Название плохо поддающееся поиску.
трудно что-то объяснять, если Вы не читали release notes к используемой СУБД.
У меня используется одна IBStoredProc в треде. Может быть из-за неё проблемы?
и зачем он используется? Вся статья ibstp.htm, а также ibx.htm говорят о том, что использовать IBStoredProc не нужно.
В конце неё стоит suspend.
надеюсь, в вызываемой процедуре, которая вызывается через select, а не в той, которую вызывает IBStoredProc?
Re: Странное поведение сервера FB
Добавлено: 02 май 2009, 12:11
DmitryBelkevich
kdv писал(а):трудно что-то объяснять, если Вы не читали release notes к используемой СУБД.
Да я как бы без претензий. Release notes посмотрю, спасибо.
kdv писал(а):и зачем он используется? Вся статья ibstp.htm, а также ibx.htm говорят о том, что использовать IBStoredProc не нужно.
Ну это я уже после увидел
Раньше статью не видел. Что делать, если ХП ничего не возвращает? Создавать фэйковый параметр?
kdv писал(а):надеюсь, в вызываемой процедуре, которая вызывается через select, а не в той, которую вызывает IBStoredProc?
Да, именно так.
Re: Странное поведение сервера FB
Добавлено: 02 май 2009, 20:30
kdv
Что делать, если ХП ничего не возвращает? Создавать фэйковый параметр?
да боже упаси. я не понял Ваш вопрос насчет "что делать". Вы не представляете себе, как вызвать процедуру не пользуясь IBStoredProc? Тем более если она ничего не возвращает? читайте тогда тут
http://www.ibase.ru/devinfo/ibx.htm#ibstoredproc
Re: Странное поведение сервера FB
Добавлено: 03 май 2009, 01:44
DmitryBelkevich
Select'ом знаю как. Если процедура ничего не возвращает, select возвращает ошибку "procedure MOVE_FILES_LENGTH does not return any values.". Фэйковый параметр помогает. Но не знаю, насколько это хорошее решение.
Re: Странное поведение сервера FB
Добавлено: 03 май 2009, 10:11
Фанис
1. Что таки делает 1 поток
2. Нафига нужет 2?
Можно внятно, без хитростей изложить суть задачи - мне кажется, что собака зарыта не в "странностях FB"
Re: Странное поведение сервера FB
Добавлено: 03 май 2009, 12:31
Dimitry Sibiryakov
Если учесть, что аффтар про SELECT - знает, а про EXECUTE PROCEDURE - нет, то "кажется" перерастает практически в уверенность.
Re: Странное поведение сервера FB
Добавлено: 03 май 2009, 16:02
Фанис
Автору сабжа - посмотри на
http://www.overbyte.be/frame_index.html
Сие поможет организовать аналог 1 потока - как понимаю, это сборщик "пакетов".
Кстати, перечитал ветку и вроде понял - это доморощенный "документооборот", размазанный по "Моим документам" компов одноранговой сети? Валидность ссылки на файл - if FileExists?
Не стучи в бубен, колись.
Re: Странное поведение сервера FB
Добавлено: 03 май 2009, 23:10
DmitryBelkevich
про SELECT - знает, а про EXECUTE PROCEDURE - нет
Честно признаюсь. Не знаю. Спасибо, посмотрю.
это доморощенный "документооборот", размазанный по "Моим документам" компов одноранговой сет
Колюсь. Сиситема называется 'PACS' Picture Archiving System. В базе, среди прочего, лежат ссылки на картинки. Сами картинки лежат по 'томам' - шарам или локальным папкам. Первый поток занимается добавлением в базу этих самых картинок (принятых другими потоками, вообще с базой не связанными). Второй - перенесением их с тома на том. Линки должны быть всегда валидными (предполагается, что система работает в безостановочном режиме). Эти файлы, по своему протоколу, могут быть запрошены в любой момент времени, другими станциями. Запросные потоки не зависят от этих двух потоков и от приёмных - это отдельные потоки. Они в баге никак не участвуют, потому не описаны.
Первый поток работает всегда автоматически, по мере приёма файлов (в остальное время - спит), по некоторой логике 'раскладывает' их по 'томам' и добавляет записи о файлах в базу. Второй поток инициализирует юзер, либо по мере заполнения 'тома', либо по еще каким-то юзерским причинам. Создаётся и запускается через гуй.
странностях FB
Я не говорю, что виновник проблемы - однозначно сервер fb. Возможно, и, вполне вероятно, что проблема на моей стороне. Но пока, к сожалению, не могу найти, где именно.
Валидность ссылки на файл - if FileExists?
Валидность ссылки - это то, что этот файл можно с этого линка 'забрать' и отдать по своему, специфическому, протоколу 'наружу'. Временная недоступность файла на стирание роли не играет (для этого есть отдельные инструменты). Главное - это постоянная доступность его на чтение.
Re: Странное поведение сервера FB
Добавлено: 04 май 2009, 17:40
DmitryBelkevich
Убрал IBStoredProc. Посмотрим на поведение...
Re: Странное поведение сервера FB
Добавлено: 05 май 2009, 14:44
Фанис
А кто отправляет 1 потоку "файлы"?
1. Мне кажется, что здесь есть кривости - собирать в базе нечто уже неактуальное по своей природе не стоит, но если попробовать типа
id integer,
file_name as_string127,
file_type integer,
hmd5 as_string32,
data as_blob)
то задача упрощается до неприличного "как два пальца ..."
hmd5 - хэш файла - как не назови файл - он будет неизменен, посему делаем это поле уникальным. Далее некая процедура отправляет данные через обычный IBSQL в ХП типа
Код: Выделить всё
CREATE OR ALTER PROCEDURE SET_NEW_FILE(
MD VARCHAR(32),
......)
AS
DECLARE VARIABLE ID INTEGER;
BEGIN
select id from MY_FILES where md=:MD into :ID;
if (ID IS NULL) then
BEGIN
ID=GEN_ID(GEN_MY_FILES,1);
INSERT INTO MY_FILES (ID,MD,....) VALUES (:ID,:MD,......;
END
Короче - здесь в БД сохраняется образы файлов со всеми вытекающими.
Лучший MD5 в ICS - проверено.
Re: Странное поведение сервера FB
Добавлено: 05 май 2009, 15:44
WildSery
Фанис писал(а):Лучший MD5 в ICS - проверено.
Насчёт "двух пальцев" - до первой коллизии. Их по-любому нужно разруливать, рано или поздно возникнут.
Re: Странное поведение сервера FB
Добавлено: 05 май 2009, 16:16
Фанис
Насчёт "двух пальцев" - до первой коллизии. Их по-любому нужно разруливать, рано или поздно возникнут.
То-то и оно, что - если вчитаться в мое решение, а оно вроде должно соответствовать предъявленной автором сабжа Picture Archiving System, то коллизиям нет места. Я предлагаю избавиться от неопределенности в наличии некоего файла, ссылка на который есть в базе данных путем сохранения образа это файла. Посему здесь потоки вообще не нужны.
Re: Странное поведение сервера FB
Добавлено: 05 май 2009, 17:06
WildSery
А, извини, я процитировал не совсем то. Неприятие возникло к словам "посему делаем это поле уникальным"
Re: Странное поведение сервера FB
Добавлено: 05 май 2009, 23:08
DmitryBelkevich
А кто отправляет 1 потоку "файлы"?
Принятые файлы приёмными потоками складываются во временной папке, есть потоконезависимый список, куда помещаются ссылки на принятые файлы. 1 поток забирает имена файлов из этого списка, парсит файл, переносит его на постоянное место хранения - том. Юзеры же могут эти файлы переносить с тома на том, по надобности. Для этого и организован 2-й поток.
1. Мне кажется, что здесь есть кривости - собирать в базе нечто уже неактуальное по своей природе не стоит,
Неактуальность отсутствует. Линк на файл, как я говорил, предполагается быть всегда валидным. Даже во время многоэтапного переноса.
data as_blob
Вы предлагаете хранить файлы в базе? У нас объёмы большие.
hmd5 - хэш файла
Вообще - проблемы с поиском и однозначной идентификацией файлов нет.
После тестов, если ничего не изменится, постараюсь 'выкристализовать' баг из кода. Выложу на обозрение, если удастся.
Re: Странное поведение сервера FB
Добавлено: 02 окт 2009, 20:47
DmitryBelkevich
Возвращаясь к теме.
На этой же базе замеченно странное поведение сервера даже без нашего софта.
Что делал.
Базу почти полностью почистил. Сделал backup/restore базы. Переустановил FB (напоминаю, ставлю Firebird-2.1.1.17910-0_Win32.exe).
Что происходит.
Коннекчусь к базе с помощью IBExpert'а (v. 2009.03.17.2). Сервер начинает отъедать 80-90% времени одного из процессоров. Отсоединяюсь от базы. Сервер продолжает занимать процессор до перезапуска. Файл базы данных при это зашарен на запись (проверяю переименовыванием).
Выкладываю базу и бакап базы (90 кБ):
http://slil.ru/28037635
Re: Странное поведение сервера FB
Добавлено: 02 окт 2009, 22:22
hvlad
И какой умник поставил sweep_interval в 1 ?
Re: Странное поведение сервера FB
Добавлено: 02 окт 2009, 22:48
DmitryBelkevich
Сорри
Менял в тестовых целях, забыл назад поменять...