Странное поведение сервера FB
-
- Сообщения: 30
- Зарегистрирован: 03 апр 2009, 21:10
Re: Странное поведение сервера FB
Убрал slepp'ы, добавил 3 Event'а для синхронизации. Добавил Read в транзакцию. Всё без изменений. Скорость добавления достаточно быстро деградирует - с 8-9 фпс до 1-2.
Можно ли как-то узнать в каком состоянии находится база? Происходит сборка мусора, sweep, или еще каки-то внутренние механизмы?
Можно ли как-то узнать в каком состоянии находится база? Происходит сборка мусора, sweep, или еще каки-то внутренние механизмы?
Re: Странное поведение сервера FB
IBAnalyst, mon$Можно ли как-то узнать в каком состоянии находится база? Происходит сборка мусора, sweep, или еще каки-то внутренние механизмы?
-
- Сообщения: 30
- Зарегистрирован: 03 апр 2009, 21:10
Re: Странное поведение сервера FB
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 'висит') коммитится.
Сегодня при очередном тесте вылезла чудная ошибка:
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
трудно что-то объяснять, если Вы не читали release notes к используемой СУБД.Mon$, к сожалению, не нашел. Название плохо поддающееся поиску.
и зачем он используется? Вся статья ibstp.htm, а также ibx.htm говорят о том, что использовать IBStoredProc не нужно.У меня используется одна IBStoredProc в треде. Может быть из-за неё проблемы?
надеюсь, в вызываемой процедуре, которая вызывается через select, а не в той, которую вызывает IBStoredProc?В конце неё стоит suspend.
-
- Сообщения: 30
- Зарегистрирован: 03 апр 2009, 21:10
Re: Странное поведение сервера FB
Да я как бы без претензий. Release notes посмотрю, спасибо.kdv писал(а):трудно что-то объяснять, если Вы не читали release notes к используемой СУБД.
Ну это я уже после увидел Раньше статью не видел. Что делать, если ХП ничего не возвращает? Создавать фэйковый параметр?kdv писал(а):и зачем он используется? Вся статья ibstp.htm, а также ibx.htm говорят о том, что использовать IBStoredProc не нужно.
Да, именно так.kdv писал(а):надеюсь, в вызываемой процедуре, которая вызывается через select, а не в той, которую вызывает IBStoredProc?
Re: Странное поведение сервера FB
да боже упаси. я не понял Ваш вопрос насчет "что делать". Вы не представляете себе, как вызвать процедуру не пользуясь IBStoredProc? Тем более если она ничего не возвращает? читайте тогда тутЧто делать, если ХП ничего не возвращает? Создавать фэйковый параметр?
http://www.ibase.ru/devinfo/ibx.htm#ibstoredproc
-
- Сообщения: 30
- Зарегистрирован: 03 апр 2009, 21:10
Re: Странное поведение сервера FB
Select'ом знаю как. Если процедура ничего не возвращает, select возвращает ошибку "procedure MOVE_FILES_LENGTH does not return any values.". Фэйковый параметр помогает. Но не знаю, насколько это хорошее решение.
Re: Странное поведение сервера FB
1. Что таки делает 1 поток
2. Нафига нужет 2?
Можно внятно, без хитростей изложить суть задачи - мне кажется, что собака зарыта не в "странностях FB"
2. Нафига нужет 2?
Можно внятно, без хитростей изложить суть задачи - мне кажется, что собака зарыта не в "странностях FB"
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Re: Странное поведение сервера FB
Если учесть, что аффтар про SELECT - знает, а про EXECUTE PROCEDURE - нет, то "кажется" перерастает практически в уверенность.
Re: Странное поведение сервера FB
Автору сабжа - посмотри на http://www.overbyte.be/frame_index.html
Сие поможет организовать аналог 1 потока - как понимаю, это сборщик "пакетов".
Кстати, перечитал ветку и вроде понял - это доморощенный "документооборот", размазанный по "Моим документам" компов одноранговой сети? Валидность ссылки на файл - if FileExists?
Не стучи в бубен, колись.
Сие поможет организовать аналог 1 потока - как понимаю, это сборщик "пакетов".
Кстати, перечитал ветку и вроде понял - это доморощенный "документооборот", размазанный по "Моим документам" компов одноранговой сети? Валидность ссылки на файл - if FileExists?
Не стучи в бубен, колись.
-
- Сообщения: 30
- Зарегистрирован: 03 апр 2009, 21:10
Re: Странное поведение сервера FB
Честно признаюсь. Не знаю. Спасибо, посмотрю.про SELECT - знает, а про EXECUTE PROCEDURE - нет
Колюсь. Сиситема называется 'PACS' Picture Archiving System. В базе, среди прочего, лежат ссылки на картинки. Сами картинки лежат по 'томам' - шарам или локальным папкам. Первый поток занимается добавлением в базу этих самых картинок (принятых другими потоками, вообще с базой не связанными). Второй - перенесением их с тома на том. Линки должны быть всегда валидными (предполагается, что система работает в безостановочном режиме). Эти файлы, по своему протоколу, могут быть запрошены в любой момент времени, другими станциями. Запросные потоки не зависят от этих двух потоков и от приёмных - это отдельные потоки. Они в баге никак не участвуют, потому не описаны.это доморощенный "документооборот", размазанный по "Моим документам" компов одноранговой сет
Первый поток работает всегда автоматически, по мере приёма файлов (в остальное время - спит), по некоторой логике 'раскладывает' их по 'томам' и добавляет записи о файлах в базу. Второй поток инициализирует юзер, либо по мере заполнения 'тома', либо по еще каким-то юзерским причинам. Создаётся и запускается через гуй.
Я не говорю, что виновник проблемы - однозначно сервер fb. Возможно, и, вполне вероятно, что проблема на моей стороне. Но пока, к сожалению, не могу найти, где именно.странностях FB
Валидность ссылки - это то, что этот файл можно с этого линка 'забрать' и отдать по своему, специфическому, протоколу 'наружу'. Временная недоступность файла на стирание роли не играет (для этого есть отдельные инструменты). Главное - это постоянная доступность его на чтение.Валидность ссылки на файл - if FileExists?
-
- Сообщения: 30
- Зарегистрирован: 03 апр 2009, 21:10
Re: Странное поведение сервера FB
Убрал IBStoredProc. Посмотрим на поведение...
Re: Странное поведение сервера FB
А кто отправляет 1 потоку "файлы"?
1. Мне кажется, что здесь есть кривости - собирать в базе нечто уже неактуальное по своей природе не стоит, но если попробовать типа
id integer,
file_name as_string127,
file_type integer,
hmd5 as_string32,
data as_blob)
то задача упрощается до неприличного "как два пальца ..."
hmd5 - хэш файла - как не назови файл - он будет неизменен, посему делаем это поле уникальным. Далее некая процедура отправляет данные через обычный IBSQL в ХП типа
Короче - здесь в БД сохраняется образы файлов со всеми вытекающими.
Лучший MD5 в ICS - проверено.
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
Насчёт "двух пальцев" - до первой коллизии. Их по-любому нужно разруливать, рано или поздно возникнут.Фанис писал(а):Лучший MD5 в ICS - проверено.
Re: Странное поведение сервера FB
То-то и оно, что - если вчитаться в мое решение, а оно вроде должно соответствовать предъявленной автором сабжа Picture Archiving System, то коллизиям нет места. Я предлагаю избавиться от неопределенности в наличии некоего файла, ссылка на который есть в базе данных путем сохранения образа это файла. Посему здесь потоки вообще не нужны.Насчёт "двух пальцев" - до первой коллизии. Их по-любому нужно разруливать, рано или поздно возникнут.
Re: Странное поведение сервера FB
А, извини, я процитировал не совсем то. Неприятие возникло к словам "посему делаем это поле уникальным"
-
- Сообщения: 30
- Зарегистрирован: 03 апр 2009, 21:10
Re: Странное поведение сервера FB
Принятые файлы приёмными потоками складываются во временной папке, есть потоконезависимый список, куда помещаются ссылки на принятые файлы. 1 поток забирает имена файлов из этого списка, парсит файл, переносит его на постоянное место хранения - том. Юзеры же могут эти файлы переносить с тома на том, по надобности. Для этого и организован 2-й поток.А кто отправляет 1 потоку "файлы"?
Неактуальность отсутствует. Линк на файл, как я говорил, предполагается быть всегда валидным. Даже во время многоэтапного переноса.1. Мне кажется, что здесь есть кривости - собирать в базе нечто уже неактуальное по своей природе не стоит,
Вы предлагаете хранить файлы в базе? У нас объёмы большие.data as_blob
Вообще - проблемы с поиском и однозначной идентификацией файлов нет.hmd5 - хэш файла
После тестов, если ничего не изменится, постараюсь 'выкристализовать' баг из кода. Выложу на обозрение, если удастся.
-
- Сообщения: 30
- Зарегистрирован: 03 апр 2009, 21:10
Re: Странное поведение сервера FB
Возвращаясь к теме.
На этой же базе замеченно странное поведение сервера даже без нашего софта.
Что делал.
Базу почти полностью почистил. Сделал backup/restore базы. Переустановил FB (напоминаю, ставлю Firebird-2.1.1.17910-0_Win32.exe).
Что происходит.
Коннекчусь к базе с помощью IBExpert'а (v. 2009.03.17.2). Сервер начинает отъедать 80-90% времени одного из процессоров. Отсоединяюсь от базы. Сервер продолжает занимать процессор до перезапуска. Файл базы данных при это зашарен на запись (проверяю переименовыванием).
Выкладываю базу и бакап базы (90 кБ): http://slil.ru/28037635
На этой же базе замеченно странное поведение сервера даже без нашего софта.
Что делал.
Базу почти полностью почистил. Сделал 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
И какой умник поставил sweep_interval в 1 ?
-
- Сообщения: 30
- Зарегистрирован: 03 апр 2009, 21:10
Re: Странное поведение сервера FB
Сорри Менял в тестовых целях, забыл назад поменять...