powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / trace со всеми включенными опциями: паузы до 1200 мс после deterministic stored ф-ции.Why?
18 сообщений из 18, страница 1 из 1
trace со всеми включенными опциями: паузы до 1200 мс после deterministic stored ф-ции.Why?
    #38626675
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hi all

Имеется вызов ХП:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
SQL> commit; set transaction no wait; out res.txt; set stat on; select * from sp_customer_reserve(293646); set stat off; rollback; out
;
Current memory = 4626545344
Delta memory = 5589096
Max memory = 5620365704
Elapsed time= 10.78 sec
Buffers = 524288
Reads = 0
Writes 46
Fetches = 647943

Трассировка этого дела с таким вот конфигом:
Код: plaintext
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.
  enabled = true
  log_sweep = true
  log_errors = true

  ####################   A C H T U N G  ##############
  time_threshold = 0
  connection_id=0
  #exclude_filter = %(SELECT)%
  #include_filter = %(DELETE)%
  ####################################################
  log_context = true
#  log_connections = true
  log_transactions = true

  log_statement_prepare = true
  log_statement_start = true
  log_statement_free = true
  log_trigger_start = true
  log_procedure_start = true
  log_function_start = true

  log_statement_finish = true
  log_procedure_finish = true
  log_function_finish = true
  log_trigger_finish = true

  print_plan = true
  print_perf = true
  max_sql_length = 16384
  max_log_size = 9999999999
-показывает, что возникают странно долгие промежутки времени (от 300 до 1200 мс) между окончанием работы функции (именно так: всегда stored-функции) и началом работы следующего "модуля" (как правило before-триггера).

