deadlock'и при обрывах коннекта

Администирование клиентской и серверной части InterBase, Firebird, Yaffil. Настройка файла конфигурации и т.п.

Модераторы: kdv, Alexey Kovyazin

vik
Сообщения: 31
Зарегистрирован: 29 янв 2008, 21:48

deadlock'и при обрывах коннекта

Сообщение vik » 12 авг 2008, 14:24

Добрый день
Есть система на FB 2.1.0 классик, постоянно подключено и работают 7-8 клиентов. У клиентов стали появляться ошибки вроде "deadlock update conflicts with concurrent update page size parameter missing" и "deadlock update conflicts with concurrent update unknown ISC error 335544878" с регулярностью от 2 до 20 раз в день. В логе птицы - "INET/inet_error: send errno = 10054", "INET/inet_error: connect errno = 10061", "SERVER/process_packet: broken port, server exiting", хотя по времени они не совсем совпадают с временем записей в логах клиентов.

Если я правильно понимаю, то суть проблемы в том что происходят кратковременные потери коннекта, после чего зависают незакрытые транзакции. Так ли это?

Про keepalive читал, но дело в том, что мне нужно моментально отреагировать на ситуацию в клиентском приложении. Для оператора ждать минуту или даже полминуты очень нехорошо. Т.е. моя задача в том, чтобы настроить сервак/локалку/изменить систему/др.варианты, так чтобы требуемые операции выполнялись в штатном режиме, в т.ч. при кратковременных потерях конекта. Куда посоветуете копать?
спс

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

Сообщение WildSery » 12 авг 2008, 14:56

Я бы начал с того, чтоб клиента правильно установил, и тогда не было б "unknown ISC error 335544878"

vik
Сообщения: 31
Зарегистрирован: 29 янв 2008, 21:48

Сообщение vik » 12 авг 2008, 17:54

WildSery писал(а):Я бы начал с того, чтоб клиента правильно установил, и тогда не было б "unknown ISC error 335544878"
в смысле? какого клиента и что значит правильно?

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

Сообщение WildSery » 12 авг 2008, 18:39

Обычного, клиента Firebird.
Тогда и сообщение об ошибке будет нормальным, а не это нечто.

vik
Сообщения: 31
Зарегистрирован: 29 янв 2008, 21:48

Сообщение vik » 12 авг 2008, 22:42

Переставил на серваке последнюю версию птицы, все checkbox в инсталяхе = true. Для эксперимента поставил супер вместо классика (было предположение что дедлоки появились после перехода на классик). В conf от стандартного отличается:
DefaultDbCachePages = 11264
LockMemSize = 16777216
Это является "правильной установкой"?

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

Сообщение dimitr » 13 авг 2008, 09:08

vik писал(а):Переставил на серваке
тебе про клиента говорят, а ты сервак переставляешь. Найди все fbclient.dll на клиентских машинах и убедись, что они версии не ниже 2.1.0.

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

Re: deadlock'и при обрывах коннекта

Сообщение dimitr » 13 авг 2008, 09:15

vik писал(а):У клиентов стали появляться ошибки вроде "deadlock update conflicts with concurrent update"
код клиентских аппликух есть на руках? Какие там параметры транзакций используются?
vik писал(а):Если я правильно понимаю, то суть проблемы в том что происходят кратковременные потери коннекта, после чего зависают незакрытые транзакции. Так ли это?
вполне возможно. Особенно в случае классика.
vik писал(а):моя задача в том, чтобы настроить сервак/локалку/изменить систему/др.варианты, так чтобы требуемые операции выполнялись в штатном режиме, в т.ч. при кратковременных потерях конекта.
регулярные потери соединения с сервером - это не есть штатный режим работы

vik
Сообщения: 31
Зарегистрирован: 29 янв 2008, 21:48

Re: deadlock'и при обрывах коннекта

Сообщение vik » 13 авг 2008, 13:27

dimitr писал(а):Найди все fbclient.dll на клиентских машинах и убедись, что они версии не ниже 2.1.0.
На клиентских тачках тоже переустанавливал последнюю версию, ситуация не менялась. Но версию либы не проверял, могла затерятся от прошлых, в след раз проверю, спс.
dimitr писал(а):код клиентских аппликух есть на руках? Какие там параметры транзакций используются?
Да, код есть целиком, только проблема в том что система жутко старая и неустойчива к любым изменениям. Юзаются стандартные IBxxx, причем не последней версии и обновить их мягко говоря проблематично, в проекте полно IBClientDataSet, переписывать уйму всего придётся. В транзакции дополнительных параметров не указано, т.е. все значения дефолтные. Кст ещё недавно была проблема с постоянным появлением "out of memory", не знаю связано ли это с этими дедлоками. Избавился путём дополнительной синхронизации в потоках и прикручиванием менеджера памяти (Fast4MM).
dimitr писал(а):регулярные потери соединения с сервером - это не есть штатный режим работы
Во-первых про потери это только предположение на основе вылетающих эксепшенов и лога фб. Правда вчера свитч подвис, но после ребута все стало ок, объективных причин не нашли. В остальном сетка пашет нормально и признаков каких-то траблов не наблюдается. Хотя конечно всегда остается вариант, что плохо искали ))

