iBase.ru Forum

P4 Mon Feb 14 17:35:07 2005
SERVER/process_packet: broken port, server exiting

P4 Mon Feb 14 17:35:07 2005
INET/inet_error: send errno = 10054

P4 Mon Feb 14 17:35:07 2005
SERVER/process_packet: broken port, server exiting

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

Недавно сменил архитектуру с СС на классик версия 1,52
вин2003. В программе изменений никаких не делал.
Может ли это быть из-за того что создал новый индекс во время работы клиентов?

Events используются?
Других ошибок в логе нет?
Есть привязка к какому-то конкретному действию в приложении?

10054 - это сервер заметил, что издох клиент, не более того. Шнурок оборвал, ресет нажал и т.п. В сочетании с events возникал всякий разный гемор, но вроде ЦПУ жрал, а не диск. Несколько раз провозглашалось, что наконец обнаружено и уборото, но проверка в поле всегда права. Ужор диска при слабом потреблении процессора может говорить о сборке горы мусора. Само создание индекса при клиентах безвредно, но появление нового индекса может вести к изменению планов выполнения каких-либо запросов, у которых раньше возможности его использовать не было, иной раз к фатально неудачному. Это в плане привязки к действиям. Ну и ещё - если он жутко неселективный, это может способствовать образованию горы мусора при массированных удалениях и апдейтах.

Эвентов не использую, приложения как уже говорил действительно срываю "снять задачу" из за беспробудного висяка

насчет мусора точно подметил
я поставил свипинтервал в 0 и вызываю
gfix -sweep каждую ночь по расписанию
попытка установить обратно автосборку

"C:\Program Files\Firebird152\bin\gfix.exe" -housekeeping 30000 -user "SYSDBA" -password "masterkey" C:\ShopDB\U96.GDB
говорит unavailable database

как это понимать?

DSKalugin писал(а):Эвентов не использую, приложения как уже говорил действительно срываю "снять задачу" из за беспробудного висяка

Вот тут сервак и пишет 10054. На классике можно бить "зависшие" процессы, если можешь из определить, но риск повредить базу есть, особенно если этот процесс как раз сборкой и занят.

DSKalugin писал(а): я поставил свипинтервал в 0 и вызываю
gfix -sweep каждую ночь по расписанию
попытка установить обратно автосборку

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

DSKalugin писал(а): "C:\Program Files\Firebird152\bin\gfix.exe" -housekeeping 30000 -user "SYSDBA" -password "masterkey" C:\ShopDB\U96.GDB
говорит unavailable database

как это понимать?

да не знаю я ваших виндовых заморочек

насчет unavailable database - это мистическое сообщение лично меня уже достало. ибо у меня на W2000 не воспроизводится, а у людей случается как на FB так и на IB 7.x.

насчет 10054 и т.п. - есть один четкий случай умирания IB 7.1 SP2 на Win2003 Server, с похожими симптомами. Сначала все ОК, потом начинаются 10054, и кончается все это 10093 и неработой IB. На Win2000 все замечательно с тем же IB и тем же приложением. Интересно было бы услышать, не имеет ли кто аналогичных проблем на W2003 + FB 1.5.2, ибо подозрения на какую-то очередную несовместимость с tcp.

kdv писал(а): насчет 10054 и т.п. - есть один четкий случай умирания IB 7.1 SP2 на Win2003 Server, с похожими симптомами.

Дим, 10054 он похоже устраивает сам, когда "зависшее" клиентское приложение снимает. А насчёт зависания - помнишь, я рассказывал, как один орёл у меня с похмела на таблице с 10 миллионами записей организовал индекс по полю "дебет/кредит"? Удалить из такой таблицы при наличии такого индекса тысяч 200 - и свип на сутки Причём, если сделать его уникальным, привесив какой-нибудь ID сзаду, то так в глаза бросаться не будет, но запросы с условиями на первый индекс начнут его хватать и перестраивать привычные планы, включая порядок следования таблиц в inner-ах, со всеми вытекающими последствиями. То есть вместо привычных сотых долей секунды можно получить минут 10. А потом начать валить приложения и усугублять происходящее

