Теперь - подробное описание теста.
Машина-1: с неё к базе TRNTEST (на машину
-2 , с ниже) выполняется коннект (isql'ем от FB 2.5), выполняющий UPDATE единственной строки и НЕ делающий COMMIT:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
SQL> select * from tlock; update tlock set f01=rand()*1000; select * from tlock;
ID F01
============ ============
1 680
ID F01
============ ============
1 983
Назначение этого коннекта объяснялось выше, это - "стопорный болт" для гарантии загрузки всех isql-окон и их одновременного срубания.
Машина-2: Windows 2003 Server SP2, два ядра по 2.4 ГГц, память 1 Гб
На этой машине установлен WI-T3.0.0.30590, SuperServer, и создана база (alias = TRNTEST) и единственной табличкой TLOCK(id int primary key, f01 int) и одной записью в ней (id=1, f01=100).
Кроме того, на этой машине запускается батник следующего вида:
fblogmemo.bat
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
@echo off
if .%1.==.. goto syntax
if .%2.==.. goto syntax
if .%3.==.. goto syntax
set mode=%1
@rem name of firebird process to be scanned by psList + parsing
set fbproc=firebird
@rem where firebird holds its LT dump when crashes:
set fbdump="%ALLUSERSPROFILE%\Application Data\firebird\fb_lock_table.dump"
@rem if exist %fbdump% rar u -ep -m5 -ag_YYYYMMDD_hhmm fb_lock_print_dump %fbdump%
@rem if exist *fb_lock_print_dump*.rar dir *fb_lock_print_dump*.rar | findstr /i /c:fb_lock_print_dump 2>nul
@rem number of test windows to be opened:
set n=%2
@rem seconds between kill test wondows and start new iteration:
set v=%3
@rem name of "main" log for this batch:
set logmain=fbmemo_%mode%_windows_cnt_%n%_interval_%v%.log
@rem path to temp folder where test window errors are logged:
set tmphome=c:\temp\trntest
@rem name of temp log for results of psList:
set logtemp=%tmphome%\tmp.tmp
del %logmain% 2>nul
@ rem. . . . . . . . s t a r t i n g . . . . . . . .
@rem extract column titles from output of psList and put them into "main log" with current timestamp:
pslist -m | findstr /i /c:name >%logtemp% && call :addstamp %logtemp% %logmain%
@rem extract 1st memory snapshot before this run and put it into "main log" with current timestamp:
pslist -m | findstr /i /c:%fbproc% >%logtemp% && call :addstamp %logtemp% %logmain%
set k=1
set inswi=-i
set insql=fbmemo_%mode%.sql
if /i %mode%==idle set inswi=
if /i %mode%==idle set insql=
:m1
@rem . . . . . . . . . . . . l o o p . . . . . . . . .
@echo off
@echo.>>%logmain%
@echo iter # %k%
@echo ##########
if exist *fb_lock_print_dump*.rar echo ACHTUNG: FIREBIRD SERVER HAS BEEN RESTARTED! STOP THIS TEST!
if exist *fb_lock_print_dump*.rar dir *fb_lock_print_dump*.rar | findstr /i /c:fb_lock_print_dump 2>nul
for /L %%i in (1,1,%n%) do start %FB30BIN%\isql localhost/3330:trntest -n %inswi% %insql% 1>nul 2>>%tmphome%\fbmemo_%mode%_%%i.err
@rem we must wait enough time for all test windows loading has been finished:
@echo 1. take some sleep before get memory snapshot. . .
ping -n 10 127.0.0.1>nul
pslist -m | findstr /i /c:%fbproc% >%logtemp% && call :addstamp %logtemp% %logmain%
@rem drop isql which locking record:
@rem pskill ping
pskill isql
@echo 2. take sleep %v% seconds before get memory snapshot. . .
ping -n %v% 127.0.0.1>nul
@rem echo %time% - memory after all test windows were killed: >>%logmain%%
pslist -m | findstr /i /c:%fbproc% >%logtemp% && call :addstamp %logtemp% %logmain%
if exist %fbdump% rar m -ep -m5 -ag_YYYYMMDD_hhmm fb_lock_print_dump %fbdump%
@rem pause
set /a k=k+1
goto m1
:addstamp
@rem . . . . . . . a d d t i m e s t a m p l e f t s i d e . . . . . . .
@rem echo args: 1= %logtemp%, 2 = %logmain%
set /p row=<%1
del %1
for /F "tokens=1-3 delims=,:" %%i in ("%time%") do echo %%i:%%j:%%k %row% >>%2 2>nul
exit /b
:syntax
@echo off
cls
echo.
echo Usage: %0 mode n s
echo where:
echo mode = idle ^| dml ^| psql
echo n = ^<number_of_test_windows^>
echo s = ^<seconds_between_iterations^>
echo.
echo e.g: %0 dml 100 30
pause
:eof
Аргументы, требуемые им на вход:
1.
2.
3.
4.
5.
6.
Usage: fblogmemo.bat mode n s
where:
mode = idle | dml | psql
n = <number_of_test_windows>
s = <seconds_between_iterations>
e.g: fblogmemo.bat dml 100 30
Этот батник:
1) открывает через (start /min ...) нужное число isql-окон, задаваемое входным параметром #2, причём:
1.1) если батнику передан входящий аргумент #1 = idle, то эти окна ничего не делают, просто загружаются и остаются в режиме подсказки "SQL> _"
1.2) если передан аргумент = dml, то каждое из открываемых isql-окон выполнит скрипт с именем = fbmemo_dml.sql, в котором записаны команды, гарантирующие "ступор" всех isql'ей на команде обновления одной и той же записи, а именно - той, которая была залочена коннектом-"паразитом" (см предыдущий пост):
1.
2.
3.
4.
5.
commit;
set transaction wait;
select current_timestamp,k.* from tlock k where id=1;
update tlock set f01=rand()*100000 where id=1; -- упрётся! эта строка занята isql'ем с другой машины
quit;
1.3) если передан аргумент = psql, то каждое из окон выполнит execute block, содержание его аналогично пункту "1.2";
1.3) при передаче аргумента = atrn каждое из окон выполнит execute block с попыткой апдейта в автономной транзакции (было подозрение, что это еще быстрее заставит ФБ отъедать память).
Перед каждым тестом выполнялся рестарт ФБ. Затем сразу же - коннект к этой базе от машины-"паразита" с апдейтом строки таблицы TLOCK.
Далее перед основным циклом (внутри батника) выполняется два вызова psList + findstr:
1) для записи
заголовков столбцов в лог.
2) для записи
начального значения потребляемой процессом firebird'a памяти - когда к нему прицеплен только один коннект с машины-"паразита".
Вот этот фрагмент:
1.
2.
3.
4.
5.
6.
7.
@ rem. . . . . . . . s t a r t i n g . . . . . . . .
@rem extract column titles from output of psList and put them into "main log" with current timestamp:
pslist -m | findstr /i /c:name >%logtemp% && call :addstamp %logtemp% %logmain%
@rem extract 1st memory snapshot before this run and put it into "main log" with current timestamp:
pslist -m | findstr /i /c:%fbproc% >%logtemp% && call :addstamp %logtemp% %logmain%
(вызов подпрограммы
addstamp , добавляющей к строкам вывода psList'a текущее время, эквивалентен по своему результату скармливанию вывода утилите mtee с ключём /t. Но у мну не получилось вызвать эту утилиту в for-цикле, да и раз можно обойтись без неё - тем лучше).
Далее в цикле этого батника (см метку `m1`) выполняется:
1. Проверка наличия в текущем каталоге rar-файла - результата упаковки дампа лок-таблицы. И если он есть, то на консоль будет выведено сообщение, что ФБ рестартовал и тест надо прекращать. Ибо коннект в окне-"паразите" уже не действует как "универсальный ступор" для isql'ей, которые упираются лбами при попытках апдейтов (см предыдущий пост).
Вот эти строки:
1.
2.
if exist *fb_lock_print_dump*.rar echo ACHTUNG: FIREBIRD SERVER HAS BEEN RESTARTED! STOP THIS TEST!
if exist *fb_lock_print_dump*.rar dir *fb_lock_print_dump*.rar | findstr /i /c:fb_lock_print_dump 2>nul
2. Запуск 100500 isql'ей:
1.
for /L %%i in (1,1,%n%) do start %FB30BIN%\isql localhost/3330:trntest -n %inswi% %insql% 1>nul 2>>%tmphome%\fbmemo_%mode%_%%i.err
NB: если каждое isql-окно должно "просто войти" и ничего больше не делать, то переменные %inswi% и %insql% будут пустыми. Если же окно должно выполнить скрипт, то %inswi% равна -i, а %insql% = имени скрипта (fbmemo_dml.sql etc).
3. 10-секундное ожидание (пингом в нулл) загрузки ВСЕХ isql-окошек (их число определяется аргументом номер 2 и сохранено в переменной %n% - см выше for /L %%i in ...).
4. Получение снимка памяти по процессам и парсинг его только для процесса 'firebird', с добавлением слева текущего штампа времени и далее - записью этой строки в накопительный лог %logmain%:
pslist -m | findstr /i /c:%fbproc% >%logtemp% && call :addstamp %logtemp% %logmain%
Этот снимок будет содержать данные по расходу памяти
при загруженных isql'ях. В накопительном логе батника это все
чётные строки данных.
5. Убиение всех isql'ей и ожидание, пока оно выполнится. Поскольку сразу после этого ожидания цикл будет повторен, то было подозрение, что величина этой паузы может как-то влиять на утечку памяти. Дело в том, что внутри ФБ-3 есть специальный поток, который живет 10 секунд с момента последнего коннекта и ждёт следующий коннект. Так сделано, чтобы не пересоздавать этот поток при массовых коннектах. Но мну кажется, что величина этой паузы НЕ влияет. Я делал паузу и в 10 сек, и в 120 - результаты одинаковые:
1.
2.
3.
@rem we must wait enough time for all test windows loading has been finished:
@echo 1. take some sleep before get memory snapshot. . .
ping -n 10 127.0.0.1>nul
6. Повторный снимок памяти процесса 'firebird' после снятия всех isql и логирование его. В накопительном логе все такие снимки - в
нечётных строках с данными.
7. Проверка наличия дампа лок-таблицы в каталоге настроек ФБ. Если он там есть, значит его надо упаковать и удалить оттуда, чтобы следующий запуск теста уже не делал этой же операции:
if exist %fbdump% rar m -ep -m5 -ag_YYYYMMDD_hhmm fb_lock_print_dump %fbdump%
8. Инкремент номера итерации и переход на начало цикла.
...........................................................................................................................................................................
Вот такой, значит, тест получился. И он либо заваливает ФБ, либо переводит его службу в "состояние нестояния".
Сейчас запущу его в режиме работы psql, т.е. чтобы он делал execute block'и, и приведу накопительный лог потребления памяти.
