Странное поведение сервера FB

Запросы, планы, оптимизация запросов, ...

Модераторы: kdv, CyberMax

DmitryBelkevich
Сообщения: 30
Зарегистрирован: 03 апр 2009, 21:10
Контактная информация:

Re: Странное поведение сервера FB

Сообщение DmitryBelkevich » 14 апр 2009, 16:21

Убрал slepp'ы, добавил 3 Event'а для синхронизации. Добавил Read в транзакцию. Всё без изменений. Скорость добавления достаточно быстро деградирует - с 8-9 фпс до 1-2.

Можно ли как-то узнать в каком состоянии находится база? Происходит сборка мусора, sweep, или еще каки-то внутренние механизмы?

kdv
Forum Admin
Сообщения: 6575
Зарегистрирован: 25 окт 2004, 18:07
Контактная информация:

Re: Странное поведение сервера FB

Сообщение kdv » 14 апр 2009, 18:21

Можно ли как-то узнать в каком состоянии находится база? Происходит сборка мусора, sweep, или еще каки-то внутренние механизмы?
IBAnalyst, mon$

DmitryBelkevich
Сообщения: 30
Зарегистрирован: 03 апр 2009, 21:10
Контактная информация:

Re: Странное поведение сервера FB

Сообщение DmitryBelkevich » 27 апр 2009, 15:04

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 'висит') коммитится.

kdv
Forum Admin
Сообщения: 6575
Зарегистрирован: 25 окт 2004, 18:07
Контактная информация:

Re: Странное поведение сервера FB

Сообщение kdv » 01 май 2009, 18:30

Mon$, к сожалению, не нашел. Название плохо поддающееся поиску.
трудно что-то объяснять, если Вы не читали release notes к используемой СУБД.
У меня используется одна IBStoredProc в треде. Может быть из-за неё проблемы?
и зачем он используется? Вся статья ibstp.htm, а также ibx.htm говорят о том, что использовать IBStoredProc не нужно.
В конце неё стоит suspend.
надеюсь, в вызываемой процедуре, которая вызывается через select, а не в той, которую вызывает IBStoredProc?

DmitryBelkevich
Сообщения: 30
Зарегистрирован: 03 апр 2009, 21:10
Контактная информация:

Re: Странное поведение сервера FB

Сообщение DmitryBelkevich » 02 май 2009, 12:11

kdv писал(а):трудно что-то объяснять, если Вы не читали release notes к используемой СУБД.
Да я как бы без претензий. Release notes посмотрю, спасибо.
kdv писал(а):и зачем он используется? Вся статья ibstp.htm, а также ibx.htm говорят о том, что использовать IBStoredProc не нужно.
Ну это я уже после увидел :) Раньше статью не видел. Что делать, если ХП ничего не возвращает? Создавать фэйковый параметр?
kdv писал(а):надеюсь, в вызываемой процедуре, которая вызывается через select, а не в той, которую вызывает IBStoredProc?
Да, именно так.

kdv
Forum Admin
Сообщения: 6575
Зарегистрирован: 25 окт 2004, 18:07
Контактная информация:

Re: Странное поведение сервера FB

Сообщение kdv » 02 май 2009, 20:30

Что делать, если ХП ничего не возвращает? Создавать фэйковый параметр?
да боже упаси. я не понял Ваш вопрос насчет "что делать". Вы не представляете себе, как вызвать процедуру не пользуясь IBStoredProc? Тем более если она ничего не возвращает? читайте тогда тут
http://www.ibase.ru/devinfo/ibx.htm#ibstoredproc

DmitryBelkevich
Сообщения: 30
Зарегистрирован: 03 апр 2009, 21:10
Контактная информация:

Re: Странное поведение сервера FB

Сообщение DmitryBelkevich » 03 май 2009, 01:44

Select'ом знаю как. Если процедура ничего не возвращает, select возвращает ошибку "procedure MOVE_FILES_LENGTH does not return any values.". Фэйковый параметр помогает. Но не знаю, насколько это хорошее решение.

Фанис
Сообщения: 17
Зарегистрирован: 16 июн 2005, 19:28

Re: Странное поведение сервера FB

Сообщение Фанис » 03 май 2009, 10:11

1. Что таки делает 1 поток
2. Нафига нужет 2?

Можно внятно, без хитростей изложить суть задачи - мне кажется, что собака зарыта не в "странностях FB"

Dimitry Sibiryakov
Заслуженный разработчик
Сообщения: 1427
Зарегистрирован: 15 сен 2005, 09:05
Откуда: Krupka
Контактная информация:

Re: Странное поведение сервера FB

Сообщение Dimitry Sibiryakov » 03 май 2009, 12:31

Если учесть, что аффтар про SELECT - знает, а про EXECUTE PROCEDURE - нет, то "кажется" перерастает практически в уверенность.

Фанис
Сообщения: 17
Зарегистрирован: 16 июн 2005, 19:28

Re: Странное поведение сервера FB

Сообщение Фанис » 03 май 2009, 16:02

Автору сабжа - посмотри на http://www.overbyte.be/frame_index.html
Сие поможет организовать аналог 1 потока - как понимаю, это сборщик "пакетов".
Кстати, перечитал ветку и вроде понял - это доморощенный "документооборот", размазанный по "Моим документам" компов одноранговой сети? Валидность ссылки на файл - if FileExists?
Не стучи в бубен, колись.

DmitryBelkevich
Сообщения: 30
Зарегистрирован: 03 апр 2009, 21:10
Контактная информация:

Re: Странное поведение сервера FB

Сообщение DmitryBelkevich » 03 май 2009, 23:10

