iBase.ru Forum

Имеется сервер 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 будет жить лучше - без проблем перееду на линукс, но хотелось бы знать наверняка.

дождись, пока разработчики праздники допразднуют.

kdv писал(а):дождись, пока разработчики праздники допразднуют.

Спасибо. Кстати, устранил (по возможности) ситуации, когда транзакции, пытаются обновить одну и ту же запись из разных нитей/процессов. Ошибка перестала (пока) появлятся. Хотя, и до этого она была не каждый день.
Все же планирую сначала частично, а потом и полностью переехать на линукс. Чутье подсказывает, что там оно получше будет. Да, заметил особенность: перенес одну из рабочих баз на линукс и оказалось, что FB там меньше памяти тратит и !!меньше загружает CPU!! (даже с учетом того, что в линуксе он использует оба CPU, а не один)

Я правильно понимаю, что упомянутая "служба" - многопоточное приложение? Тогда смущает что коннект локальный, а не по TCP-localhost. За XNET не знаю, но старый локальный протокол сериализовал обращения в gds32. Ну и факовые вещи - надеюсь, каждый поток имеет свой коннект и установление оного коннекта сериализовано в "службе", этот момент непотокобезопасен.

Merlin писал(а):Тогда смущает что коннект локальный, а не по TCP-localhost

Гм, я этого из вопроса не обнаружил

Merlin писал(а):За XNET не знаю, но старый локальный протокол сериализовал обращения в gds32.

С XNET должно быть всё в порядке в этом плане. Клиент, есс-но должен быть от 2-ки, чтобы XNET работал.

Merlin писал(а):Ну и факовые вещи - надеюсь, каждый поток имеет свой коннект и установление оного коннекта сериализовано в "службе", этот момент непотокобезопасен.

Да, в этом весьма желательно убедиться

Merlin писал(а):Я правильно понимаю, что упомянутая "служба" - многопоточное приложение? Тогда смущает что коннект локальный, а не по TCP-localhost. За XNET не знаю, но старый локальный протокол сериализовал обращения в gds32. Ну и факовые вещи - надеюсь, каждый поток имеет свой коннект и установление оного коннекта сериализовано в "службе", этот момент непотокобезопасен.

"служба" - это windows service
коннект происходит на localhost:alias, т.е. по tcp/ip
каждый thread создает свой собственный коннект в своем (thread'а) конетектсе. Т.е. стартует thread, открывает соединение, начинает транзакцию, делает коммит (или роллбэк), начинает след. транзакцию и т.д. Затем, когда служба получает сигнал остановки, она сообщает об этом каждой thread, и эти нити (потоки) завершают текущую транзакцию и закрывают свои соединения.

Может в это уже есть ошибка? Читал Хелен Борри - ничего противоречащего у себя не обнаружил.

hvlad писал(а):

Merlin писал(а):Тогда смущает что коннект локальный, а не по TCP-localhost

Гм, я этого из вопроса не обнаружил

Да, эт я погорячился, в логе пишется локальный путь всегда.

AL-GALI писал(а): стартует thread, открывает соединение

Вот этот момент следует сериализовать. Какие там ошибки бывают я не в курсе, у меня в трёхзвенках чисто случайно это сериализовалось само собой, из других соображений (визуализация-мониторинг установления коннектов), сам узнал года через три успешной работы такого приложения На www.ibase.ru где-то про это написано.

Merlin писал(а):

hvlad писал(а):

Merlin писал(а):Тогда смущает что коннект локальный, а не по TCP-localhost

Гм, я этого из вопроса не обнаружил

Да, эт я погорячился, в логе пишется локальный путь всегда.

Коннект ТОЧНО через tcp port 3050, проверил через netstat - коннект на 127.0.0.1:3050

Merlin писал(а):

AL-GALI писал(а): стартует thread, открывает соединение

Вот этот момент следует сериализовать. Какие там ошибки бывают я не в курсе, у меня в трёхзвенках чисто случайно это сериализовалось само собой, из других соображений (визуализация-мониторинг установления коннектов), сам узнал года через три успешной работы такого приложения На www.ibase.ru где-то про это написано.

Читал Я этот сайт вообще часто читаю. Однако, не понятно, с какой стати это сериализовывать? А еще у меня несколько ПРОЦЕССОВ работают с этими же БД. Или gds32.dll только в контексте одного процесса требует сериализации подключений? В книжках по FB/IB про это не читал.

AL-GALI писал(а): Однако, не понятно, с какой стати это сериализовывать?

С какой стати мы рождаемся и умираем мне тоже непонятно, но факты - упрямая вещь Такой код.

AL-GALI писал(а): А еще у меня несколько ПРОЦЕССОВ работают с этими же БД.

И пущай.

AL-GALI писал(а): Или gds32.dll только в контексте одного процесса требует сериализации подключений?

Именно.

AL-GALI писал(а): В книжках по FB/IB про это не читал.

А там и не написано, и в доке тоже

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)

ФБ при этом падает ? Или начинает всем говорить про can't continue after bug check ?
Процедуры\триггеры на ходу правите ?

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 писал(а):Но она может произойти и внезапно, например, после недели-двух непрерывной работы часа в три утра (при наименьшей нагрузке!)

Гм...

AL-GALI писал(а):после чего перезапуск fb дает снова такое же сообщение.

