Завис Firebird 3.0.5.33125. Classic.
Windows server 2012 R2. RAM 256 Gb.
База 150 Gb, Среднее количество коннектов около 200.

Зависание выражалось в следующем:
1. Никто не может подключиться к базе. При этом, на сервере быстро растет количество процессов firebird.exe
2. Старые коннекты исправно работают, тормозов в них не заметно.
3. Чрезмерной нагрузки на процессоры и диски - нет. Всё на штатном уровне.

Безуспешно пытались сделать базе shutdown.
gfix -shut multi -attach 0 database

Молча отрабатывает, но база, как будто, не гасится. Потому что количество процессов firebird.exe продолжает лавинно расти.
Пришлось отключить сеть и прибить firebird-сервис.

После перезагрузки проверили базу на ошибки. Ошибок нет, только два варнинга:
firebird.logSRV Thu Oct 10 14:04:04 2019
Database: database
Warning: Index 3 misses node on page 9452875 level 1 at offset 12163 in table REMAINDERS (132)


SRV Thu Oct 10 14:04:04 2019
Database: database
Warning: Index 3 has inconsistent left sibling pointer, page 9452875 level 1 at offset 12185 in table REMAINDERS (132)


Запустились, все работает.

Сейчас обнаружили, что вчера в firebird.log была такая ошибка:
firebird.logSRV Thu Oct 10 10:02:21 2019
JProvider::shutdown:
Firebird shutdown is still in progress after the specified timeout

И сегодня, непосредственно перед зависанием еще два таких же сообщения:
firebird.logSRV Thu Oct 10 12:35:49 2019
JProvider::shutdown:
Firebird shutdown is still in progress after the specified timeout


SRV Thu Oct 10 12:35:49 2019
JProvider::shutdown:
Firebird shutdown is still in progress after the specified timeout


Что это за ошибка? Зависание с этим как то связанно?

Не догадался, блин. Спасибо, учту на следующий раз.

hvladИ - снимать полный дамп памяти. Если есть кому на него потом смотреть.


А в Classic-e c какого процесса снимать дамп? У меня их там больше тыщи было...
С любого или есть какая то методика по выбору?

Basil A. Sidorov Сложено для удобства чтения:

for /f "tokens=2" %A in ('tasklist -nh -fi "imagename eq fb_inet_server.exe"') do
@start/b procdump -nobanner -accepteula
-ma %A ProcessName-yymmdd-hhmmss-pid.dmp

Круто, Спасибище !

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

Очень, очень нужен такой документ.
Каждая подобная авария это серьезный стресс для админа. Мало кто в таком состоянии способен быстро и адекватно принимать верные решения. Ошибиться очень легко, а исправить потом уже ничего нельзя.