"Alexey Popov" ...
Ранее я писал:
Есть БД под FB2.0.3 SS. С ней постоянно работают несколько служебных
программ и периодически пользователи. В служебных программах
происходят только простейшие select/insert, которые выполняются
обычно мгновенно. Там так же сделана сигнализация (вывод в лог) если
какой то запрос будет выполняться слишком долго. И иногда в
попадаются единичные записи о слишком долгом выполнении таких
примитивных sql запросов - до 44 секунд! Время суток - уже когда
пользователи ушли домой, серьёзной нагрузки нет. Запись о замедлении
есть с разных клиентов в одно и тоже время, один из клиентов
находится там где и сервер БД, поэтому проблемы с сетью как бы
отметаются.
Виноват оказался sweep.
Откуда это видно ?
Вот наиболее важные свойства базы:
Database size : 1409 Mb
Page size 8192
ODS version 11.0
Oldest transaction 67773710
Oldest active 67773711
Oldest snapshot 67773711
Next transaction 67786537
Sweep interval: 20000
Как вижно разница скоро достигнет 20000 и сработает sweep. Почему транзацкции застревают - это отдельный вопрос, ранее такого не
было.
Может быть rollback виноват???
OIT застревает или от роллбека, или от лимбо. Это азы.
Но в данном случае я не вижу застрявшего OIT, ибо OAT = OIT + 1, т.е.
есть долгоиграющая тр-ция с номером 67773711. С ней и разбирайся.
Основной вопрос в том, почему sweep полностью блокирует работу сервера даже на
запросе
execute block as begin post_event 'my_event'; end
?
Дисковая никакая ? gstat -r давно смотрел ? Сколько памяти в наличии ?
--
Хорсун Влад