Добрый день.

Windows Server 2008 R2, Firebird 2.5.8 SuperClassic.

Буквально на днях провели апгрейд до 2.5.8 с версии 2.5.2, на которой без особых проблем находились с 2012 года, поскольку в версии 2.5.2 обнаружился неприятный баг c медленной работой sweep .

Конфигурационные файлы сохранили (в основном, почти все было установлено по умолчанию, кроме директории для временных файлов и размера прироста файла базы данных, по необходимости могу выложить), security базу данных сохранили. Клиентские библиотеки (fbclient.dll), конечно, тоже обновили.

На Firebird работает сайт средней посещаемости и инфраструктурные проекты, обслуживающие данные, релевантные для сайта.

В процессе эксплуатации обнаружилась проблема. Через некоторое время Firebird перестает отвечать на запросы клиентов. Клиенты, подключенные ранее, также перестают получать ответ от сервера и зависают. Проверка показывает следующее:

- В логе firebird.log ничего особенного нет.
- Большое число owner(s) в fb_lock_print. Свыше 1000. Ранее на 2.5.2 при той же нагрузке наблюдались числа не более 300-400.
- Большое число TCP-соединений к серверу. Отслеживаем через netstat -ano.
- Сервер не принимает новые коннекты, не получается проверить мониторинговые таблицы, сессии ISQL (и обычный пользователь, и SYSDBA) зависают.
- При попытке сделать gfix -shut single -force 0 сервер не закрывает соединения. Число owners в fb_lock_print остается большим.
- Попытка остановить сервер через остановку службы Windows net stop servicename не приводит к успеху. Выдается сообщение, что служба не может быть остановлена.
- Убийство процесса и перезапуск службы через некоторое время приводят к той же ситуации.

Повторюсь, что на 2.5.2 всё то же самое работало годами без проблем.
Известно ли о каких-то особенностях 2.5.8 SuperClassic по сравнению с 2.5.2 SuperClassic, которые могут привести к накоплению соединений (судя по всему, они не освобождаются) и чему-то похожему?

Повторюсь, что клиентские библиотеки fbclient.dll на серверах-клиентах (таких как фронтенд) обновили до актуальной версии. Исходный код для работы с базой данных - Библиотека UIB. Могло ли измениться что-то в 2.5.8 по сравнению с 2.5.2 настолько, что версия UIB, работавшая без проблем с 2.5.2, сломается на 2.5.8?

Спасибо заранее.

P.S. Триггеров на события вроде коннект/дисконнект нету. Вообще среди Database-триггеров есть только ON TRANSACTION COMMIT, где исследуется контекстная переменная USER_TRANSACTION и в зависимости от ее некоторых значений, данные дополняются. Процессы, связанные с этим кодом, отрабатывают, если успевают до того, как сервер перестанет отвечать.

Dimitry SibiryakovIgor IvkinБольшое число TCP-соединений к серверу. Отслеживаем через netstat -ano.

Ну а пойти и дать по шапке тем, кто установил такое количество подключений?.. 1000
коннектов это жёсткий предел для супера на винде.


Проблема в том, что их столько нет. Возможно, сервер не освобождает закрытые соединения, т.к. клиентов столько нет и не бывает. Поэтому я спросил, не известно ли о каких-то изменениях в 2.5.8 по сравнению с 2.5.2, которые могли бы спровоцировать такое поведение.

P.P.S. В коде, конечно же, используется пулинг коннектов посредством библиотеки UIB. То есть создается пул коннектов, после освобождения коннект попадает в пул и пытается переиспользоваться.

Симонов ДенисIgor Ivkin,

а где гарантия что этот пул правильно работает?

Ну, он работал без проблем с 2012 года на 2.5.2. С этим как раз и связана часть моего вопроса.

Igor IvkinМогло ли измениться что-то в 2.5.8 по сравнению с 2.5.2 настолько, что версия UIB, работавшая без проблем с 2.5.2, сломается на 2.5.8?

kdvIgor IvkinВ коде, конечно же, используется пулинг коннектов посредством библиотеки UIB
во всех клиентских приложениях? это клиент-сервер, или веб?

Да, во всех клиентских приложениях. Клиенты представляют собой:
1. веб-сайт средней или даже небольшой посещаемости (несколько сотен тысяч человек в месяц).
2. приложения, которые на ежедневной основе обновляют БД актуальными данными.
3. приложения, которые генерируют различные отчеты на основе данных из БД.

Сайт преимущественно читает, 2 группа приложений преимущественно пишет, 3 группа приложений преимущественно читает.

Гаджимурадов РустамIgor Ivkin> Проблема в том, что их столько нет.

Так, подожди. Эти 1000 коннектов (какая часть из них орфанные?) появились после перехода на 2.5.8 ?


Именно так, на 2.5.2 много лет всё было нормально. В моменты пиковых нагрузок, когда и все приложения работали, и пользователей прибегало много, число owner(s) в fb_lock_print было в районе 300-400.

Симонов ДенисIgor IvkinДа, это очень похоже на мой случай. Разрыв составляет 2 000 000 транзакций, работает уже третьи сутки.

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

Можно попробовать на тестовом стенде включить трассировку и посмотреть как там ваш пул работает

Вышеуказанный разрыв произошел из-за инцидента в дата-центре (Европа). Пропал интернет во время самых активных ночных обновлений, что-то откатилось, что-то зависло. В целом с прошлого подобного инцидента в 2015 году (да, инциденты очень редкие и каждый помнится), разрыв между OIT и OST всегда держался минимальный.

kdvIgor Ivkinразрыв между OIT и OST всегда держался минимальный.
забейте вы на этот разрыв. подумаешь, где-то когда-то транзакция реальным роллбэком завершилась. ну и что?

Просто Симонов Денис предположил, что проблема в нашем некачественном софте, раз он допускает подобные разрывы. Я пояснил, что такой инцидент с разрывом - уникальный за три года, прошлый был в 2015 году из-за ошибки в коде. То есть обсуждаемый пул коннектов в целом с транзакциями и соединениями обращается аккуратно, счетчики не подвисают, ну и на версии 2.5.2 проблем, описанных в стартовом сообщении, не было никогда с 2012 года, пока мы на ней.

Dimitry SibiryakovСпрошу ещё раз, просто и недвусмысленно: во время зависания сколько TCP коннектов к
серверу Firebird (и от него) показывает netstat? В цифрах, с группировкой по состоянию
(established, time_wait, syn_send и т.д.)


Сейчас дождусь следующего раза и скопирую живые данные.
Пока что решил от отчаяния откатиться на версию поменьше, поставил 2.5.6 SuperClassic, ночь работало без особых проблем, нагрузку создавали, в основном обслуживающие приложения (их несколько десятков, работали одновременно).
Посмотрим ситуацию днём, когда придут посетители.

Симонов ДенисIgor Ivkin, o_v_a

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

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