Не останавливается ФБ-служба при старте sweep'a с OIT=39 млн и OAT=OST=NEXT= 142 млн

Таблоид
Дата: 26.08.2012 10:29:29
hi all

Выношу в отдельный топик результат эксперимента, начатого тут ("что будет с базой, когда NextTran приблизится 2^32").
Запуск теста, в котором isql выполнял сценарий:
SQL> create database 't0.fdb'; commit;
SQL> set term ;^
SQL> set term ^;
SQL> execute block as
CON> declare v int;
CON> begin
CON> while (1=1) do in autonomous transaction do select 1 from rdb$database into v;
CON> end^
- ни к чему хорошему не привёл: рост транзакций с TIL = snapshot (default) резко замедлился, а после isql вообще отвалился.
Повтор этого же теста, но с предварительной установкой TIL = read only read committed, привёл к полному ступору всего сервака.

Тест выполнялся на линухе.
Срубил isql, рестартовал ФБ. Подключился к базе заново (isql), выполнил в нём commit и дальше захотел выйти quit'ом. Результат: isql завис, никакой реакции ни на Ctrl-D, ни на kill -15.
Бактрассу с него снял, выложу с трекер. Но это вопрос, видимо, к линуксовой версии isql.

Дальше я упаковал БД в .rar (см. её в аттаче) и попробовал подключиться к ней на виндузе c WI-V2.5.2.26520.
При подключении в логе ФБ сразу же появилось сообщение о старте sweep'a, ЦПУ стал загружен на 50%:
+
CSPROG	Sun Aug 26 10:04:18 2012
Sweep is started by SWEEPER
Database "C:\TEMP\AAA\ISQL\T0.FDB"
OIT 39794865, OAT 142316400, OST 142316400, Next 142316403

Выход из isql прошел ОК, но службу ФБ остановить невозможно
+

C:\TEMP\AAA\ISQL>isql -n t0.fdb
Database: t0.fdb
SQL> quit;

C:\TEMP\AAA\ISQL>net stop "Firebird Server - FB_25"
Служба "Firebird Server - FB_25" останавливается....
Не удалось остановить службу "Firebird Server - FB_25".


C:\TEMP\AAA\ISQL>net stop "Firebird Server - FB_25"
В текущем состоянии службы управление службой невозможно.

Для вызова дополнительной справки наберите NET HELPMSG 2189.

Пришлось срубать ФБ ProcessExplorer'ом.
Проверьте у себя: подключитесь к базе (см аттач), сможете ли после этого остановить ФБ-службу, когда начнётся sweep ?
Таблоид
Дата: 26.08.2012 11:46:03
Запустил тест на новой базе (старая доломалась - см выше).
Тест выполняет переподключение после каждых 100 тыс транзакций, стартующих с TIL = RO RC.
.sql-скрипт:
+
bash-3.2$ cat chk_tps.sql
commit;
set transaction read only read committed;
set term ^;
execute block as
declare v int;
declare n int = 100000;
begin
while (n>0) do
begin
in autonomous transaction do
select 1 from rdb$database into v;
n=n-1;
end
end^
set term ;^
commit;
-- done --
.sh-запускалка:
+
bash-3.2$ cat chk_tps.sh
i=1
while :
do
echo ................................
date
echo start iter $i
isql -i chk_tps.sql t0.fdb
gstat -h t0.fdb | grep -i "oldest tran"
gstat -h t0.fdb | grep -i "next tran"
i=$(( i + 1 ))
sleep 1
done
Запуск с дублированием вывода в лог:
supertee -n chk_tps.log ./chk_tps.sh
Пока полёт нормальный: на первых 10 млн скорость роста Next не изменилась:
bash-3.2$ head -10 chk_tps.log; tail -10 chk_tps.log
................................
Sun Aug 26 11:11:57 MSK 2012
start iter 1
Oldest transaction 6
Next transaction 100007
................................
Sun Aug 26 11:12:13 MSK 2012
start iter 2
Oldest transaction 100010
Next transaction 200012