Про 'invalid SEND request' ? Или про 'файл занят другим процессом' ?

Есть возможность уронить сервер и выслать дамп ? Если да - скажу что для этого нужно сделать

Заваливать специально не хочется но я об этом подумаю. В течение нескольких часов подготовлю более подробное описание "как это".

AL-GALI писал(а):Заваливать специально не хочется но я об этом подумаю. В течение нескольких часов подготовлю более подробное описание "как это".

Про "заваливать специально" да ещё и боевой сервер не может быть и речи. Я не удачно выразился
Имелось в виду - если оно падает (как сказано в сабже), то хотелось бы получить дамп. А то есть одно подозрение...

hvlad писал(а):

AL-GALI писал(а):Заваливать специально не хочется но я об этом подумаю. В течение нескольких часов подготовлю более подробное описание "как это".

Про "заваливать специально" да ещё и боевой сервер не может быть и речи. Я не удачно выразился
Имелось в виду - если оно падает (как сказано в сабже), то хотелось бы получить дамп. А то есть одно подозрение...

Возможно, что 2.0 больше не упадет (если только старт-стоп без паузы через апплет панели управления - тогда может быть ошибка 167). Как включить дамп, чтобы в него попали интересующие Вас детали? Могу сделать это и в win2003 и в Linux (SuSE Linux Ent. Server 10).


Прилагаю два лога: большой, полученный в ходе работы 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, т.к. на ноутбуке - линукс, а другого компьютера в нерабочее время под рукой нет.

AL-GALI писал(а):Возможно, что 2.0 больше не упадет (если только старт-стоп без паузы через апплет панели управления - тогда может быть ошибка 167). Как включить дамп, чтобы в него попали интересующие Вас детали? Могу сделать это и в win2003 и в Linux (SuSE Linux Ent. Server 10).

Для начала запустить с консоли drwtsn32 -i - это установит в системе др.Ватсона как отладчик по умолчанию и он будет создавать дампы в момент краша программ.
Далее запустить его (просто drwtsn32) и настроить :
путь к файлу журнала - по вкусу
число инструкций и число ошибок - по вкусу, у меня 20 и 30
копия таблицы символов - не надо
контексты для всех потоков - да
добавление в сущ.журнал - да
визуальное и звуковое оповещение - выключить
аварийная копия памяти - выключить

Также весьма желательно скачать .pdb файлы и распаковать их в каталог bin сервера - это сделает дамп намного более читабельным

Если падений не будет (а их не много, судя по логу, - чаще вы сами перезапускаете сервер), то можно в firebird.conf поставить BugcheckAbort = 1 (и перезапустить сервер есс-но)
После получения дампа можно вернуть это назад

В принципе, я могу сделать тестовую сборку (1.5.4 или 2.0.1 - всё равно) с доп. диагностикой в том месте, где у меня подозрения. Но дамп всё же более желателен

AL-GALI писал(а):Прилагаю два лога: большой, полученный в ходе работы 1.5.3 и маленький - 2.0.
В логе 1.5.3 можно наблюдать сбой в ф-ии F_MID библиотеки FreeUDFLib. На мой взгляд, данная функция не содержит каких-либо явных ошибок, а падение FB происходит, когда fbserver.exe (в списке процессов Windows) начинает занимать более 1.4Гб памяти (всего в системе 2Гб ОЗУ).

Там кидается VCL'ное исключение EEDFADE. Его можно найти в system.pas (cDelphiException).
Возможно действительно проблемы с выделением памяти, которые эта (да и остальные) ф-ция не обрабатывает

AL-GALI писал(а):Далее, при автоматическом перезапуске (через fbguard) базы остаются недоступными (файл занят другим процессом). Вообще, я ни разу не замечал, чтобы после аварийного рестарта (через fbguard) все базы данных были доступны. Обычно от трети до двух третей (из примерно десятка баз) при попытке присоединения через IBExpert сообщают о занятости файла БД другим процессом.

Не нужно пользоваться гвардейцем ! Никогда ! Для рестарта службы в Windows, начиная с W2K есть нормальный встроенный механизм.

The database %s was being accessed when the server was shutdown

означает что сервер принудительно перезапускали, не смотря на наличие коннектов

AL-GALI писал(а):Здесь вы правы, предполагая, что в базы стучится множество клиентов практически непрерывно (точнее - несколько многопоточных процессов), и в момент старта fb - тоже, только я не подозревал, что это не очень хорошо.

Это какая-то бага в сервере, которую мы сейчас ищем.
Он должен работать независимо от кол-ва внешнего насилия

AL-GALI писал(а):Заменив fb 1.5.3 на 2.0 я заметил уменьшение занимаемой fbserver памяти до 450Мб (и более размер занимаемой памяти не растет, а лишь колеблется около этого значения 450..500 мб)

Оч. хор. - ещё один повод перейти на 2-ку
С блобами работаете ? Держите их много открытых одновременно ?

AL-GALI писал(а):Однако, перезапуск fbserver через апплет (если не выдержать паузу 1..3 минуты) опять-таки провоцирует ошибку 167 (и в 1.5.3 и в 2.0) и недоступность части (или всех) баз (файл занят...)

Не хорошо это... Похоже внутри сервера этот багчек как-то криво обрабатывается... Будем смотреть