У меня на NT 4.0 c IB 7.5 ошибка 10054 лезет постоянно, причем пишет, что с разных компов. Приложение не виснет, коннекты никто не рвет. То же самое, если законекчен один только IBExpert. Такая же фигня была и с IB 6.5, и с IB 5.6.

Unavailable database в данном случае вполне понятно - надо указывать хост в gfix, ибо win32-классик поддерживает локальный протокол только начиная с 2.0.

По порядку теперь:
1-в прошлый четверг сменил сервер с Fb SS 1.5.2 на Fb CS 1.5.2
Причину перехода я тут обосновал (из-за глюка в УДФ на одной базе перегрузился ФБ и отключились аварийно другие БД) Хотел сделать независимые процессы. Но в результате эти отдельные стали работать медленней чем на СС, иногда притормаживать.

2-свипинтервал поставил в 0. Сборку мусора делал ежедневно по расписанию gfix -sweep

3-вчера вечером для ускорения выполнения разовой процедуры создал 5 индексов на работающей БД. Процедура занималась массовым обновлением в пределах 3 тыс записей и удалением "лишних".
Сразу после этого начались длительные висяки. Работать не возможно.
Сегодня сутра тоже висяки были железные. Работать не возможно. Загадки да и только. ИБЭксперт подключаться не захотел. Говорит

Unsuccessful execution caused by an unavailable resource.
unavailable database.

-ИБАналист тоже подобным образом ругнулся
-локальный gfix тоже не хочет выполнять ни одно действие (unavailable database).
-Зато удаленно получилось положить базу в даун и подключиться ибэкспертом.
-FirstAID протестировал и сказал все ок, единственное 5 удаленных индексов показал.

Вобщем решил задачу так. Вернул все на место
перегрузил ВинСерв2003 - не помогло.

-Удаленно ибэкспертом удалил эти злополучные индексы.
-сделал бэкап
-деинсталлировал Fb CS
-установил по новой но уже SS
-провелил БД gfix.exe -v -full
на экране ничего в логе нашол потом
P4 (Client) Tue Feb 15 10:27:22 2005
Control services error 1061
-вернул свипинтервал в 30000 (перед нулем было 20000)
-всех включил, жалоб нет на тормоза.

что это было, так и не понял. Но тяга к экспериментам пропала.

dimitr писал(а):Unavailable database в данном случае вполне понятно - надо указывать хост в gfix, ибо win32-классик поддерживает локальный протокол только начиная с 2.0.

Опа, а я напрямую писал типа C:\... без локалхост. В Супере работало наура. Не знал. Спасибо.

Напрашивается еще один вопрос. Не знаю в тему ЛИ? но задам.
Читал

Не надо логиниться к одной базе с разными путями
В этом случае очень вероятно повреждение базы вплоть до ее полного уничтожения. Т.е. не надо использовать link-и на файлы и каталоги БД в unix, и не надо ошибаться и под win писать путь коннекта как c:dir\data.gdb вместо правильного c:\dir\data.gdb.
этот совет не относится к разным именам одного и того же сервера в строке коннекта.
http://www.ibase.ru/devinfo/dontdoit.htm

Вопрос : Является ли разными путями подключение
- напрямую через IBObject с указанием P4:C:\ShopDB\U96.gdb
- через FIBPlus но с использованием алиаса P4:ShopsDB
где в alias.conf четко прописано
ShopsDB = C:\ShopDB\U96.gdb
А?

DSKalugin писал(а):По порядку теперь:
независимые процессы. Но в результате эти отдельные стали работать медленней чем на СС, иногда притормаживать.

а может, надо было сначала выяснить, почему притормаживает? Может ты задал такой кэш в БД, который для классика смерти подобен.

