Сервер: Linux 3.14.14-gentoo_amd64
Firebird: 3.0.5.33220 Classsic.
Размер базы: 220Gb
Количество одновременных коннектов: ~600 шт

Началось все с того, что на сервере убили ~30 процессов firebird. Не спрашивайте зачем. Нужды в этом особой не было, но так уж случилось. После этого начались проблемы:
1. К базе стало невозможно подключиться.
2. В течении 10 минут количество процессов firebird выросло до 1,5 тыс.
3. gfix -shut single -force 0 - зависает.

С помощью утилиты fb_lock_print -a -d снял дамп менеджера очередей, нашел блокировку:
fb_lock_printLOCK BLOCK 64870616
Series: 3, State: 6, Size: 8, Length: 8, Data: 0
Key: 0001:000000, Flags: 0x00, Pending request count: 1065
Hash que (14): forward: 38456480, backward: 2652656
Requests (1066): forward: 63629224, backward: 36366616
Request 63629224, Owner: 43476928, State: 6 (6), Flags: 0x20

OWNER BLOCK 43476928
Owner id: 83949430767623, Type: 1
Process id: 19546 (Alive), Thread id: 19547
Flags: 0x02 wake
Requests (2545): forward: 29851168, backward: 63629224
Blocks: *empty*
Pending: *empty*


Потом нашел этот процесс [Owner: 43476928] и убил его. Надеялся, что это поможет, но не оправдалось. fb_lock_print, стал сообщать, что хоть процесс и мертв, но ресурс, все равно, остается им заблокирован:
fb_lock_printLOCK BLOCK 64870616
Series: 3, State: 6, Size: 8, Length: 8, Data: 0
Key: 0001:000000, Flags: 0x00, Pending request count: 1065
Hash que (14): forward: 38456480, backward: 2652656
Requests (1066): forward: 63629224, backward: 36366616
Request 63629224, Owner: 43476928, State: 6 (6), Flags: 0x20

OWNER BLOCK 43476928
Owner id: 83949430767623, Type: 1
Process id: 19546 (Dead), Thread id: 19547
Flags: 0x02 wake
Requests (2545): forward: 29851168, backward: 63629224


Надежды на корректный shutdown не осталось. Поэтому прибили все процессы firebird и стали лечиться:
1. Выполнили gfix -mend -ig <database>. В firebird.log показало кучу варинингов и несколько ошибок:
Error: Data page 12975396 {sequence 868380} marked as secondary but contains primary record versions in table T_ACC_BALANCES (128)
Error: Index 1 is corrupt {missing entries for record 656196} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 3 is corrupt {missing entries for record 1069763} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 4 is corrupt {missing entries for record 1005346} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 5 is corrupt {missing entries for record 1069763} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 7 is corrupt {missing entries for record 1217902} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 8 is corrupt {missing entries for record 1069763} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 9 is corrupt {missing entries for record 1217902} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 10 is corrupt {missing entries for record 1262171} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 11 is corrupt {missing entries for record 1069763} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 12 is corrupt {missing entries for record 1069763} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 14 is corrupt {missing entries for record 1005346} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 15 is corrupt {missing entries for record 1069763} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 18 is corrupt {missing entries for record 1069763} in table T_CR_CLIENTS_PARAM (1133)
Error: Index 19 is corrupt {missing entries for record 1217902} in table T_CR_CLIENTS_PARAM (1133)
Validation finished: 15 errors, 336 warnings, 281 fixed

2. Пересоздали индексы на таблицу T_CR_CLIENTS_PARAM (Alter index inactive + active).
3. После этого выполнили gfix -v -full <database>. Ошибок не стало. Запустились. Простой составил ~1:20.

hvladНужно было снять полный дамп памяти с процесса, который не может подключиться. И fb_lock_print -c -a

В следующий раз сделаем.

hvladПодключение пробовали сетевые или локальные (embedded) ?

Только сетевые. embeded - не пробовали.

hvlad Где-то "умный" пул коннектов подсобил ?

Да, java и php со своими пулами.

hvlad Не зависает, а долго работает. Там же 1500 процессов, это не быстро.

Ждали завершения [gfix -shutdown], примерно, 20 минут. После этого решили попробовать убить блокирующий процесс.

hvlad А сколько ждали ? Или в панике лупили на все кнопки подряд ?

Примерно, 10 минут ждали. Мало?

Ошибся. На самом деле, убили всего 4 процесса.

Еще всплыла подробность, может она кому нибудь поможет. Оказывается админ убил не обычные 4 процесса firebird, а это были зомби.

Это были не зомби-процессы в классическом понимании linux, а процессы без коннектов. Увидели их так:
админвыполнил: ps aux | grep апр
Показал апрельские процессы.
потом выполнил:
lsof -p PID
и там у процесса firebird не было TCP, а была такая запись:
firebird 19546 firebird 0u sock 0,6 0t0 3138087777 can't identify protocol

Сразу после их убийства произошел крэш.

Вот здесь http://tracker.firebirdsql.org/browse/CORE-6269 была исправлена проблема с зомби-коннектами в линуксе. Попробуем обновиться.

Однако, разве, может убийство 4 процессов привести к таким фатальным последствиям? Очевидно, проблема в чем то другом.

Как нибудь можно отличить maintance процессы от обычных?

Экий вы сегодня злой.

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