Зависание сервера FB 2.5 RC2
Зависание сервера FB 2.5 RC2
Имеется база данных под управлением сервера версии FB 2.5 RC2 Classic (Windos XP 32)
В базе есть таблица содержащая порядка ~81тыс. записей.
Обычно выборки проходят нормально. Но раз в несколько дней (непериодично) при попытке выбрать что либо из этой таблицы
сервер дико загружает процессор, и за разумное время не выдает никакого результата.
Опытным путем установлено, что часть записей выбрать можно, но после выборки определённого их количества (например нескольких тысяч)
и наступает указанное зависание.
То же самое происходит если дать команду select count(*) from tablename.
Подскажите пожалуйста в чем может быть причина, в каком направлении ковырять.
В базе есть таблица содержащая порядка ~81тыс. записей.
Обычно выборки проходят нормально. Но раз в несколько дней (непериодично) при попытке выбрать что либо из этой таблицы
сервер дико загружает процессор, и за разумное время не выдает никакого результата.
Опытным путем установлено, что часть записей выбрать можно, но после выборки определённого их количества (например нескольких тысяч)
и наступает указанное зависание.
То же самое происходит если дать команду select count(*) from tablename.
Подскажите пожалуйста в чем может быть причина, в каком направлении ковырять.
Re: Зависание сервера FB 2.5 RC2
Для начала нужно посмотреть, что скажет gstat -r в момент 'зависания'
Re: Зависание сервера FB 2.5 RC2
Устроил "зависание", собрал статистику.
Привожу её ниже.
Но хочу сказать, что в gstat глюк с форматированием (всё время ругается).
Для справки: сейчас к базе данных был подключен только один пользователь из IBExpert.
Во время сбора статистики выполнялась команда select count(*) from tablename
Хочу добавить, что перезагрузка сервера или компьютера после начала периода "зависаний" не приводит к
восстановлению нормальной работы с данной таблицей в даньнейшем.
Привожу её ниже.
Но хочу сказать, что в gstat глюк с форматированием (всё время ругается).
Для справки: сейчас к базе данных был подключен только один пользователь из IBExpert.
Во время сбора статистики выполнялась команда select count(*) from tablename
Хочу добавить, что перезагрузка сервера или компьютера после начала периода "зависаний" не приводит к
восстановлению нормальной работы с данной таблицей в даньнейшем.
Код: Выделить всё
Database header page information:
Flags 0
Checksum 12345
Generation 1761701
Page size 8192
ODS version 11.2
Oldest transaction 410206
Oldest active 1761398
Oldest snapshot 1761398
Next transaction 1761400
Bumped transaction 1
Sequence number 0
Next attachment ID 300
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Mar 31, 2010 10:47:22
Attributes force write
Variable header data:
*END*
can't format message 21:7 -- message system code -4
can't format message 21:9 -- message system code -4
can't format message 21:10 -- message system code -4
ADDRESSES (132)
can't format message 21:11 -- message system code -4
Average record length: 62.75, total records: 83259
Average version length: 9.00, total versions: 529862, max versions: 748
can't format message 21:12 -- message system code -4
can't format message 21:13 -- message system code -4
0 - 19% = 2170
20 - 39% = 373
40 - 59% = 371
60 - 79% = 1416
80 - 99% = 1343
can't format message 21:14 -- message system code -4
can't format message 21:15 -- message system code -4
can't format message 21:16 -- message system code -4
can't format message 21:17 -- message system code -4
0 - 19% = 0
20 - 39% = 0
40 - 59% = 0
60 - 79% = 1
80 - 99% = 51
Re: Зависание сервера FB 2.5 RC2
В программе отсутствует управление тр-циями и накапливается очень много мусора.
total records: 83259
total versions: 529862,
max versions: 748
Т.е. на 83К записей имеются в 7 раз больше версий, причём есть цепочки версий длиной до 748.
Изучайте (в том числе на этом сайте), как работать с тр-циями и всё будет хорошо.
PS это не gstat глючит, это у вас клиент\firebird.msg от 2.5 отсутствует или не правильно установлен
total records: 83259
total versions: 529862,
max versions: 748
Т.е. на 83К записей имеются в 7 раз больше версий, причём есть цепочки версий длиной до 748.
Изучайте (в том числе на этом сайте), как работать с тр-циями и всё будет хорошо.
PS это не gstat глючит, это у вас клиент\firebird.msg от 2.5 отсутствует или не правильно установлен
Re: Зависание сервера FB 2.5 RC2
Спасибо за помощь
Re: Зависание сервера FB 2.5 RC2
Похожий случай помогите!!!
Перешли с FB 2.0 на FB 2.5 RC3 Classic (x86)
она из таблиц содержит почти 2 млн. записей полный объём базы около 2.3 Gb,
при выборке из неё по нескольку раз в день возникает зависание.
Причём кто то первый зависнет с загрузкой процессора, а остальные как бы ждут.
Запись в таблицу идёт почти постоянно в день примерно 1000 новых записей + обновления.
Немного утрочнений.
Записает именно коннект который пишет в эту таблицу, после этого ЛЮБЫЕ запросы (в т.ч. к другим таблицам) к БД подвисают пока не срубишь
пишущее соединение.
Перешли с FB 2.0 на FB 2.5 RC3 Classic (x86)
она из таблиц содержит почти 2 млн. записей полный объём базы около 2.3 Gb,
при выборке из неё по нескольку раз в день возникает зависание.
Причём кто то первый зависнет с загрузкой процессора, а остальные как бы ждут.
Запись в таблицу идёт почти постоянно в день примерно 1000 новых записей + обновления.
Немного утрочнений.
Записает именно коннект который пишет в эту таблицу, после этого ЛЮБЫЕ запросы (в т.ч. к другим таблицам) к БД подвисают пока не срубишь
пишущее соединение.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Re: Зависание сервера FB 2.5 RC2
Ответ тот же что и предыдущему оратору - рихтуйте руки разработчику приложения в части управления транзакциями и накопления мусора.
Re: Зависание сервера FB 2.5 RC2
Я сам разработчик.
Вот сижу и мониторю по таблицам MON$....,
Базу только, что восстановил, она девственна чиста по части мусора.
Как только у одного из клиентов транзакция переходит в состояние IDLE, а другой клиент
пытается поменять только, что прочитанные данные, оба вешаются.
Или ситуация два, одна транцакция не READ_COMMITED читает, а другая READ_COMMITED пишет, всё вешается.
Я конечно не гуру в изоляции транзакций, но ранее такого не наблюдалось, пришлось в программе везде ставить READ_COMMITED
но проблема всё равно не отпала вешаеся по первому случаю,
отлавливаю моменты не пойму из-за чего транзакция иногда уходит в IDLE?
Вот сижу и мониторю по таблицам MON$....,
Базу только, что восстановил, она девственна чиста по части мусора.
Как только у одного из клиентов транзакция переходит в состояние IDLE, а другой клиент
пытается поменять только, что прочитанные данные, оба вешаются.
Или ситуация два, одна транцакция не READ_COMMITED читает, а другая READ_COMMITED пишет, всё вешается.
Я конечно не гуру в изоляции транзакций, но ранее такого не наблюдалось, пришлось в программе везде ставить READ_COMMITED
но проблема всё равно не отпала вешаеся по первому случаю,
отлавливаю моменты не пойму из-за чего транзакция иногда уходит в IDLE?
Re: Зависание сервера FB 2.5 RC2
транзакция в IDLE тогда, когда в ее контексте не выполняется ни один запрос. От сервера это никак не зависит, только от приложения.
для начала попробуйте для транзакций выставить nowait вместо wait. Если вместо зависа посыпятся дедлоки или лок-конфликты, значит проблема в управлении транзакциями. Если все продолжит виснуть, запускайте fb_lock_print -w и смотрите кто на чем висит.
для начала попробуйте для транзакций выставить nowait вместо wait. Если вместо зависа посыпятся дедлоки или лок-конфликты, значит проблема в управлении транзакциями. Если все продолжит виснуть, запускайте fb_lock_print -w и смотрите кто на чем висит.
Re: Зависание сервера FB 2.5 RC2
Проблема в том, что у меня и так все транзакции nowait.
К тому же блокировка выходит, когда одна транзакция читает, а другая в этот момент в ту же таблицу пишет.
обе транзации READ_COMMITED_VERSION NOWAIT
Вот отчёт fb_print_lock
К тому же блокировка выходит, когда одна транзакция читает, а другая в этот момент в ту же таблицу пишет.
обе транзации READ_COMMITED_VERSION NOWAIT
Вот отчёт fb_print_lock
Код: Выделить всё
LOCK_HEADER BLOCK
Version: 17, Active owner: 0, Length: 1048576, Used: 65624
Flags: 0x0001
Enqs: 14274, Converts: 187, Rejects: 8, Blocks: 4
Deadlock scans: 1, Deadlocks: 0, Scan interval: 10
Acquires: 18248, Acquire blocks: 2, Spin count: 0
Mutex wait: 0.0%
Hash slots: 1009, Hash lengths (min/avg/max): 0/ 0/ 3
Remove node: 0, Insert queue: 0, Insert prior: 0
Owners (3): forward: 18744, backward: 58232
Free owners: *empty*
Free locks (4): forward: 19704, backward: 65560
Free requests (3): forward: 65508, backward: 19188
Lock Ordering: Enabled
OWNER BLOCK 18744
Owner id: 4226247819297, type: 1, pending: 65288
Process id: 984 (Alive), thread id: 1868
Flags: 0x04 wait infn
Requests (217): forward: 18840, backward: 65288
Blocks: *empty*
18744 waits on
58232 waits on
23328 waits on nothing.
OWNER BLOCK 23328
Owner id: 4037269258273, type: 1, pending: 0
Process id: 940 (Alive), thread id: 756
Flags: 0x10 sgnl
Requests (143): forward: 25216, backward: 56424
Blocks: *empty*
23328 waits on nothing.
OWNER BLOCK 58232
Owner id: 7868380086305, type: 1, pending: 65172
Process id: 1832 (Alive), thread id: 544
Flags: 0x04 wait infn
Requests (77): forward: 58136, backward: 65172
Blocks: *empty*
58232 waits on
23328 waits on nothing.
Event log:
DEL_OWNER: owner = 23328, lock = 23328, request = 0
DEL_OWNER: owner = 23328, lock = 23328, request = 0
Re: Зависание сервера FB 2.5 RC2
А это через пару минут как диагностируется зависание (в это время ничего не предпринимаю что бы снять блокировку просто наблюдаю)
Код: Выделить всё
LOCK_HEADER BLOCK
Version: 17, Active owner: 0, Length: 1048576, Used: 67292
Flags: 0x0001
Enqs: 14313, Converts: 187, Rejects: 11, Blocks: 4
Deadlock scans: 86, Deadlocks: 0, Scan interval: 10
Acquires: 18393, Acquire blocks: 2, Spin count: 0
Mutex wait: 0.0%
Hash slots: 1009, Hash lengths (min/avg/max): 0/ 0/ 3
Remove node: 0, Insert queue: 0, Insert prior: 0
Owners (6): forward: 18744, backward: 66728
Free owners: *empty*
Free locks (4): forward: 19704, backward: 65560
Free requests: *empty*
Lock Ordering: Enabled
OWNER BLOCK 18744
Owner id: 4226247819297, type: 1, pending: 65288
Process id: 984 (Alive), thread id: 1868
Flags: 0x04 wait infn
Requests (217): forward: 18840, backward: 65288
Blocks: *empty*
18744 waits on
58232 waits on
23328 waits on nothing.
OWNER BLOCK 23328
Owner id: 4037269258273, type: 1, pending: 0
Process id: 940 (Alive), thread id: 756
Flags: 0x10 sgnl
Requests (143): forward: 25216, backward: 56424
Blocks: *empty*
23328 waits on nothing.
OWNER BLOCK 58232
Owner id: 7868380086305, type: 1, pending: 65172
Process id: 1832 (Alive), thread id: 544
Flags: 0x04 wait infn
Requests (77): forward: 58136, backward: 65172
Blocks: *empty*
58232 waits on
23328 waits on nothing.
OWNER BLOCK 65668
Owner id: 5102421147681, type: 1, pending: 66024
Process id: 1188 (Alive), thread id: 2224
Flags: 0x04 wait infn
Requests (9): forward: 58768, backward: 66024
Blocks: *empty*
65668 waits on
58232 waits on
23328 waits on nothing.
OWNER BLOCK 66120
Owner id: 10067403341857, type: 1, pending: 66632
Process id: 2344 (Alive), thread id: 204
Flags: 0x04 wait infn
Requests (9): forward: 66216, backward: 66632
Blocks: *empty*
66120 waits on
58232 waits on
23328 waits on nothing.
OWNER BLOCK 66728
Owner id: 13984413515809, type: 1, pending: 67240
Process id: 3256 (Alive), thread id: 3636
Flags: 0x04 wait infn
Requests (9): forward: 66824, backward: 67240
Blocks: *empty*
66728 waits on
58232 waits on
23328 waits on nothing.
Event log:
DEL_OWNER: owner = 23328, lock = 23328, request = 0
DEL_OWNER: owner = 23328, lock = 23328, request = 0
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Re: Зависание сервера FB 2.5 RC2
Что ещё за "географические новости" READ_COMMITED_VERSION? Только не говори что это идиотизм по имени NO_REC_VERSION...обе транзации READ_COMMITED_VERSION NOWAIT
Re: Зависание сервера FB 2.5 RC2
read_committedDimitry Sibiryakov писал(а):Что ещё за "географические новости" READ_COMMITED_VERSION? Только не говори что это идиотизм по имени NO_REC_VERSION...обе транзации READ_COMMITED_VERSION NOWAIT
rec_version
nowait
Таким образом открываются на данный момент все транзакции в ПО.
Re: Зависание сервера FB 2.5 RC2
А спецы молчат....
Ждать больше не могли, юзеры заели, обещали маляву руководству написать.
Надо было, что то предпринимать.
Перешли на SuperServer в одной из веток прочёл, что помогает.
Действительно проблемы пропали, сделал установку работать на 1-ом CPU,
т.к. есть UDF и я не уверен, что она будет корректно работать.
Может всё таки будут решения с Classic-ом?
Или это глюк сервера? в таком случае придётся ждать до новой сборки.
Ждать больше не могли, юзеры заели, обещали маляву руководству написать.
Надо было, что то предпринимать.
Перешли на SuperServer в одной из веток прочёл, что помогает.
Действительно проблемы пропали, сделал установку работать на 1-ом CPU,
т.к. есть UDF и я не уверен, что она будет корректно работать.
Может всё таки будут решения с Classic-ом?
Или это глюк сервера? в таком случае придётся ждать до новой сборки.
Re: Зависание сервера FB 2.5 RC2
Воспроизводимый пример есть ?denissoft писал(а):А спецы молчат....
PS релиз вчера вышел
Re: Зависание сервера FB 2.5 RC2
Все ждут owner'а 23328, который ничего не ждёт. Это процесс 940.denissoft писал(а):А это через пару минут как диагностируется зависание
Ставим .pdb
Делаем fb_lock_print -m -a > all.html
Снимаем дамп памяти с процесса 940
Оба файла даём нам на анализ.
Re: Зависание сервера FB 2.5 RC2
Чем это подтверждается ?denissoft писал(а):Проблема в том, что у меня и так все транзакции nowait.
К тому же блокировка выходит, когда одна транзакция читает, а другая в этот момент в ту же таблицу пишет.
обе транзации READ_COMMITED_VERSION NOWAIT
Re: Зависание сервера FB 2.5 RC2
интересное кино. Выясняется, что есть еще какая-то udf...
Re: Зависание сервера FB 2.5 RC2
Эх жаль не увидел. Позже заменю.hvlad писал(а):Воспроизводимый пример есть ?denissoft писал(а):А спецы молчат....
PS релиз вчера вышел
Простого воспроизводимого примера нет (надо пробовать писать).
База предствяет из себя хранилице данных.
С одной стороны есть сервис который получает данные из внешних источников и пишет их в БД.
С другой стороны интерфейсная часть с помощью которой люди просматривают данные и делают отчёты.
Последний раз редактировалось denissoft 06 окт 2010, 15:17, всего редактировалось 1 раз.
Re: Зависание сервера FB 2.5 RC2
Поскольку на боевом сервере сейчас стоит SS, будем организовывать тестовый с тем же набором данных.hvlad писал(а):Все ждут owner'а 23328, который ничего не ждёт. Это процесс 940.denissoft писал(а):А это через пару минут как диагностируется зависание
Ставим .pdb
Делаем fb_lock_print -m -a > all.html
Снимаем дамп памяти с процесса 940
Оба файла даём нам на анализ.
Как только всё воспроизведу, отпишусь.