2-свипинтервал поставил в 0. Сборку мусора делал ежедневно по расписанию gfix -sweep

накопление мусора можно увидеть просмотром статистики. Просто так конечно можно свип в 0 установить, но ...

Сразу после этого начались длительные висяки. Работать не возможно.

ну вот. сборка мусора в индексах.

-ИБАналист тоже подобным образом ругнулся

забей ты на локальный протокол. что, нельзя указать соединение как localhost:c:\dir\data.gdb???

-вернул свипинтервал в 30000 (перед нулем было 20000)

шаманим...

что это было, так и не понял. Но тяга к экспериментам пропала.

желания почитать хелп к IBAnalyst и www.ibase.ru/devinfo/delmany.htm, а также firebird.conf не появилось?[/quote]

Тормоза наверняка из-за кооперативной сборки мусора вместо привычной на супере фоновой... Ну и кеш наверняка влияет.

читал и хелп и конфиг. Желание учиться, разбираться всегда было и есть. Но вот со временем - попа . Быстрее было вернуть все к исходному стабильному состоянию.
С хелпом проще, там для людей писано, а доку по конфигу под силу осмыслить только профФфессуре, глубоко ежедневно копающейся в недрах кода Firebird. Общем для людей писать надо, а не для киборгов.
Конфиг у меня по умолчанию как стал так я и не трогал его.
Про Локалхост, согласен. Не придавал значения. буду теперь знать.
Спасибо за поддержку

dimitr писал(а):Тормоза наверняка из-за кооперативной сборки мусора вместо привычной на супере фоновой... Ну и кеш наверняка влияет.

Кстати, тезка, растолкуй... Возможно ли попадание классика в ситуацию, когда 2 и более процесса начинают собирать мусор в одной и тойже базе? Они меж собой не будут конфлктовать или такое не возможно? А как насчет работы в период сбора ?

а по поводу
Не надо логиниться к одной базе с разными путями см выше
может ктонить прояснить?

если не умеешь указать для одного файла БД разный путь, то лучше не надо не знаешь - спишь спокойно

1) Дока по конфигу написано вполне понятно
2) Собирать мусор могут и два процесса классика, никакого конфликта тут нет
3) Алиас - не есть другой пусть к базе

Ура! Причина тормозов разгадана!

Когда я переустанавливал Firebird, я поставил его в другой каталог.
А скрипты подправить забыл, сволачь я ) И себе и вам и юзерам неудобства создал...
Поэтому запланированная сборка мусора из скрипта не происходила!
А Автоматическую я отключил. Ну плюс добавление индексов, массовые insert/update/delete - полный висяк.

Неучел особенность локального подключения с localhost впереди пути
Поэтому не мог достучаться к базе утилитами

Спасибо за внимание. Вопрос объявляю закрытым

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

В продолжение этой темы и "IB 6.5 Server + W2KSP2 Помогите, плиз, чайнику":
Вопрос: обязательно/желательно ли ставить IB сервер на отдельную машину.
Проблема продолжается та-же, но реже - ошибки 10053 и 10054 частенько и 2-5 раз в сутки требуется перезапуск IB сервера.
Решал по форуму и докам: обновил все клиентские машины до последних патчей, отключил 2 старые машины на Вынь98 от сервера, поставил ibconsvc на сервер, убрал все не нужное. По логу не получается отследить ошибку - какая-то плавающая: может произойти когда кто-то лезет в 1С или интернет и т.д., от конкретного клиента не зависит, исправил ibconfig:connection_timeout и dummy_packet_intervel - ничего не помогает. Причем если выключить совсем все компьютеры в сети и оставить 3 (основных рабочих включая сервер) и работать только в Interbase программе - все отлично.
Поэтому и вопрос: насколько остальные сетевые программы (The Bat, 1C, EServ/аналог WinGate/ + некоторые MS офисные документы) на сервере сбивают IB сервер?