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. В программе изменений никаких не делал.
Может ли это быть из-за того что создал новый индекс во время работы клиентов?
INET/inet_error: send errno = 10054
Events используются?
Других ошибок в логе нет?
Есть привязка к какому-то конкретному действию в приложении?
10054 - это сервер заметил, что издох клиент, не более того. Шнурок оборвал, ресет нажал и т.п. В сочетании с 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
как это понимать?
насчет мусора точно подметил
я поставил свипинтервал в 0 и вызываю
gfix -sweep каждую ночь по расписанию
попытка установить обратно автосборку
"C:\Program Files\Firebird152\bin\gfix.exe" -housekeeping 30000 -user "SYSDBA" -password "masterkey" C:\ShopDB\U96.GDB
говорит unavailable database
как это понимать?
Вот тут сервак и пишет 10054. На классике можно бить "зависшие" процессы, если можешь из определить, но риск повредить базу есть, особенно если этот процесс как раз сборкой и занят.DSKalugin писал(а):Эвентов не использую, приложения как уже говорил действительно срываю "снять задачу" из за беспробудного висяка
Не надо. Если мои подозрения верны, то будет только хуже. Индекс, который создал, и его статистику в студию.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.
насчет 10054 и т.п. - есть один четкий случай умирания IB 7.1 SP2 на Win2003 Server, с похожими симптомами. Сначала все ОК, потом начинаются 10054, и кончается все это 10093 и неработой IB. На Win2000 все замечательно с тем же IB и тем же приложением. Интересно было бы услышать, не имеет ли кто аналогичных проблем на W2003 + FB 1.5.2, ибо подозрения на какую-то очередную несовместимость с tcp.
Дим, 10054 он похоже устраивает сам, когда "зависшее" клиентское приложение снимает. А насчёт зависания - помнишь, я рассказывал, как один орёл у меня с похмела на таблице с 10 миллионами записей организовал индекс по полю "дебет/кредит"? Удалить из такой таблицы при наличии такого индекса тысяч 200 - и свип на суткиkdv писал(а): насчет 10054 и т.п. - есть один четкий случай умирания IB 7.1 SP2 на Win2003 Server, с похожими симптомами.
Причём, если сделать его уникальным, привесив какой-нибудь ID сзаду, то так в глаза бросаться не будет, но запросы с условиями на первый индекс начнут его хватать и перестраивать привычные планы, включая порядок следования таблиц в inner-ах, со всеми вытекающими последствиями. То есть вместо привычных сотых долей секунды можно получить минут 10. А потом начать валить приложения и усугублять происходящее По порядку теперь:
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)
-всех включил, жалоб нет на тормоза.
что это было, так и не понял. Но тяга к экспериментам пропала.
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)
-всех включил, жалоб нет на тормоза.
что это было, так и не понял. Но тяга к экспериментам пропала.
и еще вопрос
Опа, а я напрямую писал типа C:\... без локалхост. В Супере работало наура. Не знал. Спасибо.dimitr писал(а):Unavailable database в данном случае вполне понятно - надо указывать хост в gfix, ибо win32-классик поддерживает локальный протокол только начиная с 2.0.
Напрашивается еще один вопрос. Не знаю в тему ЛИ? но задам.
Читал
Вопрос : Является ли разными путями подключениеНе надо логиниться к одной базе с разными путями
В этом случае очень вероятно повреждение базы вплоть до ее полного уничтожения. Т.е. не надо использовать 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 писал(а):По порядку теперь:
независимые процессы. Но в результате эти отдельные стали работать медленней чем на СС, иногда притормаживать.
накопление мусора можно увидеть просмотром статистики. Просто так конечно можно свип в 0 установить, но ...2-свипинтервал поставил в 0. Сборку мусора делал ежедневно по расписанию gfix -sweep
ну вот. сборка мусора в индексах.Сразу после этого начались длительные висяки. Работать не возможно.
забей ты на локальный протокол. что, нельзя указать соединение как localhost:c:\dir\data.gdb???-ИБАналист тоже подобным образом ругнулся
шаманим...-вернул свипинтервал в 30000 (перед нулем было 20000)
желания почитать хелп к IBAnalyst и www.ibase.ru/devinfo/delmany.htm, а также firebird.conf не появилось?[/quote]что это было, так и не понял. Но тяга к экспериментам пропала.
читал и хелп и конфиг. Желание учиться, разбираться всегда было и есть. Но вот со временем - попа 
. Быстрее было вернуть все к исходному стабильному состоянию.
С хелпом проще, там для людей писано, а доку по конфигу под силу осмыслить только профФфессуре, глубоко ежедневно копающейся в недрах кода Firebird. Общем для людей писать надо, а не для киборгов.
Конфиг у меня по умолчанию как стал так я и не трогал его.
Про Локалхост, согласен. Не придавал значения. буду теперь знать.
Спасибо за поддержку
. Быстрее было вернуть все к исходному стабильному состоянию. С хелпом проще, там для людей писано, а доку по конфигу под силу осмыслить только профФфессуре, глубоко ежедневно копающейся в недрах кода Firebird. Общем для людей писать надо, а не для киборгов.
Конфиг у меня по умолчанию как стал так я и не трогал его.
Про Локалхост, согласен. Не придавал значения. буду теперь знать.
Спасибо за поддержку
Кстати, тезка, растолкуй... Возможно ли попадание классика в ситуацию, когда 2 и более процесса начинают собирать мусор в одной и тойже базе? Они меж собой не будут конфлктовать или такое не возможно? А как насчет работы в период сбора ?dimitr писал(а):Тормоза наверняка из-за кооперативной сборки мусора вместо привычной на супере фоновой... Ну и кеш наверняка влияет.
А вот и развязка!!!
Ура! Причина тормозов разгадана!
Когда я переустанавливал Firebird, я поставил его в другой каталог.
А скрипты подправить забыл, сволачь я) И себе и вам и юзерам неудобства создал...
Поэтому запланированная сборка мусора из скрипта не происходила!
А Автоматическую я отключил. Ну плюс добавление индексов, массовые insert/update/delete - полный висяк.
Неучел особенность локального подключения с localhost впереди пути
Поэтому не мог достучаться к базе утилитами
Спасибо за внимание. Вопрос объявляю закрытым
Когда я переустанавливал Firebird, я поставил его в другой каталог.
А скрипты подправить забыл, сволачь я
) И себе и вам и юзерам неудобства создал...Поэтому запланированная сборка мусора из скрипта не происходила!
А Автоматическую я отключил. Ну плюс добавление индексов, массовые insert/update/delete - полный висяк.
Неучел особенность локального подключения с localhost впереди пути
Поэтому не мог достучаться к базе утилитами
Спасибо за внимание. Вопрос объявляю закрытым
В продолжение этой темы и "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 сервер?
Вопрос: обязательно/желательно ли ставить 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 сервер?