|
FB 3.0.6 долго останавливается
|
|||
---|---|---|---|
#18+
Всем доброго вечера, в сервисах нажал остановить, через какое то время вылетело (точное сообщение н помню) что служба не дождалась остановки. Теперь у сервиса показывает статус "Stopping", уже минут 10 как. Стоит ждать дальше? Раньше с такой длительной остановкой не сталкивался. Спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2020, 21:23 |
|
FB 3.0.6 долго останавливается
|
|||
---|---|---|---|
#18+
hlopotun, sorri, таки остановился. Какую лучше делать профилактику что бы так не происходило? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2020, 21:24 |
|
FB 3.0.6 долго останавливается
|
|||
---|---|---|---|
#18+
Обновление до 3.0.7. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2020, 22:56 |
|
FB 3.0.6 долго останавливается
|
|||
---|---|---|---|
#18+
hlopotun Какую лучше делать профилактику что бы так не происходило? Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
29.11.2020, 06:58 |
|
FB 3.0.6 долго останавливается
|
|||
---|---|---|---|
#18+
У нас после апгрейда Firebird на версию 3.0.7.33374 очень-очень долго стал выполняться shutdown. Минут 20-30 висит команда: Код: sql 1.
Пока 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) и идти к разработчикам? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2021, 09:12 |
|
FB 3.0.6 долго останавливается
|
|||
---|---|---|---|
#18+
bsv9, для начала попробуй текущий снапшот, ибо недавно было вот такое исправление https://github.com/FirebirdSQL/firebird/commit/3f9da90dbb776a7f67e8ea335bec053c5df6f141 Вполне возможно это исправит твой случай ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2021, 09:29 |
|
FB 3.0.6 долго останавливается
|
|||
---|---|---|---|
#18+
Симонов Денисдля начала попробуй текущий снапшот, ибо недавно было вот такое исправление 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 и все нормально работает. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2021, 08:26 |
|
FB 3.0.6 долго останавливается
|
|||
---|---|---|---|
#18+
bsv9 5. В мониторе ресурсов (resmon.exe) видно что оставшиеся в памяти процессы firebird на диск уже, практически, ничего не пишут и не читают. Сброс большого кеша на медленный диск может занять достаточно долгое время. Тем более это классик, а значит каждый процесс сбрасывает свой кеш. Всё это одновременно. В логе есть какие-то записи во время шатдауна ? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2021, 11:14 |
|
FB 3.0.6 долго останавливается
|
|||
---|---|---|---|
#18+
hvladНо всё-таки что-то пишут ? Да, но очень мало. Точно не могу сказать сколько. Помню, что я отсортировал колонку по скорости записи. Обычно там firebird на первом месте. А в этот раз он где то в конце, после фоновых процессов винды оказался. hvladСброс большого кеша на медленный диск может занять достаточно долгое время. Тем более это классик, а значит каждый процесс сбрасывает свой кеш. Всё это одновременно. Я это понимаю. Но раньше то, до 3.0.7 - это очень все быстро происходило. hvladВ логе есть какие-то записи во время шатдауна ? В firebird.log чисто. Никаких ошибок. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2021, 14:01 |
|
FB 3.0.6 долго останавливается
|
|||
---|---|---|---|
#18+
bsv95. В мониторе ресурсов (resmon.exe) видно что оставшиеся в памяти процессы firebird на диск уже, практически, ничего не пишут и не читают. Теперь добавляй в каталог PDB и Process Explorer-ом смотри стэки этих процессов. Увидишь что-то интересное (например, ожидание чего-то) - показывай сюда. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2021, 14:09 |
|
FB 3.0.6 долго останавливается
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, PDB уже лежит. Дампы процессов, я могу снять, с помощью procdump64.exe. Но эти дампы, наверное, все таки, не сюда надо, а разработчикам, через треккер отдать? Так же правильно будет? Или речь о другом? Я с Process Explorer-ом, практически, не работал, поэтому не уверен, что правильно понял, что надо в нем сделать. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2021, 14:26 |
|
FB 3.0.6 долго останавливается
|
|||
---|---|---|---|
#18+
bsv9Я с Process Explorer-ом, практически, не работал, поэтому не уверен, что правильно понял, что надо в нем сделать. Ткнуть в процесс, ткнуть в пункт всплывающего меню "Свойства", ткнуть в кнопочку "Stack". Далее по обстоятельствам. Можно и разработчикам, но лично мне тоже любопытно. Но не настолько чтобы копаться в дампах. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2021, 14:33 |
|
FB 3.0.6 долго останавливается
|
|||
---|---|---|---|
#18+
bsv9 hvladНо всё-таки что-то пишут ? Да, но очень малоМедленно и мало - не одно и то же. Если на диск пишет ОСь, то и смотреть нужно её процессы. Правильно было бы смотреть на того, кто пишет в файл БД. Resource Monitor позволяет это делать. И мы до сих пор ничего не знаем ни о дисковой подсистеме, ни о FW в БД, ни о кол-ве процессов FB в момент shutdown. bsv9 Я это понимаю. Но раньше то, до 3.0.7 - это очень все быстро происходило. Далее. Насколько я помню, раньше были жалобы на то, что gfix завершается до того, как реально завершится shutdown. И мы это исправляли. Не помню точно - когда. Возможно это имеет отношение и к данному случаю. bsv9 Пробовал перед shutdown, по рекомендации Базиля, отключать всех пользователей, но не помогает - точно так так же зависает gfix. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2021, 14:56 |
|
FB 3.0.6 долго останавливается
|
|||
---|---|---|---|
#18+
hvlad Медленно и мало - не одно и то же. Если на диск пишет ОСь, то и смотреть нужно её процессы. Правильно было бы смотреть на того, кто пишет в файл БД. Resource Monitor позволяет это делать. Да, я на это смотрел. Когда отсортировал процессы по скорости write, то видел, что самые активные писатели писали в другие файлы, а не в базу. Причем эта их активность была далеко не чрезмерная. Очереди на дисках, по крайней мере, не было. hvlad И мы до сих пор ничего не знаем ни о дисковой подсистеме, ни о FW в БД, ни о кол-ве процессов FB в момент shutdown. Подсистема такая: 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. hvlad bsv9 Пробовал перед shutdown, по рекомендации Базиля, отключать всех пользователей, но не помогает - точно так так же зависает gfix. Не могу гарантировать, что не было пользователей. У нас используется несколько томкатов и они сразу поднимают новые коннекты, когда их прибивают. Однако "Delete from mon$attachments" и последующий "gfix shutdown" вызывались из батника, без задержки. Возможно, я что то проглядел и дело было не совсем так как я сейчас описываю по памяти. Скриншотов не делал, не документировал. В следующий раз на что мне обратить внимание, что сделать, чтобы локализовать проблему? Достаточно, как Дмитрий говорит, снять стэк? Могу подольше подождать, например, минут 10-15 и потом снять дампы с процессов firebird, которые все еще останутся в памяти. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2021, 16:20 |
|
FB 3.0.6 долго останавливается
|
|||
---|---|---|---|
#18+
bsv9 В firebird FW=OFF. В тех случаях, когда приходилось сталкиваться, "сильно отложенная запись" приводила к поломкам базы. Тормоза, которые "лечили" этой настройкой убирает адекватный страничный кэш. Для (Super)Classic-а это будет 1024 страницы или около того. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2021, 18:57 |
|
FB 3.0.6 долго останавливается
|
|||
---|---|---|---|
#18+
Basil A. Sidorov bsv9 В firebird FW=OFF. Ё-мое, прошу прощения, замкнуло у меня в голове. Конечно, у нас стоит FW=ON. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2021, 19:39 |
|
FB 3.0.6 долго останавливается
|
|||
---|---|---|---|
#18+
Меряли random write IOPS в этом массиве с блоком равным р-ру страницы БД и кол-вом потоков сравнимым с кол-вом коннектов перед шатдауном ? В идеале - на файле сравнимым размером с БД, и уж точ не на 1-2-4 GB (как это обычно делают). Пробовали включить кеш в массиве под БД ? Какой размер страничного кеша этой БД ? Насчёт мониторинга - коннект "исчезает" из мониторинга до того, как будет сброшен кеш БД. Т.е. отсутствие записей в мониторинге не означает окончательного отсутствия процессов, которые скоре всего заняты сбросом своих кешей на диск. Можно снимать стеки и дампы, можно запустить procmon и посмотреть на работу с файлом БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.02.2021, 16:36 |
|
|
start [/forum/topic.php?fid=40&msg=40044019&tid=1560128]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
291ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
63ms |
get tp. blocked users: |
2ms |
others: | 232ms |
total: | 633ms |
0 / 0 |