Подскажите куда копать.
Проблема - при большом количестве коротких подключений (около 7500-10000 в день) на фоне 100-200 постоянных соединений (в сутки) через некоторое время - 10-20 дней сервер перестает устанавливать новые соединения.
Ошибки в логе сервера при этом могут быть разнообразные, чаще всего - "не могу подключится к базе Security" или начинает падать служба DCOM или WMI виндов без ошибок в логе FireBird Server
Старые соединения продолжают работать исправно.
Лечится только перезагрузкой сервера Windows - иногда (но это очень редко) нужно перезагрузить Windows два раза (это вообще по мне - непостижимое чудо) чтобы FireBird Server заработал стабильно - после первой перезагрузки работает минут десять а потом опять ошибки подключения.
Ошибка проявляется на Windows Server 2008 - 2012 (тестировалась на 6 конфигурациях). Хуже всего - когда FB ставится на виртуальную машину - там "время жизни" сокращается раза в три.
Firebird используется в режиме Classic (SuperServer для версий 2.хх не предлагать - ресурсов одного ядра для задач не хватает). Баз данных - всего две. Размер - не большой 5-10 Гб
Тестировались версии
- 2.1.17 - оказалась самая стабильная - падает через 10-20 дней
- 2.5.8 - живет при такой нагрузке всего 3-5 дней
версию 3.0.4 начали тестировать (особенно смотрели на режим SuperClassic), но для полноценного теста придется сильно лопатить метаданные и "клиентов", поэтому без уверенности, что там нет этого косяка, красить слона лениво
Подключение к базе -
- постоянный Delphi 7 + IB Controls, библиотека gds32 (из комплекта соответствующего сервера)
- короткие (сессия 1-2 минуты) - 50% тот же Delphi из РАЗНЫХ программок, запускаемых внешними событиями, остальные - php 5.3 с короткими подключениями на 1-2 запроса (пул в данном случае не предлагать - это не решает проблему а только отдаляет смерть на пару дней)

В чем может быть косяк? Куда рыть?
Если ошибка известная - решена ли она в тройке?
Гонял ли кто-то тройку в режиме SuperClassic, когда пару клиентов запустили "убойный" запрос минут на десять - не тормозят ли при этом остальные соединения?

wadman,
нет, не противоречие.
pConnect от php хорош, когда много однородных запросов и примерно ровная нагрузка, но если новые соединения перестали устанавливаться, а нагрузка выросла, то php не может расширить пул соединений и просто падает (с перезагрузкой apache)

Симонов Денисphp 5.3 менять пора на 7.1. Там ошибок море (особенно в PDO) и 5.3 уже не поддерживается.
Скорее смотрим в сторону Nod.js, косяки php уже достали, особенно с русскими названиями файлов под юниксом

но в данном случае проблема с php вторична. Там с FB и winsock что-то происходит. Даже если вообще отключить php, проблема сохраняется, только реже проявляется.

Игорь-PicoMed зачем SuperClassic смотреть? Он там нужен постольку поскольку, сразу SS тестируй.
спасибо, скорректирую тесты

Дегтярев Евгенийесли уже юниксы есть в хозяйстве, почему фб под виндой?
на линухе так проблем точно нет
На юнихе действительно проблем не было ни разу.
Моя бы воля, был бы юних, но у заказчиков такой железный зоопарк, что сам диву даюсь.
НО! огромный плюс FB + Apache + PHP что это везде работает ОДИНАКОВО.
А с юниксом еще и вторая проблема - хорошего сисадмина найти (особенно в глубинке) занятие не для слабонервного.
Сисадмины нынче балованные, им виндовский ГУИ (а еще гламурный JAVA-WEB интерфейс), и мышку подавай с тремя колесиками, чтобы интеллектуальные мозоли в новых интерфейсах наяривать. А по другому задачу в крон они поставить или диск замепить не могут....

hvladВ firebird.log смотрели ?
Варианты ошибок (для 2.1):
1. inconsistent lock table version number; found 3, expected 144
2. Fatal lock manager error: inconsistent lock table version number; found 0, expected 144, errno: 0
3. Fatal lock manager error: inconsistent lock table version number; found 3, expected 144, errno: 183
4. Database: C:\PROGRAM FILES\FIREBIRD\FIREBIRD_2_1\SECURITY2.FDB
lock manager error
5. Database:
Unable to complete network request to host "WIN-N08QDODOF22".
Error while listening for an incoming connection.
ϡ󷭮 𠧰湠泱콪宮 鲯לּ询ᮨ塠履񠠱﫥򠠨౮򮪮백泥㯩 ᥰ汯௰򩮠
6. Database: C:\PROGRAM FILES\FIREBIRD\FIREBIRD_2_1\SECURITY2.FDB
page 789, page type 3 lock denied (216)
7. Database: C:\PROGRAM FILES\FIREBIRD\FIREBIRD_2_1\SECURITY2.FDB
internal gds software consistency check (page in use during flush (210), file: cch.cpp line: 2975)
8. Fatal lock manager error: release when not owner, errno: 0

- именно так ( Database: - пусто) - это запись лога
Логи 2.5 не сохранились, но ошибки такие же по содержанию...

комбинации всегда разные, но результат - один - новые соединения не подключаются.
Обычно перед началом вышеописанных ошибок идут штук 5-10 ошибок
SERVER/process_packet: broken port, server exiting

В списке выше - по частоте встречания

в больших количествах в логах ошибка
INET/inet_error: read errno = 10054
но это ни на что не влияет и я ее принимаю как неизбежное зло при подключении к базе через интернет

