Имеется сервер HP ML350 G4p, 2 CPU Xenon 3.0 GHz, 2 Гб ОЗУ, RAID5 (smart array 642, 192M cache with bat.) гипертрединг ОТКЛЮЧЕН, FB(SuperServer) работает только на одном процессоре.
ОС Win2003 server (enterprise)
При ~ 300..500 коннектах и множестве параллельных транзакций (читающих, пишущих, 9 отдельных БД, 40 таблиц в каждой базе, 87 хранимых процедур, в таблицах не более 500 тыс записей) в логе FB появляется следующее сообщение:
TERMINAL-SERVER (Server) Wed Jan 03 02:23:49 2007
Database: D:\DB\ICARD.FDB
internal gds software consistency check (invalid SEND request (167), file: exe.cpp line: 494)
Система обслуживает сеть из примерно 120 платежных терминалов самообслуживания.
Обращение к FB из службы, работающей на той же самой машине, через Data Provider for .NET Framework 2.0 (Version 2.0.1 for .NET 2.0).
Та же самая ситуация была на FB 1.5.3, только слов "file: exe.cpp line: 494" в сообщении об ошибке не было.
Подскажите, пожалуйста, какие шаги можно предпринять для повышения стабильности работы FB.
С Уважением, Александр.
PS Если есть хороший шанс, что на линуксе FB будет жить лучше - без проблем перееду на линукс, но хотелось бы знать наверняка.
FB 2.0.0.12748 / Win2003 Ent. server падение, ошибка 167
Спасибо. Кстати, устранил (по возможности) ситуации, когда транзакции, пытаются обновить одну и ту же запись из разных нитей/процессов. Ошибка перестала (пока) появлятся. Хотя, и до этого она была не каждый день.kdv писал(а):дождись, пока разработчики праздники допразднуют.
Все же планирую сначала частично, а потом и полностью переехать на линукс. Чутье подсказывает, что там оно получше будет. Да, заметил особенность: перенес одну из рабочих баз на линукс и оказалось, что FB там меньше памяти тратит и !!меньше загружает CPU!! (даже с учетом того, что в линуксе он использует оба CPU, а не один)
Я правильно понимаю, что упомянутая "служба" - многопоточное приложение? Тогда смущает что коннект локальный, а не по TCP-localhost. За XNET не знаю, но старый локальный протокол сериализовал обращения в gds32. Ну и факовые вещи - надеюсь, каждый поток имеет свой коннект и установление оного коннекта сериализовано в "службе", этот момент непотокобезопасен.
Гм, я этого из вопроса не обнаружилMerlin писал(а):Тогда смущает что коннект локальный, а не по TCP-localhost
С XNET должно быть всё в порядке в этом плане. Клиент, есс-но должен быть от 2-ки, чтобы XNET работал.Merlin писал(а):За XNET не знаю, но старый локальный протокол сериализовал обращения в gds32.
Да, в этом весьма желательно убедитьсяMerlin писал(а):Ну и факовые вещи - надеюсь, каждый поток имеет свой коннект и установление оного коннекта сериализовано в "службе", этот момент непотокобезопасен.
"служба" - это windows serviceMerlin писал(а):Я правильно понимаю, что упомянутая "служба" - многопоточное приложение? Тогда смущает что коннект локальный, а не по TCP-localhost. За XNET не знаю, но старый локальный протокол сериализовал обращения в gds32. Ну и факовые вещи - надеюсь, каждый поток имеет свой коннект и установление оного коннекта сериализовано в "службе", этот момент непотокобезопасен.
коннект происходит на localhost:alias, т.е. по tcp/ip
каждый thread создает свой собственный коннект в своем (thread'а) конетектсе. Т.е. стартует thread, открывает соединение, начинает транзакцию, делает коммит (или роллбэк), начинает след. транзакцию и т.д. Затем, когда служба получает сигнал остановки, она сообщает об этом каждой thread, и эти нити (потоки) завершают текущую транзакцию и закрывают свои соединения.
Может в это уже есть ошибка? Читал Хелен Борри - ничего противоречащего у себя не обнаружил.
Вот этот момент следует сериализовать. Какие там ошибки бывают я не в курсе, у меня в трёхзвенках чисто случайно это сериализовалось само собой, из других соображений (визуализация-мониторинг установления коннектов), сам узнал года через три успешной работы такого приложенияAL-GALI писал(а): стартует thread, открывает соединение
На www.ibase.ru где-то про это написано.
Последний раз редактировалось Merlin 04 янв 2007, 16:31, всего редактировалось 1 раз.
ЧиталMerlin писал(а):Вот этот момент следует сериализовать. Какие там ошибки бывают я не в курсе, у меня в трёхзвенках чисто случайно это сериализовалось само собой, из других соображений (визуализация-мониторинг установления коннектов), сам узнал года через три успешной работы такого приложенияAL-GALI писал(а): стартует thread, открывает соединение
Я этот сайт вообще часто читаю. Однако, не понятно, с какой стати это сериализовывать? А еще у меня несколько ПРОЦЕССОВ работают с этими же БД. Или gds32.dll только в контексте одного процесса требует сериализации подключений? В книжках по FB/IB про это не читал.С какой стати мы рождаемся и умираем мне тоже непонятно, но факты - упрямая вещьAL-GALI писал(а): Однако, не понятно, с какой стати это сериализовывать?
Такой код.И пущай.AL-GALI писал(а): А еще у меня несколько ПРОЦЕССОВ работают с этими же БД.
Именно.AL-GALI писал(а): Или gds32.dll только в контексте одного процесса требует сериализации подключений?
А там и не написано, и в доке тожеAL-GALI писал(а): В книжках по FB/IB про это не читал.
Re: FB 2.0.0.12748 / Win2003 Ent. server падение, ошибка 167
ФБ при этом падает ? Или начинает всем говорить про can't continue after bug check ?AL-GALI писал(а):При ~ 300..500 коннектах и множестве параллельных транзакций (читающих, пишущих, 9 отдельных БД, 40 таблиц в каждой базе, 87 хранимых процедур, в таблицах не более 500 тыс записей) в логе FB появляется следующее сообщение:
TERMINAL-SERVER (Server) Wed Jan 03 02:23:49 2007
Database: D:\DB\ICARD.FDB
internal gds software consistency check (invalid SEND request (167), file: exe.cpp line: 494)
Процедуры\триггеры на ходу правите ?
Re: FB 2.0.0.12748 / Win2003 Ent. server падение, ошибка 167
"на ходу" не правлю - в книжках пишут, что так нельзя.hvlad писал(а):ФБ при этом падает ? Или начинает всем говорить про can't continue after bug check ?
Процедуры\триггеры на ходу правите ?
Выдержка из лога (старого, 1.5.3):
TERMINAL-SERVER (Client) Tue Jan 02 09:52:09 2007
Guardian starting: C:\Program Files\Firebird\Firebird_1_5\bin\fbserver.exe
TERMINAL-SERVER (Server) Tue Jan 02 09:52:10 2007
Database: D:\DB\ZNAMENSK.FDB
internal gds software consistency check (invalid SEND request (167))
TERMINAL-SERVER (Server) Tue Jan 02 09:52:11 2007
Database: D:\DB\VOLZHSKIY.FDB
internal gds software consistency check (invalid SEND request (167))
После чего никаких записей не появляется, но подключиться к базе нельзя - IBExpert сообщает (общий смысл) что файл занят другим процессом (хотя подключаюсь через tcp/ip, видимо ошибка в него приходит из gds32.dll). Сам fb в списке процессов присутствует.
Как видите, ситуация имела место быть в момент запуска. Но она может произойти и внезапно, например, после недели-двух непрерывной работы часа в три утра (при наименьшей нагрузке!) после чего перезапуск fb дает снова такое же сообщение. Для того, чтобы стартовать нормально, надо минуть пять подождать с запуском fb. Вот у меня такая мысль: может это связано с утечкой каких-либо системных ресурсов, но "восстанавливаемых" за какое-то время самой ОС? Я когда-то разрабатывал сетевые приложения, работающие в условиях высокой нагрузки - там бывали проблемы с "недозакрытыми" сокетами (вроде того, что close(socket) закрывает далеко не сразу, и он некоторое время после завершения ф-ии занимает системные ресурсы, вызывая утечку дескрипторов, которая сама устраняется при снижении нагрузки)
А клиенты сразу начинают активно долбить сервер запросами ? На изменение данных ?AL-GALI писал(а):Как видите, ситуация имела место быть в момент запуска.
Гм...AL-GALI писал(а):Но она может произойти и внезапно, например, после недели-двух непрерывной работы часа в три утра (при наименьшей нагрузке!)
Про 'invalid SEND request' ? Или про 'файл занят другим процессом' ?AL-GALI писал(а):после чего перезапуск fb дает снова такое же сообщение.
Есть возможность уронить сервер и выслать дамп ? Если да - скажу что для этого нужно сделать
Про "заваливать специально" да ещё и боевой сервер не может быть и речи. Я не удачно выразилсяAL-GALI писал(а):Заваливать специально не хочется
Имелось в виду - если оно падает (как сказано в сабже), то хотелось бы получить дамп. А то есть одно подозрение...
Возможно, что 2.0 больше не упадет (если только старт-стоп без паузы через апплет панели управления - тогда может быть ошибка 167). Как включить дамп, чтобы в него попали интересующие Вас детали? Могу сделать это и в win2003 и в Linux (SuSE Linux Ent. Server 10).hvlad писал(а):Про "заваливать специально" да ещё и боевой сервер не может быть и речи. Я не удачно выразилсяAL-GALI писал(а):Заваливать специально не хочется
Имелось в виду - если оно падает (как сказано в сабже), то хотелось бы получить дамп. А то есть одно подозрение...
Прилагаю два лога: большой, полученный в ходе работы 1.5.3 и маленький - 2.0.
В логе 1.5.3 можно наблюдать сбой в ф-ии F_MID библиотеки FreeUDFLib. На мой взгляд, данная функция не содержит каких-либо явных ошибок, а падение FB происходит, когда fbserver.exe (в списке процессов Windows) начинает занимать более 1.4Гб памяти (всего в системе 2Гб ОЗУ). Далее, при автоматическом перезапуске (через fbguard) базы остаются недоступными (файл занят другим процессом). Вообще, я ни разу не замечал, чтобы после аварийного рестарта (через fbguard) все базы данных были доступны. Обычно от трети до двух третей (из примерно десятка баз) при попытке присоединения через IBExpert сообщают о занятости файла БД другим процессом. Здесь вы правы, предполагая, что в базы стучится множество клиентов практически непрерывно (точнее - несколько многопоточных процессов), и в момент старта fb - тоже, только я не подозревал, что это не очень хорошо.
Заменив fb 1.5.3 на 2.0 я заметил уменьшение занимаемой fbserver памяти до 450Мб (и более размер занимаемой памяти не растет, а лишь колеблется около этого значения 450..500 мб). Однако, перезапуск fbserver через апплет (если не выдержать паузу 1..3 минуты) опять-таки провоцирует ошибку 167 (и в 1.5.3 и в 2.0) и недоступность части (или всех) баз (файл занят...).
[лог удален модератором]
Модератору
Уважаемый Модератор! А можно ли как-то прикреплять к сообщению файлы, дабы не засорять форум малоинтересными бОльшей части читателей логами? Я что-то не нашел или мой firefox не все показывает? У меня не всегда есть возможность пользоваться Internet Explorer, т.к. на ноутбуке - линукс, а другого компьютера в нерабочее время под рукой нет.
Для начала запустить с консоли drwtsn32 -i - это установит в системе др.Ватсона как отладчик по умолчанию и он будет создавать дампы в момент краша программ.AL-GALI писал(а):Возможно, что 2.0 больше не упадет (если только старт-стоп без паузы через апплет панели управления - тогда может быть ошибка 167). Как включить дамп, чтобы в него попали интересующие Вас детали? Могу сделать это и в win2003 и в Linux (SuSE Linux Ent. Server 10).
Далее запустить его (просто drwtsn32) и настроить :
путь к файлу журнала - по вкусу
число инструкций и число ошибок - по вкусу, у меня 20 и 30
копия таблицы символов - не надо
контексты для всех потоков - да
добавление в сущ.журнал - да
визуальное и звуковое оповещение - выключить
аварийная копия памяти - выключить
Также весьма желательно скачать .pdb файлы и распаковать их в каталог bin сервера - это сделает дамп намного более читабельным
Если падений не будет (а их не много, судя по логу, - чаще вы сами перезапускаете сервер), то можно в firebird.conf поставить BugcheckAbort = 1 (и перезапустить сервер есс-но)
После получения дампа можно вернуть это назад
В принципе, я могу сделать тестовую сборку (1.5.4 или 2.0.1 - всё равно) с доп. диагностикой в том месте, где у меня подозрения. Но дамп всё же более желателен
Там кидается VCL'ное исключение EEDFADE. Его можно найти в system.pas (cDelphiException).AL-GALI писал(а):Прилагаю два лога: большой, полученный в ходе работы 1.5.3 и маленький - 2.0.
В логе 1.5.3 можно наблюдать сбой в ф-ии F_MID библиотеки FreeUDFLib. На мой взгляд, данная функция не содержит каких-либо явных ошибок, а падение FB происходит, когда fbserver.exe (в списке процессов Windows) начинает занимать более 1.4Гб памяти (всего в системе 2Гб ОЗУ).
Возможно действительно проблемы с выделением памяти, которые эта (да и остальные) ф-ция не обрабатывает
Не нужно пользоваться гвардейцем ! Никогда ! Для рестарта службы в Windows, начиная с W2K есть нормальный встроенный механизм.AL-GALI писал(а):Далее, при автоматическом перезапуске (через fbguard) базы остаются недоступными (файл занят другим процессом). Вообще, я ни разу не замечал, чтобы после аварийного рестарта (через fbguard) все базы данных были доступны. Обычно от трети до двух третей (из примерно десятка баз) при попытке присоединения через IBExpert сообщают о занятости файла БД другим процессом.
The database %s was being accessed when the server was shutdown
означает что сервер принудительно перезапускали, не смотря на наличие коннектов
Это какая-то бага в сервере, которую мы сейчас ищем.AL-GALI писал(а):Здесь вы правы, предполагая, что в базы стучится множество клиентов практически непрерывно (точнее - несколько многопоточных процессов), и в момент старта fb - тоже, только я не подозревал, что это не очень хорошо.
Он должен работать независимо от кол-ва внешнего насилия
Оч. хор. - ещё один повод перейти на 2-куAL-GALI писал(а):Заменив fb 1.5.3 на 2.0 я заметил уменьшение занимаемой fbserver памяти до 450Мб (и более размер занимаемой памяти не растет, а лишь колеблется около этого значения 450..500 мб)
С блобами работаете ? Держите их много открытых одновременно ?
Не хорошо это... Похоже внутри сервера этот багчек как-то криво обрабатывается... Будем смотретьAL-GALI писал(а):Однако, перезапуск fbserver через апплет (если не выдержать паузу 1..3 минуты) опять-таки провоцирует ошибку 167 (и в 1.5.3 и в 2.0) и недоступность части (или всех) баз (файл занят...)