Во-вторых - потери коннекта может и не штатный режим, но скажем так - мне поставлена задача свести его к штатному с точки зрения конечного пользователя. Т.е. влияние на работу операторов должно быть минимальным. А я пока не знаю откуда начать )) Как определить где проблема - в настройке фб, в настройке сервака/клиентских машин или в логике самого приложения? Соответственно в зависимости от причины мне нужно будет поменять логику, чтобы оператору выдавать либо "всё нормально, продолжай работать" либо "стоп, сделай А, Б, Ц...". Т.е. ключевой вопрос - как точно определить причину вылета указаных ошибок?

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

Сообщение kdv » 13 авг 2008, 14:26

В транзакции дополнительных параметров не указано, т.е. все значения дефолтные.
это пипец просто. Значит все транзакции snapshot.

vik
Сообщения: 31
Зарегистрирован: 29 янв 2008, 21:48

Сообщение vik » 13 авг 2008, 15:24

kdv писал(а):
В транзакции дополнительных параметров не указано, т.е. все значения дефолтные.
это пипец просто. Значит все транзакции snapshot.
та ладно...:shock::shock: а какой догадался на дефалт поставить снеп?....
спс за наводку, это место я подправлю. вот только связано ли это с собсно сабжем? снеп снепом, но дедлок может быть только на изменении, а изменяют они совсем немного, там нет длинных транзакций...

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

Сообщение WildSery » 13 авг 2008, 15:35

Какая разница, длинные или короткие? Главное, есть конкурентные. Этого достаточно.

vik
Сообщения: 31
Зарегистрирован: 29 янв 2008, 21:48

Сообщение vik » 13 авг 2008, 15:42

WildSery писал(а):Какая разница, длинные или короткие? Главное, есть конкурентные. Этого достаточно.
но если две снеп транзакции пишут разные таблицы/записи это же не может привести к дедлоку? или я чего не понимаю?
в смысле в чем они конкурировать будут, если меняют разные данные?

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

Сообщение WildSery » 13 авг 2008, 16:07

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

Merlin
Динозавр IB/FB
Сообщения: 1502
Зарегистрирован: 27 окт 2004, 11:44

Сообщение Merlin » 13 авг 2008, 16:43

WildSery писал(а):Если бы они всегда меняли строго разные данные, и никогда сначала один, а потом второй одни и те же, то дедлока не могло возникнуть в принципе.
Есть такое штуко в природе - триггер ;)

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

Сообщение WildSery » 13 авг 2008, 17:08

Merlin писал(а):Есть такое штуко в природе - триггер ;)
Знаю-знаю. Это такой "переключатель-срабатыватель".
Под изменением данных я имел в виду конечно же все затронутые изменением, что напрямую, что триггерами, что каскадно системными триггерами.

vik
Сообщения: 31
Зарегистрирован: 29 янв 2008, 21:48

Сообщение vik » 14 авг 2008, 00:10

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

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

Сообщение kdv » 14 авг 2008, 09:56

а какой догадался на дефалт поставить снеп?....
а какой нихрена не читает про транзакции?
снапшот в IBX по умолчанию отроду, как и в IB/FB.
www.ibase.ru/devinfo/ibx.htm
www.ibase.ru/devinfo/ibtrans.htm

vik
Сообщения: 31
Зарегистрирован: 29 янв 2008, 21:48

Сообщение vik » 14 авг 2008, 14:57

kdv писал(а): а какой нихрена не читает про транзакции?
снапшот в IBX по умолчанию отроду, как и в IB/FB.
читал я всё, читал, просто всегда юзаю FIBPlus, а там дефалт read commited, посему на дефалт фб не обратил внимания

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

Сообщение kdv » 14 авг 2008, 16:50

а там дефалт read commited, посему на дефалт фб не обратил внимания
мораль - все равно не читал. и дефолты - отстой :)
А деврейсов лупить надо за исправление дефолта.

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

Сообщение WildSery » 14 авг 2008, 17:06

Такие вещи, как параметры транзакции, надо дефолтовые делать такими, чтобы вообще ничего не работало.
Тогда появится чёткий стимул - не прочитал - не разобрался - не работает.
ИМХО.

Ответить