hvladEvent log что говорит, когда DCOM\WMI "падает" ? (и что такое - падает ?)
Ошибки WMI:
примерно такие:
Event filter with query "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA "Win32_Processor" AND TargetInstance.LoadPercentage > 99" could not be reactivated in namespace "//./root/CIMV2" because of error 0x80041003. Events cannot be delivered through this filter until the problem is corrected.

Ошибки DCOM:

Регистрация сервера {752073A1-23F2-4396-85F0-8FDB879ED0ED} DCOM не выполнена за отведенное время ожидания.
или
Не удается найти описание для идентификатора события 10010 из источника Microsoft-Windows-DistributedCOM. Вызывающий данное событие компонент не установлен на этом локальном компьютере или поврежден. Установите или восстановите компонент на локальном компьютере.

{752073A1-23F2-4396-85F0-8FDB879ED0ED} - это Microsoft WMI Provider Subsystem Secured Host - частота ошибки 80%
{079AA557-4A18-424A-8EEE-E39F0A8D41B9} - MS XMLDOM - частота - 10%
остальные сервера разнообразные, например ShellWindows; компоненты, естественно установлены и после перезагрузки работает прекрасно
Ошибки WMI и DCOM примерно через полчаса заканчиваются синим экраном, НО! старые соединения с FB продолжают работать!!!

[quot hvlad]netstat что говорит ?[\quot]
В отношении порта 3050:
TCP 192.168.1.122:3050 2:26288 ESTABLISHED
TCP 192.168.1.122:3050 2:26703 ESTABLISHED
TCP 192.168.1.122:3050 client:65303 ESTABLISHED
TCP 192.168.1.122:3050 х.х.х.212:49203 ESTABLISHED
TCP 192.168.1.122:3050 х.х.х.212:51683 ESTABLISHED
TCP 192.168.1.122:3050 х.х.х.194:50572 ESTABLISHED
х.х.х.194 - старые соединения

hvladПод какой учётной записью работает служба Firebird - системной или нет ?
Если под системной - стоит ли галка 'allow to interact with desktop' ?
под системной, галка НЕ стоит

MikeDDИгорь-PicoMed, нигде в логах не появляется что-то типа такого: "Системная ошибка. Код: 8. Недостаточно памяти для обработки этой команды"? Когда ФБ перестает принимать подключения - все остальное работает, другие программы запускаются, с подключением по РДП проблем нет?
Нет, такой ошибки нет.
Ресурсов (память, диск, атомы) хватает с запасом. Гоняли на РАЗНЫХ серверах - Intel и AMD. правда все на 64 битах. Поведение одинаковое
До момента синего экрана RDP подключается
MikeDDвсе остальное работает
сказать сложно - на сервере ничего другого нет, все что там работает (кроме антивируса) все так или иначе работает с базой, но апач продолжает работать и устанавливать новые соединения

Симонов Денисну при желании можно и линух с гуём поставить

Вы меня пугаете ))))
Линукс с гуём на сервере это куче резиновой бабы будет )))
Шутка, конечно, но ума сисадмину это не добавит....

Дегтярев Евгенийphp обновить хотя-бы до 5.6, там вроде мало несовместимых изменений, а хороший код и на 7ке заведется
больной разницы 5.3 - 5.6 на нашей задаче не заметили (на 5.6 на юниксе гемморойно решался вопрос с Win1251, но это бантики)
на 7-ке наш код не завелся, вот и думаем, переписывать под семерку или сразу на nod.js
Хотя в параллельной ветке недели две назад тоже не лучшим образом nod.js + FB описали на нагруженных задачах....
Хотя на файловых задачах nod.js шустрее php будет разов в ...надцать и проблем с юникодом нет...

Ivan_PisarevskyУж не забористей сервера БД с антивирусом.
ООООО-да!
Только объяснить сисадмину что все его проблемы от касперского на сервере порой невозможно.
Как пробить железный "аргумент" - "у других же работает" - фантазии не хватает, а молоток в руки не дают )))

Ivan_Pisarevskyдаже имея под рукой гуёвую оболочку на своем десктопе, запускаю консоль, когда треба чего-нибудь пошаманить в системе.
как мне это знакомо (смотрю на консоли и радуюсь) - жаль в виндах ls не работает )))

hvladОткуда у вас появляется 3 - не могу сказать, но это плохой признак.
Я бы искал причину проблем именно тут. Или кто-то лезет грязными руками в файл лок-таблицы,
или у вас портится память, или...
причина "или" - все остальные проверены и сняты...

hvlad0, скорее всего, - из-за каких-то гонок при инициализации лок-таблицы, или из-за предыдущей ошибки.
можно поподробнее - куда смотреть

hvladДа - невозможно работать одновременно с 32 и 64 битными версиями Firebird на одной машине.
Это касается и embedded процессов тоже.
там только 64 битная версия и НИКОГДА не было 32-х битной, после перезапуска сервера (Windows) все начинает работать и работает дней 20

hvladНасчёт ошибок WMI\DCOM - гугл в помощь, их там таких 100500. Firebird не нужно сюда впутывать.
рад бы, но происходит это одновременно. Возможно и не связанно, но даже не знаю куда копать дальше - смотрю на все что там в этот момент происходит

hvladИгорь-PicoMedОшибки WMI и DCOM примерно через полчаса заканчиваются синим экраном, НО! старые соединения с FB продолжают работать!!!Это охренительная реклама для Firebird - продолжает работать при синем экране :)
Сам в шоке, но это ФАКТ
Если следить за руками в SQL запросах убить базу сложно, за это и люблю FB

hvladДля CS лучше поставить
Тут это уже обсуждалось, с подробностями. Давно, правда...
Спасибо, поставлю. Видать пропустил эту тему