Вот два примера:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
2014-04-26T18: 49:24.757 0 (18451:0x7fa98ae02f98) EXECUTE_FUNCTION_FINISH
        /var/db/fb30/oltp30.fdb (ATT_9306, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:3412
                (TRA_11292740, CONCURRENCY | NOWAIT | READ_WRITE)

Function FN_OPER_INVOICE_ADD:
returns:
param0 = integer, "2100"

      0 ms

2014-04-26T18: 49:25.961 0 (18451:0x7fa98ae02f98) EXECUTE_TRIGGER_START
        /var/db/fb30/oltp30.fdb (ATT_9306, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:3412
                (TRA_11292740, CONCURRENCY | NOWAIT | READ_WRITE)
        DOC_DATA_BIUD FOR DOC_DATA (BEFORE UPDATE)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
2014-04-26T18:49:26.0290 (18451:0x7fa98ae02f98) EXECUTE_FUNCTION_FINISH
        /var/db/fb30/oltp30.fdb (ATT_9306, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:3412
                (TRA_11292740, CONCURRENCY | NOWAIT | READ_WRITE)

Function FN_OPER_INVOICE_ADD:
returns:
param0 = integer, "2100"

      0 ms

2014-04-26T18:49:27.2210 (18451:0x7fa98ae02f98) EXECUTE_PROCEDURE_START
        /var/db/fb30/oltp30.fdb (ATT_9306, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:3412
                (TRA_11292740, CONCURRENCY | NOWAIT | READ_WRITE)

Procedure SP_ADD_DOC_LIST:
param0 = bigint, "3300"
param1 = bigint, "149"
param2 = bigint, "2000"
Просмотр аналогичных участков полного трейса показал, что ВСЕ такие затыки возникают только после выполнения одной и тоже функции:
Код: sql
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.
create or alter function FN_OPER_INVOICE_ADD
returns integer deterministic
AS
declare v_id type of column optypes.id = null;
    declare v_key1 dm_sign;
    declare v_key2 dm_sign;
    declare v_stt varchar(255);
begin
    -- find id for operation "invoice checked, add to avaliable remainders".
    -- Raises exception if it can`t be found.
    -----------------------------------------------------------------------------
    -- ::: NB ::: as of current FB-3 version, deterministic function will re-calc
    -- it's result on EVERY NEW call of the SAME statement inside the same transaction.
    -- http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1081535&msg=15694407
    -- Decided (temply) to return checking rdb$get / rdb$set context variables.
    -----------------------------------------------------------------------------
    v_id=rdb$get_context('USER_SESSION', 'FN_OPER_INVOICE_ADD');
    if (v_id is null) then begin
        v_stt = 'select o.id from optypes o where o.m_qty_sup=:x and o.m_qty_avl=:y';
        v_key1 = -1;
        v_key2 = 1;
        execute statement (v_stt) ( x := :v_key1, y := :v_key2 ) into v_id;
        if (v_id is null) then
        begin
            execute procedure sp_add_to_abend_log( 'ex_record_not_found: '||v_stt||', arg1='''||v_key1||''', arg2='''||v_key2||'''');
            exception ex_record_not_found using( 'OPTYPES', 'm_qty_sup=-1 and m_qty_avl=1' );
        end
        rdb$set_context('USER_SESSION', 'FN_OPER_INVOICE_ADD', v_id);
    end
    
    return v_id;
end

Эта функция может выполнять обращение к базе только один раз: при своём первом вызове с начала сеанса. Дальше она должна выплёвывать константу.
Помимо этой функции, в базе определено еще пяток аналогичных ей, и одна из таких "сестёр" тоже вызывается (fn_oper_retail_reserve()), однако с ней затыков нету.

С базой никто больше не работает, заданий в кроне нет, коннект к ней в данный момент - единственный.

Чем могут быть обусловлены такие странные паузы, причём строго после выполнения одной и той же stored-функции ?

ЗЫ. В аттаче:
1) trace_customer_reserve_293646_full.txt - полный текст трейса
2) trace_customer_reserve_293646_timestamps.txt - результат выжимки из первого только строк с моментами времени и номерами строк (grep -n "2014-04-26T" trace_customer_reserve_293646_full.txt), проблемные места отмаркированы так: " #+++ "
Остальные файлы (по ~800 байт) - это фрагменты из полного трейса, соотв-щие "странным местам".
...
Рейтинг: 0 / 0
trace со всеми включенными опциями: паузы до 1200 мс после deterministic stored ф-ции.Why?
    #38649495
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Поднимаю тему. Ибо вижу снова и снова: необъяснимые затыки в активности ФБ, показываемой трейсом, после завершения deterministic stored-функции. Причём, всё время одной и той же (хотя в базе их десятка два).

Итак.
1) Запущен трейс, его конфиг:
"всё включено", time_threshold = 0
Код: plaintext
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.
enabled = true
  log_sweep = true
  log_errors = true

   time_threshold = 0 

  log_context = true
  log_connections = true
  log_transactions = true

  log_statement_prepare = true
  log_statement_start = true
  log_statement_free = true
  log_trigger_start = true
  log_procedure_start = true
  log_function_start = true

  log_statement_finish = true
  log_procedure_finish = true
  log_function_finish = true
  log_trigger_finish = true

  print_plan = true
  print_perf = true
  max_sql_length = 16384
  max_log_size = 9999999999
2) из isql вызываю некую ХП, которая молотит примерно 60 сек.
3) по завершении вызова вытаскиваю из трейса все моменты времени:
Код: plaintext
grep -n -i "2014-05-22T18:1" trc3333_20140522_181618.log >trc_timestamps.txt
4) открываю в редакторе файл trc_timestamps.txt:
первые его строки
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
2:2014-05-22T18:16:22.3400 (11623:0x7f9f52be62d0) TRACE_INIT
6:2014-05-22T18:16:22.3400 (11623:0x7f9f52be62d0) START_TRANSACTION
11:2014-05-22T18:16:22.3410 (11623:0x7f9f52be62d0) PREPARE_STATEMENT
23:2014-05-22T18:16:22.3410 (11623:0x7f9f52be62d0) EXECUTE_STATEMENT_START
34:2014-05-22T18:16:22.3410 (11623:0x7f9f52be62d0) EXECUTE_PROCEDURE_START
45:2014-05-22T18:16:22.3410 (11623:0x7f9f52be62d0) EXECUTE_PROCEDURE_START
52:2014-05-22T18:16:22.3410 (11623:0x7f9f52be62d0) EXECUTE_PROCEDURE_FINISH
60:2014-05-22T18:16:22.3410 (11623:0x7f9f52be62d0) EXECUTE_PROCEDURE_START
67:2014-05-22T18:16:22.3410 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
74:2014-05-22T18:16:22.3410 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH
- и быстро пробегаю взглядом, где число секунд меняется не на 1, а на 2 и более.

5) Если такие паузы происходят между окончанием и началом <чего-то там>, то отмечаю такие фрагментики строкой "+++++":
Код: plaintext
1.
2.
3.
4.
5.
6.
1381:2014-05-22T18:16:22.8770 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH
1392:2014-05-22T18:16:22.8770 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
1399:2014-05-22T18:16: 22 .8770 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH ++++++++++++++++
1410:2014-05-22T18:16: 24 .8420 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
1417:2014-05-22T18:16:24.8420 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH
1428:2014-05-22T18:16:24.8420 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
Разумеется, меня НЕ интересует обратная ситуация, когда <чего-то там> началось и длилось много-секунд.

5) по мере этого "визуального парсинга" замечаю, что все такие паузы происходят только после окончания функции . Их *нет* после завершения триггеров или ХП. Вот результат:
Код: plaintext
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.
$ grep -A1  "++++" trc_timestamps.txt
1399:2014-05-22T18:16:22.8770 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH ++++++++++++++++
1410:2014-05-22T18:16:24.8420 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
--
3797:2014-05-22T18:16:25.4640 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH +++++++++++
3808:2014-05-22T18:16:26.2100 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
--
3833:2014-05-22T18:16:26.2100 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH +++++++++++
3844:2014-05-22T18:16:27.6680 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
--
6483:2014-05-22T18:16:29.3210 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH ++++++++++++
6494:2014-05-22T18:16:31.0730 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
--
10225:2014-05-22T18:16:34.6720 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH ++++++++++++++
10236:2014-05-22T18:16:36.6590 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
--
13055:2014-05-22T18:16:39.1060 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH +++++++++++++++++++
13066:2014-05-22T18:16:41.0540 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
--
19329:2014-05-22T18:16:43.9390 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH +++++++++++++++
19340:2014-05-22T18:16:45.7890 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
--
21041:2014-05-22T18:16:46.9070 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH++++++++++++++++
21052:2014-05-22T18:16:48.8030 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
--
25931:2014-05-22T18:16:54.8310 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH ++++++++++
25942:2014-05-22T18:16:55.6960 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
--
25967:2014-05-22T18:16:55.6970 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH +++++++++++++++
25978:2014-05-22T18:16:57.0310 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
--
34785:2014-05-22T18:17:00.3880 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH++++++++++++++++++++++++++
34796:2014-05-22T18:17:02.0200 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
--
36713:2014-05-22T18:17:04.4640 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH++++++++++++++++
36724:2014-05-22T18:17:05.9750 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
--
39327:2014-05-22T18:17:08.7440 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH +++++++++++++++++++++++++
39338:2014-05-22T18:17:10.8400 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
--
45913:2014-05-22T18:17:15.1230 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH ++++++++++++++++++++++
45924:2014-05-22T18:17:16.7090 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
--
47769:2014-05-22T18:17:18.3660 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH +++++++++++++++++++++
47780:2014-05-22T18:17:20.2960 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
6) Вытаскиваю фрагменты "сырого трейса" по номерам строк, которые у мну сейчас в файле 'trc_timestamps.txt' для странных пауз. Ниже показаны три примера, где паузы достигали ДВУХ секунд.
6.1) 1399:2014-05-22T18:16:22.8770 . . . 1410:2014-05-22T18:16:24.8420
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
$ cat -n trc3333_20140522_181618.log | tail --lines=+1399 | head -25
  1399  2014-05-22T18:16:22.8770 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH
  1400          oltp30 (ATT_1059, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
  1401          C:\MIX\firebird\fb25\bin\isql.exe:3020
  1402                  (TRA_2016508, CONCURRENCY | WAIT | READ_WRITE)
  1403
  1404  Function FN_OPER_RETAIL_RESERVE:
  1405  returns:
  1406  param0 = integer, "3300"
  1407
  1408        0 ms
  1409
  1410  2014-05-22T18:16:24.8420 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
  1411          oltp30 (ATT_1059, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
  1412          C:\MIX\firebird\fb25\bin\isql.exe:3020
  1413                  (TRA_2016508, CONCURRENCY | WAIT | READ_WRITE)
  1414
  1415  Function FN_OPER_RETAIL_RESERVE:
  1416
  1417  2014-05-22T18:16:24.8420 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH
  1418          oltp30 (ATT_1059, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
  1419          C:\MIX\firebird\fb25\bin\isql.exe:3020
  1420                  (TRA_2016508, CONCURRENCY | WAIT | READ_WRITE)
  1421
  1422  Function FN_OPER_RETAIL_RESERVE:
6.2) 10225:2014-05-22T18:16:34.6720 . . . 10236:2014-05-22T18:16:36.6590
Код: plaintext
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.
$ cat -n trc3333_20140522_181618.log | tail --lines=+10225 | head -25
 10225  2014-05-22T18:16:34.6720 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH
 10226          oltp30 (ATT_1059, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
 10227          C:\MIX\firebird\fb25\bin\isql.exe:3020
 10228                  (TRA_2016508, CONCURRENCY | WAIT | READ_WRITE)
 10229
 10230  Function FN_OPER_RETAIL_RESERVE:
 10231  returns:
 10232  param0 = integer, "3300"
 10233
 10234        0 ms
 10235
 10236  2014-05-22T18:16:36.6590 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
 10237          oltp30 (ATT_1059, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
 10238          C:\MIX\firebird\fb25\bin\isql.exe:3020
 10239                  (TRA_2016508, CONCURRENCY | WAIT | READ_WRITE)
 10240
 10241  Function FN_OPER_RETAIL_RESERVE:
 10242
 10243  2014-05-22T18:16:36.6590 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH
 10244          oltp30 (ATT_1059, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
 10245          C:\MIX\firebird\fb25\bin\isql.exe:3020
 10246                  (TRA_2016508, CONCURRENCY | WAIT | READ_WRITE)
 10247
 10248  Function FN_OPER_RETAIL_RESERVE:
 10249  returns:
6.3) 39327:2014-05-22T18:17:08.7440 . . . 39338:2014-05-22T18:17:10.8400
Код: plaintext
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.
$ cat -n trc3333_20140522_181618.log | tail --lines=+39327 | head -25
 39327  2014-05-22T18:17:08.7440 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH
 39328          oltp30 (ATT_1059, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
 39329          C:\MIX\firebird\fb25\bin\isql.exe:3020
 39330                  (TRA_2016508, CONCURRENCY | WAIT | READ_WRITE)
 39331
 39332  Function FN_OPER_RETAIL_RESERVE:
 39333  returns:
 39334  param0 = integer, "3300"
 39335
 39336        0 ms
 39337
 39338  2014-05-22T18:17:10.8400 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_START
 39339          oltp30 (ATT_1059, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
 39340          C:\MIX\firebird\fb25\bin\isql.exe:3020
 39341                  (TRA_2016508, CONCURRENCY | WAIT | READ_WRITE)
 39342
 39343  Function FN_OPER_RETAIL_RESERVE:
 39344
 39345  2014-05-22T18:17:10.8400 (11623:0x7f9f52be62d0) EXECUTE_FUNCTION_FINISH
 39346          oltp30 (ATT_1059, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
 39347          C:\MIX\firebird\fb25\bin\isql.exe:3020
 39348                  (TRA_2016508, CONCURRENCY | WAIT | READ_WRITE)
 39349
 39350  Function FN_OPER_RETAIL_RESERVE:
 39351  returns:
Чем это всё можно объяснить ? Почему затыки всё время после завершения одной и той же функции ?

ЗЫ. Никаких прочих активностей на хосте нет.
...
Рейтинг: 0 / 0
trace со всеми включенными опциями: паузы до 1200 мс после deterministic stored ф-ции.Why?
    #38649550
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

чего ты привязался к функции, если "затыки" происходят в промежутках между ее выполнениями? ХЗ что там твоя ХП делает в это время. Даже если там банальный селект, то обращения к диску (cache misses) могут давать такой же эффект.
...
Рейтинг: 0 / 0
trace со всеми включенными опциями: паузы до 1200 мс после deterministic stored ф-ции.Why?
    #38649562
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrчего ты привязался к функции, если "затыки" происходят в промежутках между ее выполнениями? ХЗ что там твоя ХП делает в это время. Даже если там банальный селект, то обращения к диску (cache misses) могут давать такой же эффект.Эээ, неееет! :-)
Если бы в промежутках между завершением F1 и началом F2 что-то выполнялось, это было бы зафиксировано мессагами вида execute_<statement | trigger | procedure | function>_start. Ибо трейсу приказано фиксировать все события.
А тут просто НИЧЕГО не происходит!
И самое интересное - всегда по завершении одной и той же функции, FN_OPER_RETAIL_RESERVE:
её DDL
Код: sql
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.
create or alter function FN_OPER_RETAIL_RESERVE
returns integer deterministic
AS
declare v_id type of column optypes.id = null;
    declare v_key1 dm_sign;
    declare v_key2 dm_sign;
    declare v_stt varchar(255);
begin
    -- find id for operation "retail selling - reserve for customer".
    -- Raises exception if it can`t be found.
    -----------------------------------------------------------------------------
    -- ::: NB ::: as of current FB-3 version, deterministic function will re-calc
    -- it's result on EVERY NEW call of the SAME statement inside the same transaction.
    -- http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1081535&msg=15694407
    -- Decided (temply) to return checking rdb$get / rdb$set context variables.
    -----------------------------------------------------------------------------
    v_id=rdb$get_context('USER_SESSION', 'FN_OPER_RETAIL_RESERVE');
    if (v_id is null) then begin
        v_stt = 'select o.id from optypes o where o.m_qty_avl=:x and o.m_qty_res=:y';
        v_key1 = -1;
        v_key2 = 1;
        execute statement (v_stt) ( x := :v_key1, y := :v_key2 ) into v_id;
        if (v_id is null) then
        begin
            execute procedure sp_add_to_abend_log( 'ex_record_not_found: '||v_stt||', arg1='''||v_key1||''', arg2='''||v_key2||'''');
            exception ex_record_not_found using( 'OPTYPES', 'm_qty_avl=-1 and m_qty_res=1' );
        end

       
        rdb$set_context('USER_SESSION', 'FN_OPER_RETAIL_RESERVE', v_id);
    end
    
    return v_id;

end


Функций fn_oper_***, почти дословно повторяющих эту, у мну еще восемь штук.
...
Рейтинг: 0 / 0
trace со всеми включенными опциями: паузы до 1200 мс после deterministic stored ф-ции.Why?
    #38649571
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrДаже если там банальный селект, то обращения к диску (cache misses) могут давать такой же эффект.Кажись, я понял твою мысль: ты говоришь про селект, в котором участвует эта ф-ция.
Блин, но по две секунды паузы - это как-то... "круто" типа...
...
Рейтинг: 0 / 0
trace со всеми включенными опциями: паузы до 1200 мс после deterministic stored ф-ции.Why?
    #38649584
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrХЗ что там твоя ХП делает в это время. Даже если там банальный селект, то обращения к диску (cache misses) могут давать такой же эффект. А, стоп! Хальт!
Если бы затыки были из-за лазания на диск или в кеш операционки, это бы отразилось в статистике ненулевыми read(s). Но их вообще не было! Т.е. всё торчало в страничном кеше ФБ (а он у мну большой, 512К страниц).
...
Рейтинг: 0 / 0
trace со всеми включенными опциями: паузы до 1200 мс после deterministic stored ф-ции.Why?
    #38649587
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я правильно помню, что у классика и суперклассика обеспечение когерентностей кэшей в разных процессах - достаточно ресурсоёмкая операция?
...
Рейтинг: 0 / 0
trace со всеми включенными опциями: паузы до 1200 мс после deterministic stored ф-ции.Why?
    #38649592
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovЯ правильно помню, что у классика и суперклассика обеспечение когерентностей кэшей в разных процессах - достаточно ресурсоёмкая операция?наверное... только у мну SuperServer.
...
Рейтинг: 0 / 0
trace со всеми включенными опциями: паузы до 1200 мс после deterministic stored ф-ции.Why?
    #38649612
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЕсли бы затыки были из-за лазания на диск или в кеш операционки, это бы отразилось в статистике ненулевыми read(s). Но их вообще не было! Т.е. всё торчало в страничном кеше ФБ (а он у мну большой, 512К страниц).
это был лишь пример. Ты не знаешь чего именно делает сервер между вызовами твоей функции. Предполагать что ничего не делает - в крайней степени наивно.
...
Рейтинг: 0 / 0
trace со всеми включенными опциями: паузы до 1200 мс после deterministic stored ф-ции.Why?
    #38649622
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидЕсли бы затыки были из-за лазания на диск или в кеш операционки, это бы отразилось в статистике ненулевыми read(s). Но их вообще не было! Т.е. всё торчало в страничном кеше ФБ (а он у мну большой, 512К страниц).
это был лишь пример. Ты не знаешь чего именно делает сервер между вызовами твоей функции. Предполагать что ничего не делает - в крайней степени наивно.я как раз и терзаюсь сомнениями, что он действительно чего-то делает .
Но если нет read(s) > 0, то значит это не связано с IO. А что еще тогда может так заклинивать, при операциях с данными, сидящими кеше ФБ ?
...
Рейтинг: 0 / 0
trace со всеми включенными опциями: паузы до 1200 мс после deterministic stored ф-ции.Why?
    #38649840
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидА что еще тогда может так заклинивать, при операциях с даннымиТипичные ОСи, что винды, что линухи не являются ОСями реального времени. Гарантировать отклик тебе никто не обязывался. Я к тому, что дело может быть не совсем в ФБ, он всего лишь прикладная программа.
Типа хинт от КО. ;)
...
Рейтинг: 0 / 0
trace со всеми включенными опциями: паузы до 1200 мс после deterministic stored ф-ции.Why?
    #38650653
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидА что еще тогда может так заклинивать, при операциях с данными, сидящими кеше ФБ ?
Было бы прикольно иметь возможность при конкретном затыке писать в лог инфу о загруженности системы, чтобы было понятно кто именно ест ресурсы (очередь к диску, загрузка процессора по-процессно, кол-во памяти). Чтобы можно было понять - это процессор не справился, или винт, или автообновление винды запустилось :)
...
Рейтинг: 0 / 0
trace со всеми включенными опциями: паузы до 1200 мс после deterministic stored ф-ции.Why?
    #38650656
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan_Pisarevskyдело может быть не совсем в ФБ, он всего лишь прикладная программа.Ога. Только странное дело: затыки в 2 секунды всё время на одном и том же месте, после завершения одной и той же stored-функции.
...
Рейтинг: 0 / 0
trace со всеми включенными опциями: паузы до 1200 мс после deterministic stored ф-ции.Why?
    #38696342
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидIvan_Pisarevskyдело может быть не совсем в ФБ, он всего лишь прикладная программа.Ога. Только странное дело: затыки в 2 секунды всё время на одном и том же месте, после завершения одной и той же stored-функции.В общем, всё прояснилось. Позор на мою б о шку.
Одна из ХП обращалась к этой самой deterministic-функции F1 (впрочем, там могло быть обращение и к обычной ХП - см ниже), а затем выполняла несколько действий <M>, среди которых был один сверхтормознутый DML <T>.
После чего делала еще чего-то, также обращающееся к какой-то determ-функции F2.

Ну так вот: трейс при всех включенных параметрах честно показывал старт+финиш F1, затем ФБ начинал делать <M> и, разумеется, упирался в <T>. Далее происходил вызов F2 и трейс опять показывал её старт + финиш.

То, что происходило в <M>, в том числе в <T>, трейс не показывает. Минимальной "гранулой" для показа на сегодня является ХП / функция / триггер, но не отдельные стейтменты внутри этого.
Стейтменты были вне подозрений, пока не запустил трассировку этой ХП на 2.5 - там, слава богу, можно увидеть не просто "PLAN P(NATURAL)", а пусть и винегрет из планов всех стейтментов, но это по-любому хоть какая-то зацепка.

Вот DDL:
Код: plaintext
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.
set term ^;
execute block as
begin
    execute statement 'drop sequence g1'; when any do begin end
end
^
set term ;^
commit;
create sequence g1;
commit;

create or alter procedure p_main returns(dts1 timestamp, n int, dts2 timestamp) as begin end;

recreate table t1(id int primary key using index pk_t1, x int, y int);
commit;
insert into t1 select gen_id(g1,1), round(45 + rand()*59, -1), rand()*30
from rdb$types,rdb$types
rows 5000;
commit;

create index t1_x on t1(x);
commit;

set term ^;

create or alter procedure p0 returns (z int) as
begin
  z=1;
  suspend;
end

^

create or alter procedure p1 returns (dts timestamp) as
begin
  dts = 'now';
  suspend;
end
^

create or alter procedure p2 returns (dts timestamp) as
begin
  dts = 'now';
  suspend;
end
^

create or alter procedure p_main returns(dts1 timestamp, n int, dts2 timestamp) as
begin
    select dts from p1 into dts1;

    with
    c as(
        select a.x, a.id, a.y, sum(b.y) y_acc
        from t1 a
        left join t1 b on a.x=b.x and a.id>=b.id
        group by a.x, a.id, a.y
    )
    ,d as(
        select x, min( iif(y_acc >= x, y_acc, 999999) ) y_first_greater
        from c
        group by x
    )
    select count( distinct c.id )
    from c
    join d on c.x = d.x and c.y_acc <= d.y_first_greater
    into n;

    select dts from p2 into dts2;
    suspend;
end
^
set term ;^
commit;
Запуск:
Код: plaintext
select * from p_main;

Трейс в 2.5 :
Код: plaintext
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.
2014-07-14T22:00:08.7220 (18796:0x7f9bf70e4ab8) EXECUTE_STATEMENT_START
        /var/db/fb25/tmp25.fdb (ATT_4, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb25sc/bin/isql:7037
                (TRA_40, CONCURRENCY | WAIT | READ_WRITE)

Statement 55:
-------------------------------------------------------------------------------
select * from p_main
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 PLAN (P1 NATURAL)MERGE (SORT (SORT (JOIN (D C A NATURAL, D C B INDEX (PK_T1, T1_X)))), SORT (SORT (JOIN (C A NATURAL, C B INDEX (PK_T1, T1_X)))))(P2 NATURAL) 

2014-07-14T22:00:08.7220 (18796:0x7f9bf70e4ab8) EXECUTE_PROCEDURE_START
        /var/db/fb25/tmp25.fdb (ATT_4, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb25sc/bin/isql:7037
                (TRA_40, CONCURRENCY | WAIT | READ_WRITE)

Procedure P_MAIN:

2014-07-14T22:00:08.7220 (18796:0x7f9bf70e4ab8) EXECUTE_PROCEDURE_START
        /var/db/fb25/tmp25.fdb (ATT_4, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb25sc/bin/isql:7037
                (TRA_40, CONCURRENCY | WAIT | READ_WRITE)

Procedure P1:

2014-07-14T 22:00:08 .7220 (18796:0x7f9bf70e4ab8) EXECUTE_PROCEDURE_FINISH
        /var/db/fb25/tmp25.fdb (ATT_4, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb25sc/bin/isql:7037
                (TRA_40, CONCURRENCY | WAIT | READ_WRITE)

Procedure P1:
      0 ms

2014-07-14T 22:00:18 .9720 (18796:0x7f9bf70e4ab8) EXECUTE_PROCEDURE_START
        /var/db/fb25/tmp25.fdb (ATT_4, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb25sc/bin/isql:7037
                (TRA_40, CONCURRENCY | WAIT | READ_WRITE)

Procedure P2:

2014-07-14T22:00:18.9730 (18796:0x7f9bf70e4ab8) EXECUTE_PROCEDURE_FINISH
        /var/db/fb25/tmp25.fdb (ATT_4, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb25sc/bin/isql:7037
                (TRA_40, CONCURRENCY | WAIT | READ_WRITE)

Procedure P2:
      0 ms

2014-07-14T22:00:18.9730 (18796:0x7f9bf70e4ab8) EXECUTE_PROCEDURE_FINISH
        /var/db/fb25/tmp25.fdb (ATT_4, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb25sc/bin/isql:7037
                (TRA_40, CONCURRENCY | WAIT | READ_WRITE)

Procedure P_MAIN:
      0 ms

2014-07-14T22:00:18.9730 (18796:0x7f9bf70e4ab8) EXECUTE_STATEMENT_FINISH
        /var/db/fb25/tmp25.fdb (ATT_4, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb25sc/bin/isql:7037
                (TRA_40, CONCURRENCY | WAIT | READ_WRITE)

Statement 55:
-------------------------------------------------------------------------------
select * from p_main
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 -- ЗДЕСЬ, В 2.5, ЕЩЕ МОЖНО УВИДЕТЬ НАМЁКИ НА ТО, В КУДА РЫТЬ.
-- ПУСТЬ И В ВИДЕ ВИНЕГРЕТА ИЗ ПЛАНОВ РАЗНЫХ СТЕЙТМЕНТОВ, НО ЕСТЬ ХОТЬ ЧТО-ТО!  
 PLAN (P1 NATURAL)MERGE (SORT (SORT (JOIN (D C A NATURAL, D C B INDEX (PK_T1, T1_X)))), SORT (SORT (JOIN (C A NATURAL, C B INDEX (PK_T1, T1_X)))))(P2 NATURAL) 
1 records fetched
  10250 ms, 8 read(s), 8445204 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T1                                  10000   4176212
Трейс в 3.0 :
Код: plaintext
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.
2014-07-14T22:04:00.0380 (12075:0x7f1d1e063740) EXECUTE_STATEMENT_START
        /var/db/fb30/tmp30.fdb (ATT_11, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:7181
                (TRA_9, CONCURRENCY | WAIT | READ_WRITE)

Statement 33:
-------------------------------------------------------------------------------
select * from p_main
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Select Expression
    -> Procedure "P_MAIN" Scan

2014-07-14T22:04:00.0380 (12075:0x7f1d1e063740) EXECUTE_PROCEDURE_START
        /var/db/fb30/tmp30.fdb (ATT_11, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:7181
                (TRA_9, CONCURRENCY | WAIT | READ_WRITE)

Procedure P_MAIN:

2014-07-14T22:04:00.0380 (12075:0x7f1d1e063740) EXECUTE_PROCEDURE_START
        /var/db/fb30/tmp30.fdb (ATT_11, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:7181
                (TRA_9, CONCURRENCY | WAIT | READ_WRITE)

Procedure P1:

2014-07-14T 22:04:00 .0380 (12075:0x7f1d1e063740) EXECUTE_PROCEDURE_FINISH
        /var/db/fb30/tmp30.fdb (ATT_11, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:7181
                (TRA_9, CONCURRENCY | WAIT | READ_WRITE)

Procedure P1:
      0 ms

2014-07-14T 22:04:10 .8640 (12075:0x7f1d1e063740) EXECUTE_PROCEDURE_START
        /var/db/fb30/tmp30.fdb (ATT_11, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:7181
                (TRA_9, CONCURRENCY | WAIT | READ_WRITE)

Procedure P2:

2014-07-14T22:04:10.8650 (12075:0x7f1d1e063740) EXECUTE_PROCEDURE_FINISH
        /var/db/fb30/tmp30.fdb (ATT_11, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:7181
                (TRA_9, CONCURRENCY | WAIT | READ_WRITE)

Procedure P2:
      0 ms

2014-07-14T22:04:10.8650 (12075:0x7f1d1e063740) EXECUTE_PROCEDURE_FINISH
        /var/db/fb30/tmp30.fdb (ATT_11, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:7181
                (TRA_9, CONCURRENCY | WAIT | READ_WRITE)

Procedure P_MAIN:
      0 ms

2014-07-14T22:04:10.8650 (12075:0x7f1d1e063740) EXECUTE_STATEMENT_FINISH
        /var/db/fb30/tmp30.fdb (ATT_11, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:7181
                (TRA_9, CONCURRENCY | WAIT | READ_WRITE)

Statement 33:
-------------------------------------------------------------------------------
select * from p_main
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Select Expression
    -> Procedure "P_MAIN" Scan   -- А В 3.0 - СПЛОШНОЕ ИЗДЕВАТЕЛЬСТВО. ВЫСШЕЙ ПРОБЫ :-) 
1 records fetched
   10826 ms , 8 read(s), 8445206 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T1                                  10000   4176212

ЗЫ. 2 dimitr : отсутствие в 3.0 показа планов всех выполнявшихся внутри модуля стейтментов - может, и не зло. А вот отсутствие даже возможности включить их показ - Центр Мирового Зла. Потеря времени при поиске источника проблемы обеспечена. Как и трёхэтажная ругань тех, кто еще этого не знает.
Либо надо научить трейс выталкивать статистику до уровня отдельных стейтментов внутри модулей.
...
Рейтинг: 0 / 0
trace со всеми включенными опциями: паузы до 1200 мс после deterministic stored ф-ции.Why?
    #38696350
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид> В общем, всё прояснилось. Позор на мою бошку.

Как обычно. :) В твоём другом недавнем топике про deterministic-функции то же самое, поди?

Таблоид> А вот отсутствие даже возможности включить их показ
Таблоид> ...
Таблоид> Либо надо научить трейс выталкивать статистику до
Таблоид> уровня отдельных стейтментов внутри модулей.

Если я правильно понял, то это одно и то же.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
trace со всеми включенными опциями: паузы до 1200 мс после deterministic stored ф-ции.Why?
    #38696353
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамТаблоид> В общем, всё прояснилось. Позор на мою бошку.

Как обычно. :) В твоём другом недавнем топике про deterministic-функции то же самое, поди?Ога :-)

Гаджимурадов РустамТаблоид> А вот отсутствие даже возможности включить их показ
Таблоид> ...
Таблоид> Либо надо научить трейс выталкивать статистику до
Таблоид> уровня отдельных стейтментов внутри модулей.

Если я правильно понял, то это одно и то же.Не, второе ("микро-гранулированный trace") - это было бы действительно круто. Представь: в каком-нить модуле отрабатывает 5 отдельных стейтментов, каждый лезет в базу со своим планом - и трейс их по-отдельности показывает, с планами и со статистикой... Oooh-h, yeah-h!.. :-)
...
Рейтинг: 0 / 0
trace со всеми включенными опциями: паузы до 1200 мс после deterministic stored ф-ции.Why?
    #38696389
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид> Не, второе ("микро-гранулированный trace") - это было бы действительно круто

Ты не понял. Я имею в виду, что твои "первое" и "второе"
одно и то же. Если трейс и научится показывать не только
внешние стейтменты, но и внутримодульные, то, по идее,
они будут показываться аналогично остальным.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
trace со всеми включенными опциями: паузы до 1200 мс после deterministic stored ф-ции.Why?
    #38696407
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов Рустам,

"первое" - это я про возможность показа только ПЛАНОВ (в виде винегрета), как это происходит в трейсе 2.5. Статистика по отдельным стейтментам в 2.5 не показывается.
...
Рейтинг: 0 / 0
18 сообщений из 18, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / trace со всеми включенными опциями: паузы до 1200 мс после deterministic stored ф-ции.Why?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]