"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 давно смотрел ? Сколько памяти в наличии ?

--
Хорсун Влад

Ответить