internal gds software consistency check (invalid SEND reques

Access Violation, некорректное выполнение запросов или вызовов API, ошибки утилит командной строки, в общем все, что вам мешает работать

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

Ответить
SZeman
Сообщения: 39
Зарегистрирован: 20 июл 2005, 12:46

internal gds software consistency check (invalid SEND reques

Сообщение SZeman » 14 апр 2011, 15:13

Доброго времени суток.
при увеличении количества активно пишущих и читающих клиентов в два раза около (13-14) в логе FB появились ошибки. Все клиенты работают на сервере, параллельно. Читают и пишут данные из одних и тех же таблиц.
internal gds software consistency check (invalid SEND request (167))
иногда встречаются записи типа:
INET/inet_error: connect errno = 10061
Компьютер:
Windows XP SP3 (32)
Core 2 Duo
4Гб ОЗУ
160 Гб HDD – NTFS (4K)
FB 1.5.5.4926 SS
Размер страницы БД 4096
Параметры в firebird.conf стандартные из умолчания. Единственное изменение - указан порт для событий 3051.
Вопрос: можно ли сделать настройки в FB чтобы убрать ошибки? Или что может вызывать данные ошибки?
Скорее всего это было причиной разрушения БД (internal gds software consistency check (cannot find record back version (291)). Базу восстановили из резервной копии. Хотелось уверенности что не упадет снова. Подскажите в какую сторону посмотреть.

SZeman
Сообщения: 39
Зарегистрирован: 20 июл 2005, 12:46

Re: internal gds software consistency check (invalid SEND re

Сообщение SZeman » 14 апр 2011, 15:16

На сервере работает 5 баз

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

Re: internal gds software consistency check (invalid SEND re

Сообщение hvlad » 14 апр 2011, 16:02

SZeman писал(а):internal gds software consistency check (invalid SEND request (167))
Попытка передать входные параметры запросу, который их не ожидает.
Либо попытка выполнить процедуру\триггер при её\его параллельном удалении\альтере.
SZeman писал(а):Скорее всего это было причиной разрушения БД (internal gds software consistency check (cannot find record back version (291)).
Вряд ли.
SZeman писал(а):Подскажите в какую сторону посмотреть.
1.5.х уже давно не поддерживается. Так что даже если в нём есть баг, исправляться он не будет.
Разве что вы кого-то наймёте это сделать.
Можно попробовать обновиться на 1.5.6, но лучше на более актуальную версию.

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

Re: internal gds software consistency check (invalid SEND re

Сообщение kdv » 14 апр 2011, 23:53

мой совет - чините или тестируйте железо. "Сервер" на WinXP на котором 5 баз - это стыдоба. Значит, ваши данные не стоят ни копейки.

SZeman
Сообщения: 39
Зарегистрирован: 20 июл 2005, 12:46

Re: internal gds software consistency check (invalid SEND re

Сообщение SZeman » 15 апр 2011, 10:12

Спасибо за ответы.
Компьютер рабочий до увеличения количества одновременно пишущих клиентов был стабилен. Слабое место это сеть. На компьютере используются сетевые COM порты, доступ до которых по беспроводной сети. Возможно комп находится в аномальной зоне – был замечен в перезагрузке. ИБП стоит. Однако при отправке его на стендовые испытания проблем с перезагрузками не замечается. Для предотвращения отвалов по TCP установлен «адаптер замыкания на себя».
Извиняюсь за вопрос. Почему «Значит, ваши данные не стоят ни копейки»? Из 5-ти баз две - десятки МБ, две – сотни МБ, одна – от 100 МБ до 2,5 ГБ. Не сказать, что огромные и не под силу такому компьютеру. Там раньше около 3-х лет стоял сервер HP, сейчас он в ремонтах. К слову, новый c XP работает с шустрее.
Еще раз большое спасибо за помощь. Будем рассматривать вариант перехода на ФБ 2.5.

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

Re: internal gds software consistency check (invalid SEND re

Сообщение kdv » 15 апр 2011, 12:33

Почему «Значит, ваши данные не стоят ни копейки»?
то что вы перечислили в характеристиках компьютера - не сервер. Это худой десктопный комп. Я не спорю, что ФБ может при вашей нагрузке вполне нормально обслуживать 5 баз (и 10 баз) на таком компьютере, но обычно, когда данные имеют какую-то ценность, реальные деньги вкладывают в обеспечение сохранности этих данных.
Это может выражаться в организации резервного копирования, Raid, использования более качественного железа, и т.д. Просто, мы же ремонтируем базы InterBase и Firebird, и бывают случаи, когда ремонтировать-то нечего. И бэкапов нет (или они были на том же умершем диске где и база). Вот и получается, что данные были "очень важные и дорогие", только их теперь нет.

Ответить