про SELECT - знает, а про EXECUTE PROCEDURE - нет
Честно признаюсь. Не знаю. Спасибо, посмотрю.
это доморощенный "документооборот", размазанный по "Моим документам" компов одноранговой сет
Колюсь. Сиситема называется 'PACS' Picture Archiving System. В базе, среди прочего, лежат ссылки на картинки. Сами картинки лежат по 'томам' - шарам или локальным папкам. Первый поток занимается добавлением в базу этих самых картинок (принятых другими потоками, вообще с базой не связанными). Второй - перенесением их с тома на том. Линки должны быть всегда валидными (предполагается, что система работает в безостановочном режиме). Эти файлы, по своему протоколу, могут быть запрошены в любой момент времени, другими станциями. Запросные потоки не зависят от этих двух потоков и от приёмных - это отдельные потоки. Они в баге никак не участвуют, потому не описаны.

Первый поток работает всегда автоматически, по мере приёма файлов (в остальное время - спит), по некоторой логике 'раскладывает' их по 'томам' и добавляет записи о файлах в базу. Второй поток инициализирует юзер, либо по мере заполнения 'тома', либо по еще каким-то юзерским причинам. Создаётся и запускается через гуй.
странностях FB
Я не говорю, что виновник проблемы - однозначно сервер fb. Возможно, и, вполне вероятно, что проблема на моей стороне. Но пока, к сожалению, не могу найти, где именно.
Валидность ссылки на файл - if FileExists?
Валидность ссылки - это то, что этот файл можно с этого линка 'забрать' и отдать по своему, специфическому, протоколу 'наружу'. Временная недоступность файла на стирание роли не играет (для этого есть отдельные инструменты). Главное - это постоянная доступность его на чтение.

DmitryBelkevich
Сообщения: 30
Зарегистрирован: 03 апр 2009, 21:10
Контактная информация:

Re: Странное поведение сервера FB

Сообщение DmitryBelkevich » 04 май 2009, 17:40

Убрал IBStoredProc. Посмотрим на поведение...

Фанис
Сообщения: 17
Зарегистрирован: 16 июн 2005, 19:28

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 - проверено.

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Re: Странное поведение сервера FB

Сообщение WildSery » 05 май 2009, 15:44

Фанис писал(а):Лучший MD5 в ICS - проверено.
Насчёт "двух пальцев" - до первой коллизии. Их по-любому нужно разруливать, рано или поздно возникнут.

Фанис
Сообщения: 17
Зарегистрирован: 16 июн 2005, 19:28

Re: Странное поведение сервера FB

Сообщение Фанис » 05 май 2009, 16:16

Насчёт "двух пальцев" - до первой коллизии. Их по-любому нужно разруливать, рано или поздно возникнут.
То-то и оно, что - если вчитаться в мое решение, а оно вроде должно соответствовать предъявленной автором сабжа Picture Archiving System, то коллизиям нет места. Я предлагаю избавиться от неопределенности в наличии некоего файла, ссылка на который есть в базе данных путем сохранения образа это файла. Посему здесь потоки вообще не нужны.

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Re: Странное поведение сервера FB

Сообщение WildSery » 05 май 2009, 17:06

А, извини, я процитировал не совсем то. Неприятие возникло к словам "посему делаем это поле уникальным" :)

DmitryBelkevich
Сообщения: 30
Зарегистрирован: 03 апр 2009, 21:10
Контактная информация:

Re: Странное поведение сервера FB

Сообщение DmitryBelkevich » 05 май 2009, 23:08

А кто отправляет 1 потоку "файлы"?
Принятые файлы приёмными потоками складываются во временной папке, есть потоконезависимый список, куда помещаются ссылки на принятые файлы. 1 поток забирает имена файлов из этого списка, парсит файл, переносит его на постоянное место хранения - том. Юзеры же могут эти файлы переносить с тома на том, по надобности. Для этого и организован 2-й поток.
1. Мне кажется, что здесь есть кривости - собирать в базе нечто уже неактуальное по своей природе не стоит,
Неактуальность отсутствует. Линк на файл, как я говорил, предполагается быть всегда валидным. Даже во время многоэтапного переноса.
data as_blob
Вы предлагаете хранить файлы в базе? У нас объёмы большие.
hmd5 - хэш файла
Вообще - проблемы с поиском и однозначной идентификацией файлов нет.

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

DmitryBelkevich
Сообщения: 30
Зарегистрирован: 03 апр 2009, 21:10
Контактная информация:

Re: Странное поведение сервера FB

Сообщение DmitryBelkevich » 02 окт 2009, 20:47

Возвращаясь к теме.

На этой же базе замеченно странное поведение сервера даже без нашего софта.

Что делал.

Базу почти полностью почистил. Сделал backup/restore базы. Переустановил FB (напоминаю, ставлю Firebird-2.1.1.17910-0_Win32.exe).

Что происходит.

Коннекчусь к базе с помощью IBExpert'а (v. 2009.03.17.2). Сервер начинает отъедать 80-90% времени одного из процессоров. Отсоединяюсь от базы. Сервер продолжает занимать процессор до перезапуска. Файл базы данных при это зашарен на запись (проверяю переименовыванием).

Выкладываю базу и бакап базы (90 кБ): http://slil.ru/28037635

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48
Контактная информация:

Re: Странное поведение сервера FB

Сообщение hvlad » 02 окт 2009, 22:22

И какой умник поставил sweep_interval в 1 ? :shock: :twisted:

DmitryBelkevich
Сообщения: 30
Зарегистрирован: 03 апр 2009, 21:10
Контактная информация:

Re: Странное поведение сервера FB

Сообщение DmitryBelkevich » 02 окт 2009, 22:48

:oops:

Сорри :) Менял в тестовых целях, забыл назад поменять...

Ответить

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость