У нас после апгрейда Firebird на версию 3.0.7.33374 очень-очень долго стал выполняться shutdown. Минут 20-30 висит команда:


Пока gfix висит:
1. Невозможно подключиться к базе, даже под SYSDBA - коннект зависает. Каждая попытка коннекта стартует новый процесс firebird.exe и они все висят.
2. Если на сервере запустить gstat -h database, то он говорит, что база уже находится в single-user maintenance.


Пробовал перед shutdown, по рекомендации Базиля, отключать всех пользователей, но не помогает - точно так так же зависает gfix.
На предыдущих версиях 3.0 такие проблемы не возникали - база всегда уходила в shutdown за несколько секунд.

Firebird Classic на Windows server 2012 R2. RAM 192 Gb. База 170 GB, Среднее количество коннектов - ~200.

Кто нибудь сталкивался с подобным? Что можно сделать, чтобы решить проблему? Снять дампы с процессов, менеджера очередей (fb_lock_print) и идти к разработчикам?

Симонов Денисдля начала попробуй текущий снапшот, ибо недавно было вот такое исправление
https://github.com/FirebirdSQL/firebird/commit/3f9da90dbb776a7f67e8ea335bec053c5df6f141

Вполне возможно это исправит твой случай

Поставил 3.0.8.33404, стало лучше, но все равно "gfix -shutdown single -force 0 database" так и не завершает работу, висит. Но теперь, в отличие от 3.0.7, пока gfix висит, удалось подключиться к базе под SYSDBA и каждая попытка коннекта теперь не оставляет в памяти процесс firebird. То есть, сейчас анамнез такой:
1. Запускаю "gfix -shutdown" - он зависает.
2. Новые коннекты подключиться к базе не могут. Но количество процессов firebird, в отличие от 3.0.7 теперь не растет.
3. В это время gstat -h database, говорит, что база уже находится в single-user maintenance.
4. Удается подключиться к базе под SYSDBA. В MON$ATTACHEMNTS, видно что других коннектов к базе нету.
5. В мониторе ресурсов (resmon.exe) видно что оставшиеся в памяти процессы firebird на диск уже, практически, ничего не пишут и не читают.

То есть, по всем признакам дело выглядит так, как будто shutdown успешно выполнен, но gfix, почему то, не завершает работу. В итоге, подождал 5 минут и убил его. Затем базу перевел в online и все нормально работает.

hvladНо всё-таки что-то пишут ?
Да, но очень мало. Точно не могу сказать сколько. Помню, что я отсортировал колонку по скорости записи. Обычно там firebird на первом месте. А в этот раз он где то в конце, после фоновых процессов винды оказался.

hvladСброс большого кеша на медленный диск может занять достаточно долгое время.
Тем более это классик, а значит каждый процесс сбрасывает свой кеш.
Всё это одновременно.

Я это понимаю. Но раньше то, до 3.0.7 - это очень все быстро происходило.

hvladВ логе есть какие-то записи во время шатдауна ?

В firebird.log чисто. Никаких ошибок.

Dimitry Sibiryakov,
PDB уже лежит. Дампы процессов, я могу снять, с помощью procdump64.exe. Но эти дампы, наверное, все таки, не сюда надо, а разработчикам, через треккер отдать? Так же правильно будет? Или речь о другом? Я с Process Explorer-ом, практически, не работал, поэтому не уверен, что правильно понял, что надо в нем сделать.

Да, я на это смотрел. Когда отсортировал процессы по скорости write, то видел, что самые активные писатели писали в другие файлы, а не в базу. Причем эта их активность была далеко не чрезмерная. Очереди на дисках, по крайней мере, не было.


Подсистема такая: RAID контроллер - LSI MegaRAID SAS 9271-8iCC с батареей и 1ГБ кэша
массив под диск С, где темп и папка с бинарниками firebird и локфайлы - RAID 10 из 6 SAS дисков по 300ГБ на 15000 оборотов, на массиве включен WriteBack, т.е. запишь кешируется в кэш контроллера.
Массив под базу Firebird - RAID10 из 6 SSD SATA дисков (Intel DS 3700) по 200ГБ, на массиве выключен WriteBack, запись идет мимо кэша, сразу на диски.

В firebird FW=OFF.

Обычно, в момент shutdown в памяти ~200 процессов. Однако, в этот раз, было всего ~30.

Не могу гарантировать, что не было пользователей. У нас используется несколько томкатов и они сразу поднимают новые коннекты, когда их прибивают. Однако "Delete from mon$attachments" и последующий "gfix shutdown" вызывались из батника, без задержки.

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

Ё-мое, прошу прощения, замкнуло у меня в голове. Конечно, у нас стоит FW=ON.