Добрый день!

Недавно, стал наблюдать картину падения сервера FB с сообщением в fiebird.log:

Operating system call _beginthreadex failed. Error code 8

Затем terminated abnormally.

И служба уже не перезапускается автоматически ( поставил Гардиант после первого случая).
Таких эпизодов было уже 2, возникают в конце рабочего дня.

Переход на x64 версию сервера и FB пока не реализуем.

С сервером FB работает только одно приложение.

FB 2.5.4 SS x32, WinServer 2003 r2 (4Gb) памяти.

Может ли быть утечка в приложении?

С уважением, Сергей.

Dimitry SibiryakovСергейВПМожет ли быть утечка в приложении?
Если оно использует левые UDF, то да.

UDF нет.
Это "чудесное" приложение из моего поста http://www.sql.ru/forum/1099277-a/monitoring-kolichestva-konnektov-k-serveru
Только раньше был FB 1.5.6, а сейчас по рекомендации разработчиков был установлен 2.5.4.
И это БЕЗ КОНВЕРТАЦИИ метаданных. Т.е. теперь БД с ODS FB 1.5.6 просто работает под FB 2.5.4, зато они себе галочку поставили, что перевели на другую версию сервера. ужос. Но мы люди подневольные).
Но это так, отвлечение.
База то небольшая - 400-500 Мб, на что еще обратить внимание?

Dimitry SibiryakovСергейВПтеперь БД с ODS FB 1.5.6 просто работает под FB 2.5.4
И ведь к таблицам мониторинга при таком дерьмовом раскладе не пошлёшь...

Совершенно верно.

На тестовой машине я делал backup/restore в fb 2.5.4 - на удивление прошел без ошибок (restore), есть подозрение, что обновление метаданных проводить нет необходимости в моем случае.

Объясню, почему думаю про утечку памяти через приложение.

приложение в своей работе взаимодействует с dbf Файлами. Взаимодействует через ADO.
А так как, у microsoft есть ограничение на количество ADO соединений,
при наличии на компьютере установленного BDE - 1 соединение, то другие программы,
использующие dbf работать не могут - при обращении к dbf возникает ошибка драйвера.
Раньше пользователи поработав в "чудесном" приложении закрывали его, чтобы работать
в другом.
У microsof я нашел решение с внесением изменений в реестр, которое позволяет обходить
данное ограничение. Теперь пользователям не надо закрывать одно приложение, чтобы работать в другом.

т.е. длительность работы в "чудесном" приложении увеличилась.

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

Dimitry Sibiryakov
Если ты прав, то переход на TCP и localhost может решить проблему.


В настроечном файле приложения указываю путь к БД в виде "IP-адрес:путь к БД".
Или это внутри приложения дополнительно определяется тип коннекта?

hvladСергейВП,

раз мониторинг недоступен, то остаётся трейс. Я бы искал незакрытые запросы, тр-ции и коннекты.

Да собственно этим и займусь с понедельника. Буду мониторить незакрытые коннекты.

Приветствую.
Вот результаты мониторинга количества коннектов к серверу и объемов потребляемой памяти + виртуальной.

Видно, что при относительно постоянном количестве коннектов объем используемой FB памяти увеличивается.
Что можно сказать о причинах?

Память

Симонов Денис
по графику в принципе ничего сказать невозможно

А разве рост постоянный потребляемой памяти сервером при условии, что программа не закрывается это нормально?

Симонов Денис Есть момент когда память резко упала. Вот и ищи что тогда произошло. Может натолкнёт на мысль.

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

Пока мне видится только одно решение:
Мониторить потребляемую память и при достижении, например, 1.8Гб отправлять по электронной почте информацию о необходимости срочно все выйти из приложения и заново зайти.

Чтобы не изобретать велосипед - не подскажите ли существующие утилиты для мониторинга памяти с возможностью отправки информации по электронной почте?