................................
Sun Aug 26 11:37:29 MSK 2012
start iter 113
Oldest transaction 11200565
Next transaction 11300567
................................
Sun Aug 26 11:37:42 MSK 2012
start iter 114
Oldest transaction 11300570
Next transaction 11400572
- примерно по 13...15 сек на 100 тыс транзакций.
Надеюсь, что теперь-то он допрёт до заветных Next = 2^32.
Таблоид
Дата: 26.08.2012 12:06:49
PS. Только база всё равно пухнет:
bash-3.2$ ls -la t0.fdb
-rw-rw---- 1 firebird dba 5881856 Aug 26 11:58 t0.fdb
bash-3.2$ ls -la t0.fdb
-rw-rw---- 1 firebird dba 6930432 Aug 26 12:05 t0.fdb
Таблоид
Дата: 26.08.2012 13:52:37
Сейчас, через 2 часа после запуска, рост NextTran немного замедлился и стал в среднем 16-17 сек (на 100 тыс) против первоначальных 13-15:
+
................................
Sun Aug 26 13:46:01 MSK 2012
start iter 614
Oldest transaction 61303070
Next transaction 61403072
................................
Sun Aug 26 13:46:17 MSK 2012
start iter 615
Oldest transaction 61403075
Next transaction 61503077
................................
Sun Aug 26 13:46:34 MSK 2012
start iter 616
Oldest transaction 61503080
Next transaction 61603082
................................
Sun Aug 26 13:46:51 MSK 2012
start iter 617
Oldest transaction 61603085
Next transaction 61703087
................................
Sun Aug 26 13:47:07 MSK 2012
start iter 618
Oldest transaction 61703090
Next transaction 61803092
................................
Sun Aug 26 13:47:23 MSK 2012
start iter 619
Oldest transaction 61803095
Next transaction 61903097
................................
Sun Aug 26 13:47:39 MSK 2012
start iter 620
Oldest transaction 61903100
Next transaction 62003102
................................
Sun Aug 26 13:47:55 MSK 2012
start iter 621
Oldest transaction 62003105
Next transaction 62103107
База вспухла до 16891904 байт.

Вот этого я уже не понимаю: есть коннект, он делает 100 тыс автономных транзакций и отсоединяется. Затем новый коннект делает то же самое.
Откуда рост файла базы ? Почему снова замедляется кол-во транзакций в секунду (пусть и ненамного, но - уже видно, что на 3 сек медленнее) ?
Dimitry Sibiryakov
Дата: 26.08.2012 14:00:50

Таблоид
Откуда рост файла базы ?

Тебе же уже сказали - ТIP-ы.

Posted via ActualForum NNTP Server 1.5

Таблоид
Дата: 26.08.2012 16:34:35
Срубил я этот тест. Ибо ошибся в 60 раз, когда вычислял время.
При скорости 6250 транзакций в секунду и "емкости" TIP = 2^31 время в пути составит 238 дней - что-то действительно долго.
Впрочем, один результат из этой ошибки всё же получен: разницу Next - OIT больше 100 млн лучше никогда не допускать, какие бы TIL при этом не использовались :-)
dimitr
Дата: 26.08.2012 19:15:16
хорошая иллюстрация того, зачем нужен свип :-) Всем админам читать эту страшилку на ночь.
kdv
Дата: 26.08.2012 20:06:02
Таблоид,

я не понял, какие проблемы. Ну да, ты сам виноват, что после срубания теста со snapshot ты не сделал sweep и у тебя застряла OIT. Но сейчас-то можно запустить sweep и продолжить тест с RC?

И, обрати внимание - в выводе статистики gstat нет sweep interval, а значит он равен 20000, т.е. автосвип включен.

p.s. надо будет попробовать. что-то я не очень понимаю, откуда тормоза. каждый раз производится линейный скан TIP?
Таблоид
Дата: 26.08.2012 20:30:11
kdv
сам виноват, что после срубания теста со snapshot ты не сделал sweep и у тебя застряла OIT.
эээ, нееет! OIT-то застряла, но свип делает "что-то ужасное": службу ФБ при таком зазоре просто невозможно остановить. Это в виндузе.
А в линухе, если к такой базе подключиться через isql, то фиг выйдешь по quit. Не знаю, может там дело и не в свипе вовсе - бактрассу я снял с этого isql и отметил сообщением в трекере.

kdv
сейчас-то можно запустить sweep и продолжить тест с RC?
я его возобновил, ибо погорячился.
При скорости роста 100000 / 16 = 6250 транзакций в секунду лимит в 2^31 транзакций будет достигнут через 2147483648 / (100000 / 16) / 86400 = 4 суток - можно и подождать, короче
В .sh-скрипт добавил вывод на каждой итерации размера файла:
bash-3.2$ cat chk_tps.sh
i=1250
while :
do
echo ................................
date
echo start iter $i
isql -i chk_tps.sql t0.fdb
gstat -h t0.fdb | grep -i "oldest tran"
gstat -h t0.fdb | grep -i "next tran"
ls -l t0.fdb | awk '{print $5,$9}'
i=$(( i + 1 ))
sleep 1
done
Таблоид
Дата: 26.08.2012 20:32:57
kdv
в выводе статистики gstat нет sweep interval, а значит он равен 20000, т.е. автосвип включен.
Да, я это понимаю. Но не понимаю вот чего: раз он включен и срабатывает при каждом переконнекте (ибо там по 100 тыс транзакций "нарост" на каждой итерации .sh-скрипта), то почему TIP'ы приводят к росту .fdb ? Свип делает какие-то попытки "упаковать" TIP ?