ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Понимание результатов fb_lock_print
119 сообщений из 119, показаны все 5 страниц
  все  
Понимание результатов fb_lock_print
    #38111426
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hi all

Хотелось бы понять, что можно получить с помощью этого инструмента.
Начну со следующего теста.

Дано:
Код: plaintext
1.
2.
3.
4.
C:\MIX\firebird\fb25>isql
Use CONNECT or CREATE DATABASE to specify a database
SQL> create database 't1.fdb'; commit;
SQL> create table t(id int primary key, f01 int); commit;
В отдельном окне запускаю:
Код: plaintext
fb_lock_print -i 1 9999 -d T1.FDB | mtee fblockprint.log
(будет с интервалом 1 сек выводить в лог всю инфу из лок-таблицы, и делать это на протяжении 9999 секунд)

Далее:

Код: plaintext
1.
session #1
SQL> insert into t values(1,1); -- см ниже в логе fb_lock_print'a: "insert_1"

Запускаю еще один isql:
Код: plaintext
1.
2.
session #2
SQL> insert into t values(1,1); -- см ниже в логе fb_lock_print'a: "insert_2"
-- бесконечно ждёт, т.к. открыл транзакцию в default-режиме wait. Даю ему выждать около 40 сек.

Код: plaintext
1.
2.
3.
4.
5.
6.
session #1
SQL> commit;

session #2
Statement failed, SQLSTATE = 23000
violation of PRIMARY or UNIQUE KEY constraint "INTEG_2" on table "T"
Останавливаю fb_lock_print и смотрю в его лог (нули удалены для улучшения читабельности):
 
20:06:19 acquire/sacqwait/s%acqwaitacqrtry/srtrysuc/senqueue/sconvert/sdowngrd/sdequeue/sreadata/swrtdata/sqrydata/sdblop/srellop/spagelop/stranlop/srelxlop/sidxxlop/smisclop/swait/sreject/stimeout/sblckast/swakeup/sdlkscan/sdeadlck/s20:06:2020:06:2120:06:2220:06:2320:06:2420:06:2520:06:2620:06:27 < insert #1 19199123111941212220:06:2820:06:2920:06:3020:06:3120:06:3220:06:3320:06:3420:06:3520:06:36 < insert in #2 1919913211831413320:06:3720:06:3820:06:3920:06:4020:06:4120:06:4220:06:4320:06:4420:06:4520:06:4611120:06:4720:06:4820:06:4920:06:5020:06:5120:06:5220:06:5320:06:5420:06:5520:06:5611120:06:5720:06:5820:06:5920:07:0020:07:0120:07:0220:07:0320:07:0420:07:0520:07:0611120:07:0720:07:0820:07:0920:07:1020:07:1120:07:1220:07:1320:07:1420:07:1520:07:1611120:07:1720:07:1820:07:19 < commit in #1 1 1313491651120:07:2020:07:2120:07:2220:07:2320:07:2420:07:2520:07:2620:07:2720:07:2820:07:2920:07:3020:07:3120:07:3220:07:3320:07:34
В логе отчётливо видно, что каждые 10 сек (20:06:46, 20:06:56 etc) идёт некий "опрос" чего-то там внутри.

Если подключить третье isql-окно и в нём также попытаться ввести дубликат первичного ключа, то лог покажет вместо единиц двойки (две ожидающих транзакции ?), но в других ячейках будут значения, отличающиеся в разную сторону от случая с двумя окнами:
 
20:18:31acquire/sacqwait/s%acqwaitacqrtry/srtrysuc/senqueue/sconvert/sdowngrd/sdequeue/sreadata/swrtdata/sqrydata/sdblop/srellop/spagelop/stranlop/srelxlop/sidxxlop/smisclop/swait/sreject/stimeout/sblckast/swakeup/sdlkscan/sdeadlck/s20:18:3220:18:3320:18:3420:18:3520:18:36 < insert in #1 23231133211151313320:18:3720:18:3820:18:3920:18:4020:18:4120:18:4220:18:4320:18:4420:18:4520:18:4620:18:4720:18:4820:18:4920:18:5020:18:5120:18:5220:18:5320:18:5420:18:5520:18:5620:18:5720:18:5820:18:5920:19:00 < insert in #2 111141341413320:19:0120:19:02 < insert in #3 515142311132155413420:19:0320:19:0420:19:0520:19:0620:19:0720:19:0820:19:0920:19:1020:19:1120:19:1222220:19:1320:19:1420:19:1520:19:1620:19:1720:19:1820:19:1920:19:2020:19:2120:19:2222220:19:2320:19:2420:19:2520:19:2620:19:2720:19:2820:19:2920:19:3020:19:3120:19:3222220:19:3320:19:3420:19:3520:19:3620:19:3720:19:3820:19:3920:19:4020:19:4120:19:4222220:19:4320:19:4420:19:4520:19:4620:19:4720:19:4820:19:4920:19:5020:19:5120:19:5222220:19:5320:19:5420:19:5520:19:5620:19:5720:19:5820:19:5920:20:0020:20:01 < commit in #1 42819421536121281626920:20:0220:20:0320:20:0420:20:05
ВОПРОСЫ.
1) "Кто" проверяет занятый ресурс 1 раз в 10 сек ?
2) Если проверки идут только 1 разв 10 сек, то почему после commit'a и высвобождения ресурса все ожидающие его транзакции узнают об этом тотчас ?
3) Где можно почитать описание столбцов этого лога ?
...
Рейтинг: 0 / 0
15.01.2013, 20:35:38
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38111433
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
ТаблоидВОПРОСЫ.
RTFM firebird.conf на предмет DeadlockTimeout.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
15.01.2013, 20:44:10
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38111442
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Dimitry SibiryakovТаблоидВОПРОСЫ.
RTFM firebird.conf на предмет DeadlockTimeout.А, точно, псип.
Так. Поставил я 5 сек, рестартанул ФБ. Вижу, что проверки действительно стали чаще.
Повторил эксперимент с четырьмя окнами (одно ввело запись без коммита, остальные три - пытаются ввести дубли в ПК и ждут).
Затем стал срубать все ждущие isql-окна (Ctrl-Break). Вижу, однако, что опрос лок-менеджера продолжает идти - т.е. цифры "3" так и продолжают появляться в логе каждые 5 сек. До тех пор, пока я не срубил первое окно (которое вводило запись).
 
20:47:44acquire/sacqwait/s%acqwaitacqrtry/srtrysuc/senqueue/sconvert/sdowngrd/sdequeue/sreadata/swrtdata/sqrydata/sdblop/srellop/spagelop/stranlop/srelxlop/sidxxlop/smisclop/swait/sreject/stimeout/sblckast/swakeup/sdlkscan/sdeadlck/s20:47:4520:47:4620:47:4720:47:4820:47:4920:47:5020:47:5120:47:5220:47:5320:47:5420:47:5520:47:5620:47:57995211143120:47:5820:47:5920:48:0020:48:0120:48:0220:48:0320:48:0420:48:0520:48:0620:48:07525242411132155514420:48:0820:48:0920:48:1020:48:1120:48:1211120:48:1320:48:14545442411132155514620:48:1520:48:1620:48:1720:48:1820:48:1922220:48:2020:48:2120:48:2220:48:2320:48:24562356424111321555146220:48:2520:48:2620:48:2720:48:2820:48:2933320:48:3020:48:3120:48:3220:48:3320:48:3433320:48:3520:48:3620:48:3720:48:3820:48:3933320:48:4020:48:4120:48:4220:48:4320:48:4433320:48:4520:48:4620:48:4720:48:4820:48:4933320:48:5020:48:5120:48:5220:48:5320:48:5433320:48:5520:48:5620:48:5720:48:5820:48:5933320:49:0020:49:0120:49:0220:49:0320:49:0433320:49:0520:49:0620:49:0720:49:0820:49:0933320:49:1020:49:1120:49:1220:49:1320:49:1433320:49:1520:49:1620:49:1720:49:1820:49:1933320:49:2020:49:2120:49:2220:49:2320:49:2433320:49:2520:49:2620:49:2720:49:2820:49:2933320:49:3020:49:3120:49:3220:49:3320:49:3433320:49:3520:49:3620:49:3720:49:3820:49:3933320:49:4020:49:4120:49:4220:49:4320:49:4431333320:49:4520:49:4620:49:4720:49:4820:49:49437235437328113644323132828136122320:49:5020:49:5120:49:5220:49:5320:49:5420:49:5520:49:5620:49:5720:49:5820:49:59
...
Рейтинг: 0 / 0
15.01.2013, 20:55:40
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38111661
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидЗатем стал срубать все ждущие isql-окна (Ctrl-Break)
думаю, что замена локального коннекта на локалхост и/или использование ctrl-c вместо ctrl-break привнесут разницу. И таки да, тебе об этом уже говорили, причем по обоим пунктам.
...
Рейтинг: 0 / 0
16.01.2013, 09:23:13
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38111972
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrдумаю, что замена локального коннекта на локалхост и/или использование ctrl-c вместо ctrl-break привнесут разницу.При коннектах пяти окон по tcp (и, след-но, ожидании четырёх окон) картина меняется.
Почти каждую секунду в графах acquire/s и acqrtry/s появляются значения: то 1, то 2. При обрубе окон по Ctrl-Break значения в этих графах будут в итоге нулевыми. При коммите и получении сообщений о наружении ПК - также всё сразу в ноль.
 
12:30:25acquire/sacqwait/s%acqwaitacqrtry/srtrysuc/senqueue/sconvert/sdowngrd/sdequeue/sreadata/swrtdata/sqrydata/sdblop/srellop/spagelop/stranlop/srelxlop/sidxxlop/smisclop/swait/sreject/stimeout/sblckast/swakeup/sdlkscan/sdeadlck/s12:30:2612:30:2712:30:2812:30:2912:30:3012:30:31525242411132155514412:30:3212:30:3312:30:3412:30:35545442411132155514612:30:3612:30:3712:30:3854115442411132155514612:30:3912:30:4011112:30:41171717133112:30:423737232411119124514612:30:4311112:30:4412:30:451112:30:4622212:30:4712:30:481112:30:4912:30:501112:30:511112:30:521112:30:531112:30:5412:30:551112:30:5612:30:572212:30:581112:30:5912:31:001112:31:0112:31:022212:31:031112:31:0412:31:051112:31:0612:31:07215212:31:081112:31:0912:31:101112:31:1112:31:122212:31:131112:31:1412:31:151112:31:1612:31:172212:31:181112:31:1912:31:201112:31:211112:31:2212:31:231112:31:2412:31:251112:31:261112:31:2712:31:281112:31:2912:31:301112:31:3112:31:32215212:31:331112:31:3412:31:351112:31:3612:31:372212:31:381112:31:3912:31:401112:31:4112:31:422212:31:431112:31:4412:31:451112:31:4612:31:472212:31:481112:31:4912:31:501112:31:5112:31:522212:31:531112:31:5412:31:551112:31:561112:31:571112:31:581112:31:5912:32:0013149371314272161513121623512:32:0112:32:0212:32:0312:32:0412:32:0512:32:0612:32:0712:32:08
dimitrИ таки да, тебе об этом уже говорили, причем по обоим пунктам.о чём "об этом" ? и у меня не два было "пункта", а три , главный из которых:автор3) Где можно почитать описание столбцов этого лога ?
...
Рейтинг: 0 / 0
16.01.2013, 12:40:19
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38112002
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидо чём "об этом"?
о том, что:
- ctrl-break не равен ctrl-c и не прерывает текущую операцию на сервере
- сервер обнаруживает отвал клиента (твой ctrl-break) и сразу закрывает коннет только в TCP
...
Рейтинг: 0 / 0
16.01.2013, 12:54:13
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38112517
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Вижу (не в первый не в первый раз уже), что когда в логе fb_lock_print -i N M значения равны нулям, то это означает сильный (или полный) ступор.
Создал пустую базу, в ней:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
create table log(
  conn_id int default current_connection, 
  gen_ms int,
  dts timestamp default 'now'
);
commit;
create descending index log_gen_ms on log(gen_ms);
create sequence g;
commit;


Создал следующий .sql-скрипт для одновременного его вызова из большого числа isql-окон:
Код: 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.
set term ^;
execute block as
  declare i bigint = 0;
  declare k int;
  declare n int = 500; -- number of loops in autonom transaction
  declare t timestamp;
  declare v_ms int;
  declare v_min_ms int = 500; -- min threshold for log time of obtaining gen_id
begin
  while(1=1) do begin
    in autonomous transaction do begin
      k=1;
      while (k<=n) do begin
         t=cast('now' as timestamp);
         i=gen_id(g,1);
         v_ms = datediff(millisecond from :t to cast('now' as timestamp));
         if (v_ms > v_min_ms and i >=0 ) then
           insert into log(gen_ms) values( :v_ms );
         if (i<0) then exit;
         k=k+1;
      end
    end
    if (i<0) then exit; -- alter sequence g restart with -9999999999;
  end
end^
set term ;^
commit;


Этот скрипт будет в бесконечном цикле дёргать генератор `g`, засекая время этой операции и записывая его в таблицу `log` в случае превышения некоторого порога (например, 500 мс). Кроме того, если на очередной итерации выяснится, что значение генератора оказалось меньше нуля, то будет немедленное прекращение работы скрипта.

Батник для старта произвольного числа isql-окон:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
@echo off
cls
if .%1.==.. goto syntax
for /L %%i in (1,1,%1) do start /min isql 192.168.31.216/3252:gen_test -i tg.sql -c 75 -n
:syntax
echo.
echo Please specify 1st arg as number of isql windows!..
pause
goto end
:end

Перед началом теста запустил в двух окнах накопительное логирование:
1) fb_lock_print -d:
Код: plaintext
1.
2.
3.
4.
5.
6.
db=gen_test
lthacc=lock_table_hdr.log_$(date +'%Y%m%d_%H%M%S')
while :
do
  supertee -t -a -n $lthacc fb_lock_print -d $db
  sleep 1
done
2) fb_lock_print -i 1 M
Код: plaintext
1.
2.
3.
db=gen_test
lthacc=lock_table_mon.log_$(date +'%Y%m%d_%H%M%S')
supertee -n $lthacc fb_lock_print -i 1 86400 -d $db

Затем запустил с трёх машин в общей сложности около 850 isql-окон.
Конечно, в период установки такого числа коннектов (около 3-4 минут) время дёргания генераторов каждым из них могло быть неадекватным. Интересовало, что будет дальше, когда все коннекты уже войдут в работу. Поэтому я дал им промолотить около 3 часов.

Ну, так вот.
Если взять первые 200 строк лога, упорядоченные по убыванию времени получения gen_id, то получим следующий результат:
 
conn_idgen_msdts880275819:37:181468275819:37:181503275819:37:181106275819:37:181278275819:37:181527275719:37:181017275719:37:181696275719:37:181330275619:37:181260275619:37:18877275519:37:181206275419:37:181615275419:37:181192275419:37:181562275419:37:181044275419:37:181653275319:37:181320275319:37:181646275319:37:18914275319:37:181068275319:37:181418275319:37:181321275319:37:181021275119:37:181517275019:37:181665275019:37:181647275019:37:181650275019:37:181509275019:37:181282275019:37:181501274919:37:181610274919:37:181173274919:37:181266274919:37:181618274919:37:18973274919:37:181092274719:37:181187274619:37:18879274619:37:181432274519:37:181386274519:37:18972274519:37:181074274519:37:181451274519:37:181682274519:37:18925274319:37:181309274319:37:181186274219:37:181410274219:37:181159274119:37:181388274119:37:181415274119:37:181334274119:37:181560274119:37:181004274119:37:181244274019:37:181426274019:37:181012273619:37:181048273519:37:181525273519:37:18988273519:37:18907273519:37:181359273519:37:181664273419:37:181473273419:37:181108273419:37:181486273319:37:181053273319:37:18915273319:37:181105273319:37:181299273319:37:181620273319:37:181663273219:37:181383273219:37:181508272919:37:181547272819:37:181264272619:37:181498272619:37:18942272619:37:181690272619:37:181380272619:37:181283272619:37:181290272619:37:181240272619:37:181289272619:37:181029272519:04:481653272519:04:481367272519:04:481356272519:37:181188272519:37:181293272519:37:181723272519:37:181445272519:37:181097272519:37:181261272519:37:18943272519:37:181605272419:04:481120272419:04:48912272419:04:481672272419:04:481496272419:04:481167272419:04:481322272419:04:481115272419:04:481112272419:04:481350272419:04:481534272319:04:48937272219:37:181582272119:04:481566272119:37:181212272119:37:181172272019:04:481441272019:37:181392272019:37:18897271919:04:481379271919:04:481406271919:04:481203271919:04:481128271919:04:481572271919:37:181629271919:37:181003271919:37:181501271819:04:48980271819:04:481326271619:37:18892271619:37:18935271619:37:181607271519:04:481361271519:04:481473271519:04:481521271519:04:481011271519:37:181712271519:37:181293271419:04:481493271419:04:481358271419:37:181595271419:37:181458271419:37:181020271319:37:181215271219:04:481241271119:04:481603271119:04:481689271119:04:481083271119:37:181427271019:04:481719271019:04:481342271019:04:481025271019:37:181040271019:37:181089270919:04:481701270919:37:181471270919:37:181462270919:37:181354270919:37:181571270819:37:181446270819:37:181007270819:37:181654270819:37:181182270619:04:481681270619:04:481312270619:04:481482270619:37:181052270519:04:481719270519:37:181600270519:37:181485270519:37:181700270419:04:48925270419:04:481261270419:04:481022270419:04:48921270419:37:181310270419:37:181563270419:37:181401270419:37:181357270419:37:181133270419:37:181125270419:37:18989270419:37:181270270419:37:18940270419:37:181606270419:37:18908270419:37:181687270419:37:181531270419:37:181526270419:37:181546270419:37:181301270419:37:18901270419:37:181228270419:37:18882270419:37:181081270419:37:181633270319:04:48915270319:04:481388270319:04:481408270319:04:481644270319:37:181710270319:37:181443270319:37:181306270319:37:181693270319:37:18
Как видно, самые одиозные затыки были в два момента времени: 19:04:48 и 19:37:18 (время на серваке сбито от мск, но это сейчас неважно).

Первому моменту времени в логе fb_lock_print -i 1 N соответствует вот это:
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
18:25:26 acquire/s acqwait/s  %acqwait acqrtry/s rtrysuc/s enqueue/s convert/s downgrd/s dequeue/s readata/s wrtdata/s qrydata/s   dblop/s  rellop/s pagelop/s tranlop/s relxlop/s idxxlop/s misclop/s    wait/s  reject/s timeout/s blckast/s  wakeup/s dlkscan/s deadlck/s 
...
19:04:44     49975      6893        13     49975         0     18316        18      5804     12820       202         0         0         0       294     26932       606         0         0      3524      4028        18         0      5776      7977         0         0 
19:04:45     53449      7201        13     53449         0     20080        20      5687     14375       229         0         0         0       349     30000       687         0         0      3668      4050        20         0      5664      7879         0         0 
19:04:46     24342      3424        14     24342         0      9259         8      2374      6494       103         0         0         0       166     13689       309         0         0      1700      2000         8         0      2363      3462         0         0 
19:04:47         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0 
19:04:48     38368     14863        38     38368         0     11394       115      6990      3511        33         0         0         0       209     11353        99         0         0      3392      6239       113         0      7030     11546         0         0 
19:04:49     45508      6394        14     45508         0     18258        33      4370     13845       226         0         0         0       222     28568       678         0         0      2894      3448        33         0      4384      6880         0         0 
19:04:50     50442      8473        16     50442         0     18843        52      5651     13374       212         0         0         0       229     28006       636         0         0      3610      3954        52         0      5674      8443         0         0
Второму моменту соответствует вот это:
 
Код: plaintext
1.
2.
3.
4.
5.
6.
19:37:15     79353      6565         8     79353         0     35426        15      4480     29958       319         0         0         0       420     61621       957         0         0      2720      3824        15         0      4458      6489         0         0 
19:37:16     85026      6287         7     85026         0     36429        16      4995     31088       331         0         0         0       409     63605       994         0         0      2856      3599        16         0      4982      7020         0         0 
19:37:17     18765       989         5     18765         0      7530         3      1077      6227        66         0         0         0        86     12899       197         0         0       644       881         3         0      1068      1520         0         0 
19:37:18         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0         0 
19:37:19     63297     18048        28     63297         0     23002        92      8260     13218       128         0         0         0       372     32291       385         0         0      3392      7642        90         0      8283     13191         0         0 
19:37:20     80140      6461         8     80140         0     34730        18      3991     30763       330         0         0         0       276     62244       989         0         0      2332      3065        18         0      3991      6350         0         0 
19:37:21     74873      5908         7     74873         0     33204        16      3725     29249       314         0         0         0       245     59318       942         0         0      2278      3038        16         0      3728      6028         0         0

2 dimitr: я помню, что ты мне говорил про эти "нулевые строки", когда шло исследование долгих коннектов. Они возникали при снятии бактрассы fb_smp_server'a одним из мониторных окон. Но сейчас этого нет. Идёт снятие только ЛТ, причём без ключика '-c'.
Отчего тогда могут возникать эти затыки ?
...
Рейтинг: 0 / 0
16.01.2013, 16:42:30
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38112614
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидОтчего тогда могут возникать эти затыки ?
от ожидания на блокировках
...
Рейтинг: 0 / 0
16.01.2013, 17:15:37
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38112635
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrот ожидания на блокировкахну, так вот я и хочу понять: где-то видны эти ожидания ? в развернутом отчете fb_lock_print'a ?
...
Рейтинг: 0 / 0
16.01.2013, 17:21:51
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38112640
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидгде-то видны эти ожидания ? в развернутом отчете fb_lock_print'a ?
конечно. С ключом -w, например.
...
Рейтинг: 0 / 0
16.01.2013, 17:23:01
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38112969
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrТаблоидгде-то видны эти ожидания ? в развернутом отчете fb_lock_print'a ?
конечно. С ключом -w, например.Хорошо, вернусь к начальному примеру.

Код: plaintext
1.
2.
3.
4.
 connect #1 
C:\MIX\firebird\fb25>isql localhost/3050:C:\MIX\firebird\fb25\T1.FDB -n
Database:  localhost/3050:C:\MIX\firebird\fb25\T1.FDB
SQL> commit;
SQL> insert into t values(2,2);

Снимаю ЛТ на этот момент: fb_lock_print -w -d T1.FDB
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
LOCK_HEADER BLOCK
        Version: 17, Active owner:      0, Length: 1048576, Used:   20868 
        Flags: 0x0001
        Enqs:     19, Converts:      3, Rejects:      0, Blocks:      0
        Deadlock scans:      0, Deadlocks:      0, Scan interval:   5
        Acquires:      36 , Acquire blocks:      0, Spin count:   0
        Mutex wait: 0.0%
        Hash slots: 1009, Hash lengths (min/avg/max):    0/   0/   3
        Remove node:      0, Insert queue:      0, Insert prior:      0
        Owners  (1) :     forward:  18744, backward:   18744 
        Free owners: *empty*
        Free locks (1): forward:  19820, backward:  19820
        Free requests: *empty*
        Lock Ordering: Enabled

Код: plaintext
1.
 connect #2 
SQL> insert into t values(2,2); -- ==> висяк

Снимаю еще раз ЛТ:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
LOCK_HEADER BLOCK
        Version: 17, Active owner:      0, Length: 1048576, Used:   33580 
        Flags: 0x0001
        Enqs:    186, Converts:     10, Rejects:      3, Blocks:      6
        Deadlock scans:      0, Deadlocks:      0, Scan interval:   5
        Acquires:     243 , Acquire blocks:      0, Spin count:   0
        Mutex wait: 0.0%
        Hash slots: 1009, Hash lengths (min/avg/max):    0/   0/   3
        Remove node:      0, Insert queue:      0, Insert prior:      0
        Owners  (2) :     forward:  18744, backward:   20868 
        Free owners: *empty*
        Free locks (1): forward:  19820, backward:  19820
        Free requests: *empty*
        Lock Ordering: Enabled

Далее делал снимок ЛТ в этом же состоянии еще несколько раз:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
@echo off
del lp2.log 2>nul
:m1
  fb_lock_print -w -d T1.FDB | mtee /t tmp.tmp
  type tmp.tmp | findstr /c:Acquires >> lp2.log
  @ping 127.0.0.1 -n 2 > nul
goto m1
Вижу, что увеличивается только счетчик Acquires , на единицу.
С интервалом, равным указанному в firebird.conf значению DeadlockTimeout (у мну он = 5), минус ~0.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.
...
20:48:38.577    Acquires:    528, Acquire blocks:      0, Spin count:   0
20:48:39.718    Acquires:    529, Acquire blocks:      0, Spin count:   0
20:48:40.858    Acquires:    529, Acquire blocks:      0, Spin count:   0
20:48:41.999    Acquires:    529, Acquire blocks:      0, Spin count:   0
20:48:43.155    Acquires:    529, Acquire blocks:      0, Spin count:   0
20:48:44.312    Acquires:    530, Acquire blocks:      0, Spin count:   0
20:48:45.452    Acquires:    530, Acquire blocks:      0, Spin count:   0
20:48:46.593    Acquires:    530, Acquire blocks:      0, Spin count:   0
20:48:47.749    Acquires:    530, Acquire blocks:      0, Spin count:   0
20:48:48.874    Acquires:    531, Acquire blocks:      0, Spin count:   0
20:48:50.015    Acquires:    531, Acquire blocks:      0, Spin count:   0
20:48:51.171    Acquires:    531, Acquire blocks:      0, Spin count:   0
20:48:52.296    Acquires:    531, Acquire blocks:      0, Spin count:   0
20:48:53.452    Acquires:    531, Acquire blocks:      0, Spin count:   0
20:48:54.593    Acquires:    532, Acquire blocks:      0, Spin count:   0
20:48:55.749    Acquires:    532, Acquire blocks:      0, Spin count:   0
20:48:56.905    Acquires:    532, Acquire blocks:      0, Spin count:   0
20:48:58.062    Acquires:    532, Acquire blocks:      0, Spin count:   0
20:48:59.249    Acquires:    533, Acquire blocks:      0, Spin count:   0
20:49:00.421    Acquires:    533, Acquire blocks:      0, Spin count:   0
20:49:01.562    Acquires:    533, Acquire blocks:      0, Spin count:   0
20:49:02.702    Acquires:    533, Acquire blocks:      0, Spin count:   0
20:49:03.843    Acquires:    533, Acquire blocks:      0, Spin count:   0
20:49:04.983    Acquires:    534, Acquire blocks:      0, Spin count:   0
20:49:06.124    Acquires:    534, Acquire blocks:      0, Spin count:   0
...

А как понять, какая транзакция (или коннект ?) и чего именно ждёт ?
...
Рейтинг: 0 / 0
16.01.2013, 20:57:32
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38112984
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидА как понять, какая транзакция (или коннект ?) и чего именно ждёт ?
смотреть вывод утилиты ниже заголовка и интерпретировать его. Я об этом рассказывал на конфе, запись доступна в онлайне.
...
Рейтинг: 0 / 0
16.01.2013, 21:12:31
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38114599
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrЯ об этом рассказывал на конфе, запись доступна в онлайне.Прослушал твой доклад на конфе-2011: http://www.ютуб.com/watch?v=iYNjwbYcjuc - появилось несколько вопросов (частично - потому что не смог перевести какие-то фразы, частично - слова понял, а смысл - нет).
0) время 00:25:43. Там говорится про remap лок-таблицы, когда она упирается в потолок LockMemSize. Вопрос: на сколько увеличивается в размере ЛТ, когда ей становится мало места ?
1) время 00:28:55. Что такое request-статус = 0x100 (Blocking Seen ) ?
2) время 00:38:15. Речь идёт о возможном указании в переменной окружения FIREBIRD_LOCK каталога, в котором будет храниться лок-таблица. И что кто-то там (настроив правильно размер ЛТ и HashSlots, но продолжая иметь траблы с произв-стью), назначил этой переменной каталог на RAM-диске, и у него производительность увеличилась на 50%. Вопросов тут на самом деле два:
2.1) если я правильно перевёл, ты говоришь там, что ЛТ хранится в каталоге установки ФБ. Но почему я вижу файлы fb_lock_XXX всегда в /tmp/firebird ?
2.2) зачем вообще ЛТ вытряхивать на диск, если эта структура актуальна только в момент работы с базой ? Что от неё может "пригодиться", если будет рестарт ФБ или сервака ?
3) Что обозначается в ЛТ под free-объектами (owners; locks; requests) ?
4) Не засёк в докладе места, где бы говорилось вот об этом:
Код: plaintext
Enqs: 881770814, Converts: 564766, Rejects: 523062, Blocks: 1549513
- что такое Enqs, Converts и остальное ?
5.1) Допустим, увижу я в ЛТ, что некий owner, которому соотв-вует thread с id = 12345, является "держимордой" и из-за него всё заклинило. Если этот клиент просто держит что-то, НИЧЕГО не делая, то вычислить его через mon$statements не получится. Как тогда его найти ? (речь идёт о SuperClassic'e, ес-сно).
5.2) Пригляделся я к выводу fb_lock_print -o -d prodfile.fdb и охватил мну ужасный кошмар. Что там за ID'шники у thread'ов ?
Вот вывод этой команды (первые 30 строк):
 
Код: 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.
LOCK_HEADER BLOCK
        Version: 145, Active owner:      0, Length: 16777216, Used: 16294520
        Flags: 0x0001
        Enqs: 882519705, Converts: 567651, Rejects: 524335, Blocks: 1554734
        Deadlock scans:      0, Deadlocks:      0, Scan interval:  10
        Acquires: 921968334, Acquire blocks: 34454946, Spin count:   0
        Mutex wait: 3.7%
        Hash slots: 25013, Hash lengths (min/avg/max):    0/   0/   6
        Remove node:      0, Insert queue:      0, Insert prior:      0
        Owners (97):    forward: 595880, backward: 13323256
        Free owners (208):      forward: 6917456, backward: 1871184
        Free locks (21143):     forward: 1143752, backward: 15860544
        Free requests (145611): forward: 1875848, backward: 15028440
        Lock Ordering: Enabled

OWNER BLOCK 595880
        Owner id: 132684431509074, type: 1, pending:      0
        Process id:  30893 (Alive), thread id:  140170150016784 
        Flags: 0x08       wake
        Requests (828): forward: 514680, backward: 9255104
        Blocks: *empty*

OWNER BLOCK 1941624
        Owner id: 132684431509215, type: 1, pending:      0
        Process id:  30893 (Alive), thread id:  140169882670864 
        Flags: 0x08       wake
        Requests (1184):        forward: 1132872, backward: 8336200
        Blocks: *empty*

OWNER BLOCK 1948720
        Owner id: 132684431509218, type: 1, pending:      0
        Process id:  30893 (Alive), thread id:  140170150016784 
        Flags: 0x08       wake
        Requests (480): forward: 1948656, backward: 14737176
        Blocks: *empty*
...

я никогда не видел такого кошмара: thread id = 140170150016784, как мне сопоставить сиё с выводом потоков для fb_smp_server'a:
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
-bash-4.1$ ps -FLC fb_smp_server
UID        PID  PPID   LWP  C NLWP    SZ   RSS PSR STIME TTY          TIME CMD
firebird 30893  1996 30893 12   12 2136629 3030056 6 2012 ?       6-09:13:20 /opt/firebird/bin/fb_smp_server
firebird 30893  1996 30894  0   12 2136629 3030056 6 2012 ?       00:00:00 /opt/firebird/bin/fb_smp_server
firebird 30893  1996 30895  0   12 2136629 3030056 4 2012 ?       00:19:33 /opt/firebird/bin/fb_smp_server
firebird 30893  1996 30951  0   12 2136629 3030056 2 2012 ?       00:00:00 /opt/firebird/bin/fb_smp_server
firebird 30893  1996 31015  0   12 2136629 3030056 3 2012 ?       00:00:00 /opt/firebird/bin/fb_smp_server
firebird 30893  1996 26692  0   12 2136629 3030056 3 Jan16 ?      00:00:00 /opt/firebird/bin/fb_smp_server
firebird 30893  1996 26693  0   12 2136629 3030056 7 Jan16 ?      00:00:00 /opt/firebird/bin/fb_smp_server
firebird 30893  1996 28811  0   12 2136629 3030056 1 Jan16 ?      00:00:00 /opt/firebird/bin/fb_smp_server
firebird 30893  1996  4146  0   12 2136629 3030056 3 17:43 ?      00:00:00 /opt/firebird/bin/fb_smp_server
firebird 30893  1996  5501  5   12 2136629 3030056 2 21:19 ?      00:00:46 /opt/firebird/bin/fb_smp_server
firebird 30893  1996  5511  4   12 2136629 3030056 4 21:28 ?      00:00:12 /opt/firebird/bin/fb_smp_server
firebird 30893  1996  5633  0   12 2136629 3030056 3 21:33 ?      00:00:00 /opt/firebird/bin/fb_smp_server
- ?

ЗЫ-1. В докладе на точках 00:00:48 и 00:50:20 идёт весьма ценная инфа про Hash lengths (min/avg/max) и Mutex wait%, а именно:
1) если avg больше 10, то пора увеличивать hashslots;
2) если mutex wait показатель около 12%, то следует насторожиться и анализировать причину этого. А если 20% и выше, то это уже плохо.
ИМХО, надо бы сиё в firebird.conf добавить. Равно как и формулу примерного значения LockMemSize = ~ page_cache * max_connects * 100 (время ~00:31:45)

ЗЫ-2. Жаль, что доклада нет в читабельном виде. На слух трудно, буду переслушивать заново. Так что вопросы еще будут, это точно :-)
...
Рейтинг: 0 / 0
17.01.2013, 21:40:18
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38114691
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
0) на LockMemSize
1) блокирующему был доставлен АСТ и с этого момента он считается оповещенным (ждем его реакции)
2.1) до 2.5 в ФБ-руте, после - в темпе
2.2) ЛТ - это расшаренная между процессами память, сиречь MMP (memory-mapped file)
3) объекты для повторного использования, т.к. ЛТ никогда не уменьшается в размере
4) счетчики операций. enq - новый лок, cnv - изменение статуса лока, rej - отказ в локе, blk - факт блокировки кого-либо
5.1) gdb и сорцы тебе в руки
5.2) забей, это поле только для отладки, ибо отражает не текущее, а последнее известное состояние
...
Рейтинг: 0 / 0
18.01.2013, 00:37:01
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38114699
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitr5.1) gdb и сорцы тебе в рукиАааа!!!
Правильно ли я понял, что:
1. Создав примитивную БД с master & detail табличками:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
C:\1INSTALL\FIREBIRD\Data>isql
Use CONNECT or CREATE DATABASE to specify a database
SQL> create database 'tf.fdb'; commit;
SQL> create table tm(id int primary key); commit;
SQL> create table td(id int primary key, pid int references tm on delete cascade); commit;
SQL> insert into tm values(1);
SQL> commit;
SQL> insert into td values(101, 1);
SQL> commit;
SQL> exit;

2. Запустив два isql, в первом из которых удаляю master-запись ( без commit'a), а во втором - пытаясь добавить в detail строку:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
 session #1 
C:\1INSTALL\FIREBIRD\Data>isql localhost/3050:C:\1INSTALL\FIREBIRD\Data\TF.FDB -n
Database:  localhost/3050:C:\1INSTALL\FIREBIRD\Data\TF.FDB
SQL> delete from tm where id=1;

 session #2 
C:\1INSTALL\FIREBIRD\Data>isql localhost/3050:C:\1INSTALL\FIREBIRD\Data\TF.FDB -n
Database:  localhost/3050:C:\1INSTALL\FIREBIRD\Data\TF.FDB
SQL> commit; set transaction read committed record_version no wait;
SQL> insert into td values(102, 1);
Statement failed, SQLSTATE = 40001
lock conflict on no wait transaction
-violation of FOREIGN KEY constraint "INTEG_5" on table "TD"
-Foreign key reference target does not exist

3. Создав снимок лок-таблицы с ключиками -a -m (см аттач)

- я всё равно НЕ получу никакой инфы о номере транзакции / коннекта, который не даёт добавить строку в detail-таблицу ?
...
Рейтинг: 0 / 0
18.01.2013, 00:54:26
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38114712
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Вывод REQUEST BLOCK'ов (<==> ресурсов ) для каждого из двух owner'ов (<==> коннектов ) какой-то сверхъестественный: примерно по 700 строк на каждый коннект.
Что можно было запросить у базы, удаляя одну строку в мастере (и еще одну же в детали), либо делая запрос на добавление строки ?
Не понимаю, как можно разбираться в этом без надлежащего инструмента-парсера :(
 
многабукф!
Код: 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.
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.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
186.
187.
188.
189.
190.
191.
192.
193.
194.
195.
196.
197.
198.
199.
200.
201.
202.
203.
204.
205.
206.
207.
208.
209.
210.
211.
212.
213.
214.
215.
216.
217.
218.
219.
220.
221.
222.
223.
224.
225.
226.
227.
228.
229.
230.
231.
232.
233.
234.
235.
236.
237.
238.
239.
240.
241.
242.
243.
244.
245.
246.
247.
248.
249.
250.
251.
252.
253.
254.
255.
256.
257.
258.
259.
260.
261.
262.
263.
264.
265.
266.
267.
268.
269.
270.
271.
272.
273.
274.
275.
276.
277.
278.
279.
280.
281.
282.
283.
284.
285.
286.
287.
288.
289.
290.
291.
292.
293.
294.
295.
296.
297.
298.
299.
300.
301.
302.
303.
304.
305.
306.
307.
308.
309.
310.
311.
312.
313.
314.
315.
316.
317.
318.
319.
320.
321.
322.
323.
324.
325.
326.
327.
328.
329.
330.
331.
332.
333.
334.
335.
336.
337.
338.
339.
340.
341.
342.
343.
344.
345.
346.
347.
348.
349.
350.
351.
352.
353.
354.
355.
356.
357.
358.
359.
360.
361.
362.
363.
364.
365.
366.
367.
368.
369.
370.
371.
372.
373.
374.
375.
376.
377.
378.
379.
380.
381.
382.
383.
384.
385.
386.
387.
388.
389.
390.
391.
392.
393.
394.
395.
396.
397.
398.
399.
400.
401.
402.
403.
404.
405.
406.
407.
408.
409.
410.
411.
412.
413.
414.
415.
416.
417.
418.
419.
420.
421.
422.
423.
424.
425.
426.
427.
428.
429.
430.
431.
432.
433.
434.
435.
436.
437.
438.
439.
440.
441.
442.
443.
444.
445.
446.
447.
448.
449.
450.
451.
452.
453.
454.
455.
456.
457.
458.
459.
460.
461.
462.
463.
464.
465.
466.
467.
468.
469.
470.
471.
472.
473.
474.
475.
476.
477.
478.
479.
480.
481.
482.
483.
484.
485.
486.
487.
488.
489.
490.
491.
492.
493.
494.
495.
496.
497.
498.
499.
500.
501.
502.
503.
504.
505.
506.
507.
508.
509.
510.
511.
512.
513.
514.
515.
516.
517.
518.
519.
520.
521.
522.
523.
524.
525.
526.
527.
528.
529.
530.
531.
532.
533.
534.
535.
536.
537.
538.
539.
540.
541.
542.
543.
544.
545.
546.
547.
548.
549.
550.
551.
552.
553.
554.
555.
556.
557.
558.
559.
560.
561.
562.
563.
564.
565.
566.
567.
568.
569.
570.
571.
572.
573.
574.
575.
576.
577.
578.
579.
580.
581.
582.
583.
584.
585.
586.
587.
588.
589.
590.
591.
592.
593.
594.
595.
596.
597.
598.
599.
600.
601.
602.
603.
604.
605.
606.
607.
608.
609.
610.
611.
612.
613.
614.
615.
616.
617.
618.
619.
620.
621.
622.
623.
624.
625.
626.
627.
628.
629.
630.
631.
632.
633.
634.
635.
636.
637.
638.
639.
640.
641.
642.
643.
644.
645.
646.
647.
648.
649.
650.
651.
652.
653.
654.
655.
656.
657.
658.
659.
660.
661.
662.
663.
664.
665.
666.
667.
668.
669.
670.
671.
672.
673.
674.
675.
676.
677.
678.
679.
680.
681.
682.
683.
684.
685.
686.
687.
688.
689.
690.
691.
692.
693.
694.
695.
696.
697.
698.
699.
700.
701.
702.
703.
704.
705.
706.
707.
708.
709.
710.
711.
712.
713.
714.
715.
716.
717.
718.
719.
720.
721.
722.
723.
724.
725.
726.
727.
728.
729.
730.
731.
732.
733.
734.
735.
736.
737.
738.
739.
740.
741.
742.
743.
744.
745.
746.
747.
748.
OWNER BLOCK  18744
        Owner id: 2147483648043, type: 1, pending:      0
        Process id:    500 (Alive), thread id:    988
        Flags: 0x00                               
        Requests (106): forward:  18840, backward:  31456
        Blocks: *empty*

REQUEST BLOCK  18840
        Owner:  18744, Lock:  18892, State: 4, Mode: 4, Flags: 0x00
        AST: 0x00447C90, argument: 0x04C4E0E8
        lrq_own_requests:       forward:  18964, backward:  18756
        lrq_lbl_requests:       forward:  34988, backward:  18868
        lrq_own_blocks  : *empty*

REQUEST BLOCK  18964
        Owner:  18744, Lock:  19016, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00445840, argument: 0x06389F18
        lrq_own_requests:       forward:  19072, backward:  18840
        lrq_lbl_requests:       forward:  36040, backward:  18992
        lrq_own_blocks  : *empty*

REQUEST BLOCK  19072
        Owner:  18744, Lock:  19124, State: 2, Mode: 2, Flags: 0x00
        AST: 0x004D7970, argument: 0x04C4E0E8
        lrq_own_requests:       forward:  19188, backward:  18964
        lrq_lbl_requests:       forward:  34260, backward:  19100
        lrq_own_blocks  : *empty*

REQUEST BLOCK  19188
        Owner:  18744, Lock:  19240, State: 2, Mode: 2, Flags: 0x00
        AST: 0x00444750, argument: 0x04C4E4E8
        lrq_own_requests:       forward:  19304, backward:  19072
        lrq_lbl_requests:       forward:  34312, backward:  19216
        lrq_own_blocks  : *empty*

REQUEST BLOCK  19304
        Owner:  18744, Lock:  19356, State: 2, Mode: 2, Flags: 0x00
        AST: 0x004BD590, argument: 0x04C4E0E8
        lrq_own_requests:       forward:  19420, backward:  19188
        lrq_lbl_requests:       forward:  35572, backward:  19332
        lrq_own_blocks  : *empty*

REQUEST BLOCK  19420
        Owner:  18744, Lock:  19472, State: 2, Mode: 2, Flags: 0x00
        AST: 0x0045EDC0, argument: 0x04C5DA20
        lrq_own_requests:       forward:  19536, backward:  19304
        lrq_lbl_requests:       forward:  35300, backward:  19448
        lrq_own_blocks  : *empty*

REQUEST BLOCK  19536
        Owner:  18744, Lock:  19588, State: 2, Mode: 2, Flags: 0x00
        AST: 0x0045EDC0, argument: 0x04C5E4B4
        lrq_own_requests:       forward:  19652, backward:  19420
        lrq_lbl_requests:       forward:  34884, backward:  19564
        lrq_own_blocks  : *empty*

REQUEST BLOCK  19652
        Owner:  18744, Lock:  19704, State: 6, Mode: 6, Flags: 0x00
        AST: 0x00490670, argument: 0x04C47A24
        lrq_own_requests:       forward:  19768, backward:  19536
        lrq_lbl_requests:       forward:  19680, backward:  19680
        lrq_own_blocks  : *empty*

REQUEST BLOCK  19768
        Owner:  18744, Lock:  19876, State: 6, Mode: 6, Flags: 0x00
        AST: 0x00000000, argument: 0x06379338
        lrq_own_requests:       forward:  19940, backward:  19652
        lrq_lbl_requests:       forward:  19852, backward:  19852
        lrq_own_blocks  : *empty*

REQUEST BLOCK  19940
        Owner:  18744, Lock:  19992, State: 2, Mode: 2, Flags: 0x00
        AST: 0x0045EDC0, argument: 0x04C458D4
        lrq_own_requests:       forward:  20056, backward:  19768
        lrq_lbl_requests:       forward:  33248, backward:  19968
        lrq_own_blocks  : *empty*

REQUEST BLOCK  20056
        Owner:  18744, Lock:  20108, State: 2, Mode: 2, Flags: 0x00
        AST: 0x0045EDC0, argument: 0x04C45D58
        lrq_own_requests:       forward:  20172, backward:  19940
        lrq_lbl_requests:       forward:  33144, backward:  20084
        lrq_own_blocks  : *empty*

REQUEST BLOCK  20172
        Owner:  18744, Lock:  20224, State: 2, Mode: 2, Flags: 0x00
        AST: 0x0045EDC0, argument: 0x04C4184C
        lrq_own_requests:       forward:  20288, backward:  20056
        lrq_lbl_requests:       forward:  33092, backward:  20200
        lrq_own_blocks  : *empty*

REQUEST BLOCK  20288
        Owner:  18744, Lock:  20340, State: 2, Mode: 2, Flags: 0x00
        AST: 0x00481330, argument: 0x06379338
        lrq_own_requests:       forward:  20404, backward:  20172
        lrq_lbl_requests:       forward:  20316, backward:  20316
        lrq_own_blocks  : *empty*

REQUEST BLOCK  20404
        Owner:  18744, Lock:  20456, State: 2, Mode: 2, Flags: 0x00
        AST: 0x0045EDC0, argument: 0x04C44FAC
        lrq_own_requests:       forward:  20520, backward:  20288
        lrq_lbl_requests:       forward:  32208, backward:  20432
        lrq_own_blocks  : *empty*

REQUEST BLOCK  20520
        Owner:  18744, Lock:  20572, State: 2, Mode: 2, Flags: 0x00
        AST: 0x0045EB80, argument: 0x04C49CAC
        lrq_own_requests:       forward:  20636, backward:  20404
        lrq_lbl_requests:       forward:  20548, backward:  20548
        lrq_own_blocks  : *empty*

REQUEST BLOCK  20636
        Owner:  18744, Lock:  20688, State: 2, Mode: 2, Flags: 0x00
        AST: 0x0045EDC0, argument: 0x04C56714
        lrq_own_requests:       forward:  20752, backward:  20520
        lrq_lbl_requests:       forward:  20664, backward:  20664
        lrq_own_blocks  : *empty*

REQUEST BLOCK  20752
        Owner:  18744, Lock:  20804, State: 2, Mode: 2, Flags: 0x00
        AST: 0x00000000, argument: 0x00000000
        lrq_own_requests:       forward:  20868, backward:  20636
        lrq_lbl_requests:       forward:  20780, backward:  20780
        lrq_own_blocks  : *empty*

REQUEST BLOCK  20868
        Owner:  18744, Lock:  20920, State: 2, Mode: 2, Flags: 0x00
        AST: 0x0045EDC0, argument: 0x0637D488
        lrq_own_requests:       forward:  20984, backward:  20752
        lrq_lbl_requests:       forward:  31624, backward:  20896
        lrq_own_blocks  : *empty*

REQUEST BLOCK  20984
        Owner:  18744, Lock:  21036, State: 2, Mode: 2, Flags: 0x00
        AST: 0x00000000, argument: 0x00000000
        lrq_own_requests:       forward:  21100, backward:  20868
        lrq_lbl_requests:       forward:  21012, backward:  21012
        lrq_own_blocks  : *empty*

REQUEST BLOCK  21100
        Owner:  18744, Lock:  21152, State: 4, Mode: 4, Flags: 0x00
        AST: 0x00456CF0, argument: 0x0637B004
        lrq_own_requests:       forward:  21216, backward:  20984
        lrq_lbl_requests:       forward:  21128, backward:  21128
        lrq_own_blocks  : *empty*

REQUEST BLOCK  21216
        Owner:  18744, Lock:  21268, State: 4, Mode: 4, Flags: 0x00
        AST: 0x00456CF0, argument: 0x0637B214
        lrq_own_requests:       forward:  21332, backward:  21100
        lrq_lbl_requests:       forward:  35456, backward:  21244
        lrq_own_blocks  : *empty*

REQUEST BLOCK  21332
        Owner:  18744, Lock:  21384, State: 2, Mode: 2, Flags: 0x00
        AST: 0x0045EF00, argument: 0x0637D488
        lrq_own_requests:       forward:  21448, backward:  21216
        lrq_lbl_requests:       forward:  36648, backward:  21360
        lrq_own_blocks  : *empty*

REQUEST BLOCK  21448
        Owner:  18744, Lock:  21500, State: 2, Mode: 2, Flags: 0x00
        AST: 0x0045EF00, argument: 0x04C56714
        lrq_own_requests:       forward:  21712, backward:  21332
        lrq_lbl_requests:       forward:  21476, backward:  21476
        lrq_own_blocks  : *empty*

REQUEST BLOCK  21712
        Owner:  18744, Lock:  21764, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638F58C
        lrq_own_requests:       forward:  21828, backward:  21448
        lrq_lbl_requests:       forward:  33352, backward:  21740
        lrq_own_blocks  : *empty*

REQUEST BLOCK  21828
        Owner:  18744, Lock:  21880, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638F4A4
        lrq_own_requests:       forward:  21944, backward:  21712
        lrq_lbl_requests:       forward:  33508, backward:  21856
        lrq_own_blocks  : *empty*

REQUEST BLOCK  21944
        Owner:  18744, Lock:  21996, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638F3BC
        lrq_own_requests:       forward:  22060, backward:  21828
        lrq_lbl_requests:       forward:  33404, backward:  21972
        lrq_own_blocks  : *empty*

REQUEST BLOCK  22060
        Owner:  18744, Lock:  22112, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638F2D4
        lrq_own_requests:       forward:  22292, backward:  21944
        lrq_lbl_requests:       forward:  33456, backward:  22088
        lrq_own_blocks  : *empty*

REQUEST BLOCK  22292
        Owner:  18744, Lock:  22344, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638F104
        lrq_own_requests:       forward:  22408, backward:  22060
        lrq_lbl_requests:       forward:  36752, backward:  22320
        lrq_own_blocks  : *empty*

REQUEST BLOCK  22408
        Owner:  18744, Lock:  22460, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638F01C
        lrq_own_requests:       forward:  22524, backward:  22292
        lrq_lbl_requests:       forward:  33976, backward:  22436
        lrq_own_blocks  : *empty*

REQUEST BLOCK  22524
        Owner:  18744, Lock:  22576, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638EF34
        lrq_own_requests:       forward:  22640, backward:  22408
        lrq_lbl_requests:       forward:  34144, backward:  22552
        lrq_own_blocks  : *empty*

REQUEST BLOCK  22640
        Owner:  18744, Lock:  22692, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638EE4C
        lrq_own_requests:       forward:  22756, backward:  22524
        lrq_lbl_requests:       forward:  22176, backward:  22668
        lrq_own_blocks  : *empty*

REQUEST BLOCK  22756
        Owner:  18744, Lock:  22808, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638ED64
        lrq_own_requests:       forward:  22988, backward:  22640
        lrq_lbl_requests:       forward:  21660, backward:  22784
        lrq_own_blocks  : *empty*

REQUEST BLOCK  22988
        Owner:  18744, Lock:  23040, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638EB94
        lrq_own_requests:       forward:  23104, backward:  22756
        lrq_lbl_requests:       forward:  36144, backward:  23016
        lrq_own_blocks  : *empty*

REQUEST BLOCK  23104
        Owner:  18744, Lock:  23156, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638EAAC
        lrq_own_requests:       forward:  23220, backward:  22988
        lrq_lbl_requests:       forward:  33716, backward:  23132
        lrq_own_blocks  : *empty*

REQUEST BLOCK  23220
        Owner:  18744, Lock:  23272, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638E9C4
        lrq_own_requests:       forward:  23336, backward:  23104
        lrq_lbl_requests:       forward:  23248, backward:  23248
        lrq_own_blocks  : *empty*

REQUEST BLOCK  23336
        Owner:  18744, Lock:  23388, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638E8DC
        lrq_own_requests:       forward:  23452, backward:  23220
        lrq_lbl_requests:       forward:  23364, backward:  23364
        lrq_own_blocks  : *empty*

REQUEST BLOCK  23452
        Owner:  18744, Lock:  23504, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638E7F4
        lrq_own_requests:       forward:  23568, backward:  23336
        lrq_lbl_requests:       forward:  36856, backward:  23480
        lrq_own_blocks  : *empty*

REQUEST BLOCK  23568
        Owner:  18744, Lock:  23620, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638E70C
        lrq_own_requests:       forward:  23684, backward:  23452
        lrq_lbl_requests:       forward:  36804, backward:  23596
        lrq_own_blocks  : *empty*

REQUEST BLOCK  23684
        Owner:  18744, Lock:  23736, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638E624
        lrq_own_requests:       forward:  23800, backward:  23568
        lrq_lbl_requests:       forward:  36700, backward:  23712
        lrq_own_blocks  : *empty*

REQUEST BLOCK  23800
        Owner:  18744, Lock:  23852, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638E53C
        lrq_own_requests:       forward:  23916, backward:  23684
        lrq_lbl_requests:       forward:  31844, backward:  23828
        lrq_own_blocks  : *empty*

REQUEST BLOCK  23916
        Owner:  18744, Lock:  23968, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638E454
        lrq_own_requests:       forward:  24032, backward:  23800
        lrq_lbl_requests:       forward:  31740, backward:  23944
        lrq_own_blocks  : *empty*

REQUEST BLOCK  24032
        Owner:  18744, Lock:  24084, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638E36C
        lrq_own_requests:       forward:  24148, backward:  23916
        lrq_lbl_requests:       forward:  32000, backward:  24060
        lrq_own_blocks  : *empty*

REQUEST BLOCK  24148
        Owner:  18744, Lock:  24200, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638E284
        lrq_own_requests:       forward:  24264, backward:  24032
        lrq_lbl_requests:       forward:  31572, backward:  24176
        lrq_own_blocks  : *empty*

REQUEST BLOCK  24264
        Owner:  18744, Lock:  24316, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638E19C
        lrq_own_requests:       forward:  24380, backward:  24148
        lrq_lbl_requests:       forward:  24292, backward:  24292
        lrq_own_blocks  : *empty*

REQUEST BLOCK  24380
        Owner:  18744, Lock:  24432, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638E0B4
        lrq_own_requests:       forward:  24496, backward:  24264
        lrq_lbl_requests:       forward:  24408, backward:  24408
        lrq_own_blocks  : *empty*

REQUEST BLOCK  24496
        Owner:  18744, Lock:  24548, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638DF78
        lrq_own_requests:       forward:  24612, backward:  24380
        lrq_lbl_requests:       forward:  24524, backward:  24524
        lrq_own_blocks  : *empty*

REQUEST BLOCK  24612
        Owner:  18744, Lock:  24664, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638DE90
        lrq_own_requests:       forward:  24728, backward:  24496
        lrq_lbl_requests:       forward:  24640, backward:  24640
        lrq_own_blocks  : *empty*

REQUEST BLOCK  24728
        Owner:  18744, Lock:  24780, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638DDA8
        lrq_own_requests:       forward:  24844, backward:  24612
        lrq_lbl_requests:       forward:  24756, backward:  24756
        lrq_own_blocks  : *empty*

REQUEST BLOCK  24844
        Owner:  18744, Lock:  24896, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638DCC0
        lrq_own_requests:       forward:  24960, backward:  24728
        lrq_lbl_requests:       forward:  31896, backward:  24872
        lrq_own_blocks  : *empty*

REQUEST BLOCK  24960
        Owner:  18744, Lock:  25012, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638DBD8
        lrq_own_requests:       forward:  25076, backward:  24844
        lrq_lbl_requests:       forward:  31948, backward:  24988
        lrq_own_blocks  : *empty*

REQUEST BLOCK  25076
        Owner:  18744, Lock:  25128, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638DAF0
        lrq_own_requests:       forward:  25192, backward:  24960
        lrq_lbl_requests:       forward:  32052, backward:  25104
        lrq_own_blocks  : *empty*

REQUEST BLOCK  25192
        Owner:  18744, Lock:  25244, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638DA08
        lrq_own_requests:       forward:  25308, backward:  25076
        lrq_lbl_requests:       forward:  32104, backward:  25220
        lrq_own_blocks  : *empty*

REQUEST BLOCK  25308
        Owner:  18744, Lock:  25360, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638D920
        lrq_own_requests:       forward:  25424, backward:  25192
        lrq_lbl_requests:       forward:  32156, backward:  25336
        lrq_own_blocks  : *empty*

REQUEST BLOCK  25424
        Owner:  18744, Lock:  25476, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638D838
        lrq_own_requests:       forward:  25540, backward:  25308
        lrq_lbl_requests:       forward:  32260, backward:  25452
        lrq_own_blocks  : *empty*

REQUEST BLOCK  25540
        Owner:  18744, Lock:  25592, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638D750
        lrq_own_requests:       forward:  25656, backward:  25424
        lrq_lbl_requests:       forward:  32312, backward:  25568
        lrq_own_blocks  : *empty*

REQUEST BLOCK  25656
        Owner:  18744, Lock:  25708, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638D668
        lrq_own_requests:       forward:  25772, backward:  25540
        lrq_lbl_requests:       forward:  32416, backward:  25684
        lrq_own_blocks  : *empty*

REQUEST BLOCK  25772
        Owner:  18744, Lock:  25824, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638D580
        lrq_own_requests:       forward:  25888, backward:  25656
        lrq_lbl_requests:       forward:  32468, backward:  25800
        lrq_own_blocks  : *empty*

REQUEST BLOCK  25888
        Owner:  18744, Lock:  25940, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638D498
        lrq_own_requests:       forward:  26004, backward:  25772
        lrq_lbl_requests:       forward:  32520, backward:  25916
        lrq_own_blocks  : *empty*

REQUEST BLOCK  26004
        Owner:  18744, Lock:  26056, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638D3B0
        lrq_own_requests:       forward:  26120, backward:  25888
        lrq_lbl_requests:       forward:  32572, backward:  26032
        lrq_own_blocks  : *empty*

REQUEST BLOCK  26120
        Owner:  18744, Lock:  26172, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638D2C8
        lrq_own_requests:       forward:  26236, backward:  26004
        lrq_lbl_requests:       forward:  32624, backward:  26148
        lrq_own_blocks  : *empty*

REQUEST BLOCK  26236
        Owner:  18744, Lock:  26288, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638D1E0
        lrq_own_requests:       forward:  26352, backward:  26120
        lrq_lbl_requests:       forward:  32676, backward:  26264
        lrq_own_blocks  : *empty*

REQUEST BLOCK  26352
        Owner:  18744, Lock:  26404, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638D0F8
        lrq_own_requests:       forward:  26468, backward:  26236
        lrq_lbl_requests:       forward:  32728, backward:  26380
        lrq_own_blocks  : *empty*

REQUEST BLOCK  26468
        Owner:  18744, Lock:  26520, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638D010
        lrq_own_requests:       forward:  26584, backward:  26352
        lrq_lbl_requests:       forward:  32780, backward:  26496
        lrq_own_blocks  : *empty*

REQUEST BLOCK  26584
        Owner:  18744, Lock:  26636, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638CF28
        lrq_own_requests:       forward:  26700, backward:  26468
        lrq_lbl_requests:       forward:  32832, backward:  26612
        lrq_own_blocks  : *empty*

REQUEST BLOCK  26700
        Owner:  18744, Lock:  26752, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638CE40
        lrq_own_requests:       forward:  26816, backward:  26584
        lrq_lbl_requests:       forward:  32936, backward:  26728
        lrq_own_blocks  : *empty*

REQUEST BLOCK  26816
        Owner:  18744, Lock:  26868, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638CD58
        lrq_own_requests:       forward:  26932, backward:  26700
        lrq_lbl_requests:       forward:  32988, backward:  26844
        lrq_own_blocks  : *empty*

REQUEST BLOCK  26932
        Owner:  18744, Lock:  26984, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638CC70
        lrq_own_requests:       forward:  27048, backward:  26816
        lrq_lbl_requests:       forward:  33040, backward:  26960
        lrq_own_blocks  : *empty*

REQUEST BLOCK  27048
        Owner:  18744, Lock:  27100, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638CB88
        lrq_own_requests:       forward:  27164, backward:  26932
        lrq_lbl_requests:       forward:  33768, backward:  27076
        lrq_own_blocks  : *empty*

REQUEST BLOCK  27164
        Owner:  18744, Lock:  27216, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638CAA0
        lrq_own_requests:       forward:  27280, backward:  27048
        lrq_lbl_requests:       forward:  33820, backward:  27192
        lrq_own_blocks  : *empty*

REQUEST BLOCK  27280
        Owner:  18744, Lock:  27332, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638C9B8
        lrq_own_requests:       forward:  27396, backward:  27164
        lrq_lbl_requests:       forward:  33872, backward:  27308
        lrq_own_blocks  : *empty*

REQUEST BLOCK  27396
        Owner:  18744, Lock:  27448, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638C8D0
        lrq_own_requests:       forward:  27512, backward:  27280
        lrq_lbl_requests:       forward:  33924, backward:  27424
        lrq_own_blocks  : *empty*

REQUEST BLOCK  27512
        Owner:  18744, Lock:  27564, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638C7E8
        lrq_own_requests:       forward:  27628, backward:  27396
        lrq_lbl_requests:       forward:  34364, backward:  27540
        lrq_own_blocks  : *empty*

REQUEST BLOCK  27628
        Owner:  18744, Lock:  27680, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638C700
        lrq_own_requests:       forward:  27744, backward:  27512
        lrq_lbl_requests:       forward:  34416, backward:  27656
        lrq_own_blocks  : *empty*

REQUEST BLOCK  27744
        Owner:  18744, Lock:  27796, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638C618
        lrq_own_requests:       forward:  27860, backward:  27628
        lrq_lbl_requests:       forward:  34468, backward:  27772
        lrq_own_blocks  : *empty*

REQUEST BLOCK  27860
        Owner:  18744, Lock:  27912, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638C530
        lrq_own_requests:       forward:  27976, backward:  27744
        lrq_lbl_requests:       forward:  34520, backward:  27888
        lrq_own_blocks  : *empty*

REQUEST BLOCK  27976
        Owner:  18744, Lock:  28028, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638C448
        lrq_own_requests:       forward:  28092, backward:  27860
        lrq_lbl_requests:       forward:  34572, backward:  28004
        lrq_own_blocks  : *empty*

REQUEST BLOCK  28092
        Owner:  18744, Lock:  28144, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638C360
        lrq_own_requests:       forward:  28208, backward:  27976
        lrq_lbl_requests:       forward:  34624, backward:  28120
        lrq_own_blocks  : *empty*

REQUEST BLOCK  28208
        Owner:  18744, Lock:  28260, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638C278
        lrq_own_requests:       forward:  28324, backward:  28092
        lrq_lbl_requests:       forward:  34676, backward:  28236
        lrq_own_blocks  : *empty*

REQUEST BLOCK  28324
        Owner:  18744, Lock:  28376, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638C190
        lrq_own_requests:       forward:  28440, backward:  28208
        lrq_lbl_requests:       forward:  34728, backward:  28352
        lrq_own_blocks  : *empty*

REQUEST BLOCK  28440
        Owner:  18744, Lock:  28492, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638C0A8
        lrq_own_requests:       forward:  28556, backward:  28324
        lrq_lbl_requests:       forward:  34780, backward:  28468
        lrq_own_blocks  : *empty*

REQUEST BLOCK  28556
        Owner:  18744, Lock:  28608, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638BF6C
        lrq_own_requests:       forward:  28672, backward:  28440
        lrq_lbl_requests:       forward:  34832, backward:  28584
        lrq_own_blocks  : *empty*

REQUEST BLOCK  28672
        Owner:  18744, Lock:  28724, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638BE84
        lrq_own_requests:       forward:  28788, backward:  28556
        lrq_lbl_requests:       forward:  34936, backward:  28700
        lrq_own_blocks  : *empty*

REQUEST BLOCK  28788
        Owner:  18744, Lock:  28840, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638BD9C
        lrq_own_requests:       forward:  28904, backward:  28672
        lrq_lbl_requests:       forward:  35040, backward:  28816
        lrq_own_blocks  : *empty*

REQUEST BLOCK  28904
        Owner:  18744, Lock:  28956, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638BCB4
        lrq_own_requests:       forward:  29020, backward:  28788
        lrq_lbl_requests:       forward:  35092, backward:  28932
        lrq_own_blocks  : *empty*

REQUEST BLOCK  29020
        Owner:  18744, Lock:  29072, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638BBCC
        lrq_own_requests:       forward:  29136, backward:  28904
        lrq_lbl_requests:       forward:  35196, backward:  29048
        lrq_own_blocks  : *empty*

REQUEST BLOCK  29136
        Owner:  18744, Lock:  29188, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638BAE4
        lrq_own_requests:       forward:  29252, backward:  29020
        lrq_lbl_requests:       forward:  35248, backward:  29164
        lrq_own_blocks  : *empty*

REQUEST BLOCK  29252
        Owner:  18744, Lock:  29304, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638B9FC
        lrq_own_requests:       forward:  29368, backward:  29136
        lrq_lbl_requests:       forward:  35352, backward:  29280
        lrq_own_blocks  : *empty*

REQUEST BLOCK  29368
        Owner:  18744, Lock:  29420, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638B914
        lrq_own_requests:       forward:  29484, backward:  29252
        lrq_lbl_requests:       forward:  35404, backward:  29396
        lrq_own_blocks  : *empty*

REQUEST BLOCK  29484
        Owner:  18744, Lock:  29536, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638B82C
        lrq_own_requests:       forward:  29600, backward:  29368
        lrq_lbl_requests:       forward:  35624, backward:  29512
        lrq_own_blocks  : *empty*

REQUEST BLOCK  29600
        Owner:  18744, Lock:  29652, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638B744
        lrq_own_requests:       forward:  29716, backward:  29484
        lrq_lbl_requests:       forward:  35676, backward:  29628
        lrq_own_blocks  : *empty*

REQUEST BLOCK  29716
        Owner:  18744, Lock:  29768, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638B65C
        lrq_own_requests:       forward:  29832, backward:  29600
        lrq_lbl_requests:       forward:  35728, backward:  29744
        lrq_own_blocks  : *empty*

REQUEST BLOCK  29832
        Owner:  18744, Lock:  29884, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638B574
        lrq_own_requests:       forward:  29948, backward:  29716
        lrq_lbl_requests:       forward:  35780, backward:  29860
        lrq_own_blocks  : *empty*

REQUEST BLOCK  29948
        Owner:  18744, Lock:  30000, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638B48C
        lrq_own_requests:       forward:  30064, backward:  29832
        lrq_lbl_requests:       forward:  35832, backward:  29976
        lrq_own_blocks  : *empty*

REQUEST BLOCK  30064
        Owner:  18744, Lock:  30116, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638B3A4
        lrq_own_requests:       forward:  30180, backward:  29948
        lrq_lbl_requests:       forward:  35884, backward:  30092
        lrq_own_blocks  : *empty*

REQUEST BLOCK  30180
        Owner:  18744, Lock:  30232, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638B2BC
        lrq_own_requests:       forward:  30296, backward:  30064
        lrq_lbl_requests:       forward:  35936, backward:  30208
        lrq_own_blocks  : *empty*

REQUEST BLOCK  30296
        Owner:  18744, Lock:  30348, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638B1D4
        lrq_own_requests:       forward:  30412, backward:  30180
        lrq_lbl_requests:       forward:  35988, backward:  30324
        lrq_own_blocks  : *empty*

REQUEST BLOCK  30412
        Owner:  18744, Lock:  30464, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638B0EC
        lrq_own_requests:       forward:  30528, backward:  30296
        lrq_lbl_requests:       forward:  22872, backward:  30440
        lrq_own_blocks  : *empty*

REQUEST BLOCK  30528
        Owner:  18744, Lock:  30580, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638B004
        lrq_own_requests:       forward:  30644, backward:  30412
        lrq_lbl_requests:       forward:  36196, backward:  30556
        lrq_own_blocks  : *empty*

REQUEST BLOCK  30644
        Owner:  18744, Lock:  30696, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638AF1C
        lrq_own_requests:       forward:  30760, backward:  30528
        lrq_lbl_requests:       forward:  36312, backward:  30672
        lrq_own_blocks  : *empty*

REQUEST BLOCK  30760
        Owner:  18744, Lock:  30812, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638AE34
        lrq_own_requests:       forward:  30876, backward:  30644
        lrq_lbl_requests:       forward:  36364, backward:  30788
        lrq_own_blocks  : *empty*

REQUEST BLOCK  30876
        Owner:  18744, Lock:  30928, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638AD4C
        lrq_own_requests:       forward:  30992, backward:  30760
        lrq_lbl_requests:       forward:  36416, backward:  30904
        lrq_own_blocks  : *empty*

REQUEST BLOCK  30992
        Owner:  18744, Lock:  31044, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638AC64
        lrq_own_requests:       forward:  31108, backward:  30876
        lrq_lbl_requests:       forward:  36532, backward:  31020
        lrq_own_blocks  : *empty*

REQUEST BLOCK  31108
        Owner:  18744, Lock:  31160, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638AA94
        lrq_own_requests:       forward:  31224, backward:  30992
        lrq_lbl_requests:       forward:  32884, backward:  31136
        lrq_own_blocks  : *empty*

REQUEST BLOCK  31224
        Owner:  18744, Lock:  31276, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638A9AC
        lrq_own_requests:       forward:  31340, backward:  31108
        lrq_lbl_requests:       forward:  33196, backward:  31252
        lrq_own_blocks  : *empty*

REQUEST BLOCK  31340
        Owner:  18744, Lock:  31392, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638A8C4
        lrq_own_requests:       forward:  31456, backward:  31224
        lrq_lbl_requests:       forward:  35144, backward:  31368
        lrq_own_blocks  : *empty*

REQUEST BLOCK  31456
        Owner:  18744, Lock:  31508, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00449E20, argument: 0x0638A7DC
        lrq_own_requests:       forward:  18756, backward:  31340
        lrq_lbl_requests:       forward:  34028, backward:  31484
        lrq_own_blocks  : *empty*
Да, и еще.
Тут какие-то lrq_own _requests и lrq_lbl _requests появились - о них в докладе я тоже не засёк ничего.
...
Рейтинг: 0 / 0
18.01.2013, 01:10:01
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38114713
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitr5.1) gdb и сорцы тебе в рукиа это... что делать тем, кто под виндузой сидит, у них же gdb нету ? (да и знать бы еще, куда там в логе gdb смотреть... )
...
Рейтинг: 0 / 0
18.01.2013, 01:12:56
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38114719
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitr2.2) ЛТ - это расшаренная между процессами память, сиречь MMP (memory-mapped file)А зачем это же распространять на SuperClassic, в котором процесс - один ? (потоки - они могут видеть шаред-область без "материализации" её в виде файла или нет ?)
...
Рейтинг: 0 / 0
18.01.2013, 01:25:29
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38114816
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидА зачем это же распространять на SuperClassic, в котором процесс - один ?
кто тебе такое сказал? Твои embedded-коннекты от isql/gfix/gbak/etc святым духом с базой работают, ага.
...
Рейтинг: 0 / 0
18.01.2013, 08:36:00
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38114817
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидя всё равно НЕ получу никакой инфы о номере транзакции / коннекта, который не даёт добавить строку в detail-таблицу?
для NOWAIT транзакции есс-но не получишь, ибо не сможешь в ЛТ найти ожидающий коннект. Для WAIT - номер коннекта найдешь при желании.
...
Рейтинг: 0 / 0
18.01.2013, 08:39:20
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38114820
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидВывод REQUEST BLOCK'ов (<==> ресурсов ) для каждого из двух owner'ов (<==> коннектов ) какой-то сверхъестественный: примерно по 700 строк на каждый коннект.
Что можно было запросить у базы, удаляя одну строку в мастере (и еще одну же в детали), либо делая запрос на добавление строки ?
на каждую занятую страницу кеша - по одному риквесту, плюс локи на метаданные
...
Рейтинг: 0 / 0
18.01.2013, 08:43:03
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38114822
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидчто делать тем, кто под виндузой сидит, у них же gdb нету?
у них есть Visual Studio ;-)
...
Рейтинг: 0 / 0
18.01.2013, 08:46:05
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38114842
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
ТаблоидНе понимаю, как можно разбираться в этом без надлежащего инструмента-парсераПытаюсь разобраться в "минимально возможных дебрях". Будет много букаф, извиняйте.

Создана пустая база и единственный коннект к ней:
Код: plaintext
1.
2.
3.
C:\1INSTALL\FIREBIRD\Data>isql localhost:C:\1INSTALL\FIREBIRD\Data\tt.FDB -n
Database:  localhost:C:\1INSTALL\FIREBIRD\Data\tt.FDB
SQL>
Снимаю в этот момент лок-таблицу, получаю файлик в 176 строк (7486 байт).
Единственный коннект (owner id=18744) запросил при этом 9 ресурсов:
 
Код: 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.
REQUEST BLOCK  18840
        Owner:  18744, Lock:   18892 , State: 6, Mode: 6, Flags: 0x00
        AST: 0x00447C90, argument: 0x0A10E0E8
        lrq_own_requests:       forward:  18964, backward:  18756
        lrq_lbl_requests:       forward:  18868, backward:  18868
        lrq_own_blocks  : *empty*

REQUEST BLOCK  18964
        Owner:  18744, Lock:  19016, State: 3, Mode: 3, Flags: 0x00
        AST: 0x00445840, argument: 0x09419F18
        lrq_own_requests:       forward:  19072, backward:  18840
        lrq_lbl_requests:       forward:  18992, backward:  18992
        lrq_own_blocks  : *empty*

REQUEST BLOCK  19072
        Owner:  18744, Lock:  19124, State: 2, Mode: 2, Flags: 0x00
        AST: 0x004D7970, argument: 0x0A10E0E8
        lrq_own_requests:       forward:  19188, backward:  18964
        lrq_lbl_requests:       forward:  19100, backward:  19100
        lrq_own_blocks  : *empty*

REQUEST BLOCK  19188
        Owner:  18744, Lock:  19240, State: 5, Mode: 5, Flags: 0x00
        AST: 0x00444750, argument: 0x0A10E4E8
        lrq_own_requests:       forward:  19304, backward:  19072
        lrq_lbl_requests:       forward:  19216, backward:  19216
        lrq_own_blocks  : *empty*

REQUEST BLOCK  19304
        Owner:  18744, Lock:  19356, State: 2, Mode: 2, Flags: 0x00
        AST: 0x004BD590, argument: 0x0A10E0E8
        lrq_own_requests:       forward:  19420, backward:  19188
        lrq_lbl_requests:       forward:  19332, backward:  19332
        lrq_own_blocks  : *empty*

REQUEST BLOCK  19420
        Owner:  18744, Lock:  19472, State: 2, Mode: 2, Flags: 0x00
        AST: 0x0045EDC0, argument: 0x0A11DA20
        lrq_own_requests:       forward:  19536, backward:  19304
        lrq_lbl_requests:       forward:  19448, backward:  19448
        lrq_own_blocks  : *empty*

REQUEST BLOCK  19536
        Owner:  18744, Lock:  19588, State: 2, Mode: 2, Flags: 0x00
        AST: 0x0045EDC0, argument: 0x0A11E4B4
        lrq_own_requests:       forward:  19652, backward:  19420
        lrq_lbl_requests:       forward:  19564, backward:  19564
        lrq_own_blocks  : *empty*

REQUEST BLOCK  19652
        Owner:  18744, Lock:   19704 , State: 6, Mode: 6, Flags: 0x00
        AST: 0x00490670, argument: 0x0A107A24
        lrq_own_requests:       forward:  19768, backward:  19536
        lrq_lbl_requests:       forward:  19680, backward:  19680
        lrq_own_blocks  : *empty*

REQUEST BLOCK  19768
        Owner:  18744, Lock:   19876 , State: 6, Mode: 6, Flags: 0x00
        AST: 0x00000000, argument: 0x093F9884
        lrq_own_requests:       forward:  18756, backward:  19652
        lrq_lbl_requests:       forward:  19852, backward:  19852
        lrq_own_blocks  : *empty*
=====================
На три "объекта" были запрошены и получены exclusive -блокировки (оба "поля": state & mode - равны 6). Эти три request-блока имеют в полях Lock id'шники = 18892, 19704 & 19876 .

Идём в секцию полученных локов (lock block's, ниже request'ов).

Блок 18892 (последний в выводе) имеет вид:
Код: plaintext
1.
2.
3.
4.
5.
6.
LOCK BLOCK   18892
          Series: 1 , Parent:      0, State: 6, size: 16 length: 12 data: 0
        Key: 5<34><234><164><0><0><24><0><229><244><0><0>, Flags: 0x00, Pending request count:      0
        Hash que (1):   forward:   5548, backward:   5548
        Requests (1):   forward:  18840, backward:  18840
                Request  18840, Owner:  18744, State: 6 (6), Flags: 0x00
Согласно Большой Книги, это блокировка всей базы, выполненная первым коннектом. Она будет понижена при подключении второго и последующих коннектов:
Helen Borrie, page 868SymbolSeriesDescriptionLCK_database.1database lock is taken by eachprocess that attaches a database. The first process takes an exclusive lock. The next process notices a conflict and signals the first to downgrade its lock from exclusive to shared

Блок 19704 имеет вид:
Код: plaintext
1.
2.
3.
4.
5.
LOCK BLOCK  19704
         Series: 7 , Parent:   18892 , State: 6, size: 8 length: 4 data: 0
        Key: 000002, Flags: 0x00, Pending request count:      0
        Hash que (2):   forward:    364, backward:  19240
        Requests (1):   forward:  19652, backward:  19652
                Request  19652, Owner:  18744, State: 6 (6), Flags: 0x00
В книге сказано, что серия (= вид объекта, который блокируется) номер 7 ... не используется!
Helen Borrie, page 868SymbolSeriesDescriptionLCK_attachment7Not used. Attachment lock to support dBase record locks, which can exist across transaction boundaries.
Блок 19876 имеет вид:
Код: plaintext
1.
2.
3.
4.
5.
LOCK BLOCK  19876
         Series: 4 , Parent:   18892 , State: 6, size: 8 length: 4 data: 4
        Key: 000004, Flags: 0x00, Pending request count:      0
        Hash que (1):   forward:    380, backward:    380
        Requests (1):   forward:  19768, backward:  19768
                Request  19768, Owner:  18744, State: 6 (6), Flags: 0x00
Для серии номер 4 в Книге говорится, что это:Helen Borrie, page 868SymbolSeriesDescriptionLCK_tra4Individual transaction lock. Each action takes an exclusive lock on its own transaction ID when it starts. Other owners can acquire null locks on it to read its state.
===============

Еще один lock bloсk, id = 19240, имеет state = 5 ( protected write: "is used for constsency mode (table stability)"):
Код: plaintext
1.
2.
3.
4.
5.
LOCK BLOCK  19240
         Series: 24 , Parent:  18892, State: 5, size: 8 length: 4 data: 33
        Key: 000002, Flags: 0x00, Pending request count:      0
        Hash que (2):   forward:  19704, backward:    364
        Requests (1):   forward:  19188, backward:  19188
                Request  19188, Owner:  18744, State: 5 (5), Flags: 0x00

Но что это за объект - непонятно. В Большой Книге типы объектов ("серии") заканчиваются номером 17 (LCK_update_shadow).

================

Блок с id = 19016 имеет state = 3 ( protected read: все могут читать этот блок, но никто не может в него записывать - правильно ?).
Код: plaintext
1.
2.
3.
4.
5.
LOCK BLOCK  19016
         Series: 15 , Parent:  18892, State: 3, size: 0 length: 0 data: 0
        Key: , Flags: 0x00, Pending request count:      0
        Hash que (3):   forward:  19124, backward:    348
        Requests (1):   forward:  18964, backward:  18964
                Request  18964, Owner:  18744, State: 3 (3), Flags: 0x00
По книге его серия (15) означает:Helen Borrie, page 868SymbolSeriesDescriptionLCK_prc_exist15Procedure existence lock. Prevents procedures and triggers from being dropped while any owner has a prepared request that uses (or depends on) that resource. Это тоже непонятно. Нет ни одной ХП, никаких триггеров (таблиц нету!). Чего блокировать ?

================

Остальные блоки имеют статус = 2 ( shared read):
Код: plaintext
1.
LOCK BLOCK  19124
         Series: 8 , Parent:  18892, State: 2, size: 8 length: 4 data: 0
SymbolSeriesDescriptionLCK_shadow8Lock to synchronize addition of shadows, mainly on Classic server.

Код: plaintext
1.
LOCK BLOCK  19356
         Series: 20 , Parent:  18892, State: 2, size: 8 length: 4 data: 0
-снова нет инфы в Книге (там до 17-й серии расписано).

Код: plaintext
1.
2.
3.
4.
5.
LOCK BLOCK  19588
         Series: 5 , Parent:  18892, State: 2, size: 8 length: 4 data: 0
...
LOCK BLOCK  19472
        Series: 5, Parent:  18892, State: 2, size: 8 length: 4 data: 0
- это "блокировки существования" таблиц:
Helen Borrie, page 868SymbolSeriesDescriptionLCK_rel_exist5Relation existence lock. Prevents tables from being dropped while any owner has a prepared request that uses that table.Опять не понимаю: НЕТ ни одной таблицы в базе (за исключением словарных), чего тут блокировать надо ?

PS. Пфф... без инструмента типа IBAnalyst (в смысле наглядности инфы) - тяжко... Ну, и чувствуется, что Большая Книга устарела кое-где: не все типы серий расписаны.
...
Рейтинг: 0 / 0
18.01.2013, 09:25:41
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38114845
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrДля WAIT - номер коннекта найдешь при желании.А кто работает в wait-режиме ? Это же камикадзе надо быть...
...
Рейтинг: 0 / 0
18.01.2013, 09:30:23
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38114884
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидНЕТ ни одной таблицы в базе (за исключением словарных), чего тут блокировать надо ?
системные таблицы тоже надо блокировать, они отнюдь не волшебные. А на "книгу" забей, ты ей только голову себе задурил. Смотри в своих сорцах /src/jrd/lck.h, вопросы отпадут.
...
Рейтинг: 0 / 0
18.01.2013, 09:55:33
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38115189
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrТаблоидя всё равно НЕ получу никакой инфы о номере транзакции / коннекта, который не даёт добавить строку в detail-таблицу?для NOWAIT транзакции есс-но не получишь, ибо не сможешь в ЛТ найти ожидающий коннект. Для WAIT - номер коннекта найдешь при желании.Хорошо, вот пример с WAIT.
Новая база, таблица t(id int, f01 int);
В таблицу добавлена единственная строка: id=1, f01=1, после чего выполнен quit.
Затем:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
 connect #1 
C:\MIX\firebird\fb25>isql 192.168.0.60:test -n
Database:  192.168.0.60:test
SQL> update t set f01=-1 where id=1;
SQL> select current_connection,current_transaction from rdb$database;

CURRENT_CONNECTION CURRENT_TRANSACTION
================== ===================
                 6                  24

 connect #2 
C:\MIX\firebird\fb25>isql 192.168.0.60:test -n
Database:  192.168.0.60:test
SQL> update t set f01=-2 where id=1; -- висяк.

В этот момент была снята ЛТ:
Код: plaintext
fb_lock_print -a -d test
-- см аттач.
Допустим, надо понять, кто не даёт второму коннекту проапдейтить строку.

В лок-таблице ищем строку с pending: NNNNN, где NNNNN > 0.
Такой блок - один (в данной ситуации):
Код: plaintext
1.
2.
3.
4.
5.
OWNER BLOCK 215480
        Owner id: 132684431762415, type: 1, pending:  216240 
        Process id:  30893 (Alive), thread id: 140166742538000
        Flags: 0x06             scan wait infn      
        Requests (84):  forward: 228144, backward: 216240
        Blocks: *empty*

Если теперь поискать строку вида 'BLOCK 216240", то мы выходим на вот это:
Код: plaintext
1.
2.
3.
4.
5.
REQUEST BLOCK  216240 
        Owner: 215480, Lock: 214264, State: 0, Mode: 3, Flags: 0x82
        AST: 0x(nil), argument: 0x(nil)
        lrq_own_requests:       forward: 215492, backward: 229296
        lrq_lbl_requests:       forward: 214240, backward: 214144
        lrq_own_blocks  : *empty*
(других таких блоков нету).
То, что в этом блоке записано "Owner: 215480", подсказывает очевидное: мы нашли нечто, что хотел заблокировать зависший коннект с id=215480. А хотел он залочить объект с id = 214264.

Ищем далее строку "BLOCK 214264" и находим её тут:
Код: plaintext
1.
2.
3.
4.
5.
6.
LOCK BLOCK  214264 
        Series: 4, Parent: 213184, State: 6, size: 8 length: 4 data: 24
        Key: 000024, Flags: 0x00, Pending request count:      1
        Hash que (4):   forward: 214776, backward: 213824
        Requests (2):   forward: 214144, backward: 216240
                Request 214144, Owner: 212936, State: 6 (6), Flags: 0x00
                Request 216240, Owner: 215480, State: 0 (3), Flags: 0x82
Видим, что её получил в exclusive-распоражение некто "Request 214144, Owner: 212936 , State: 6 (6)".

Отлично. Ищем теперь строку "OWNER BLOCK 212936".
Находим этот блок в самом начале ЛТ:
Код: plaintext
1.
2.
3.
4.
5.
6.
OWNER BLOCK  212936 
        Owner id: 132684431762346, type: 1, pending:      0
        Process id:  30893 (Alive), thread id: 140166742538000
        Flags: 0x00                               
        Requests (83):  forward: 213120, backward: 224048
        Blocks: *empty*
- видим, что он сам уже ничего не ждёт (pending: 0), но... дальше-то что ?
Номер коннекта (который равен 6 - см выше), номер транзакции - в где они тут ?

С другой стороны, в mon$statements видим (с третьего окна):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
SQL> select * from mon$statements where mon$attachment_id<>current_connection;

MON$STATEMENT_ID                235
MON$ATTACHMENT_ID               8
MON$TRANSACTION_ID              26
 MON$STATE                       1 
MON$TIMESTAMP                   2013-01-18 12:24:46.4340
MON$SQL_TEXT                    0:4
 update t set f01=-2 where id=1 
MON$STAT_ID                     7

MON$STATEMENT_ID                35
MON$ATTACHMENT_ID               6
MON$TRANSACTION_ID              <null>
 MON$STATE                       0 
MON$TIMESTAMP                   <null>
MON$SQL_TEXT                    0:6
 update t set f01=-1 where id=1 
MON$STAT_ID                     10
По равенству ID'шников таблицы `t` можно понять, ес-сно, что тут и есть затык. Но это - примитивный запрос, в нём сразу видно, ЧТО будет меняться. В реальности такое редко бывает.

В общем, я так и не понял, как в ЛТ найти транзакцию-"держиморду", которая не даёт развиваться остальным. Что в wait-режиме, что без него.
...
Рейтинг: 0 / 0
18.01.2013, 12:58:18
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38115309
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ищи лок с series = LCK_attachment, у которого будет всего один owner = 212936. Это LOCK BLOCK 214080. Его key равен номеру коннекта. С транзакцией сложнее, т.к. она напрямую с локом не связана. Если ожидание именно на записи, то смотри key у конфликтного лока 214264. Либо просто ищи все тр-ции данного овнера по вышесказанному алгоритму, только для series = LCK_tra.
...
Рейтинг: 0 / 0
18.01.2013, 13:29:19
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38115339
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrищи лок с series = LCK_attachment, у которого будет всего один owner = 212936. Это LOCK BLOCK 214080. Его key равен номеру коннекта. С транзакцией сложнее, т.к. она напрямую с локом не связана. Если ожидание именно на записи, то смотри key у конфликтного лока 214264. Либо просто ищи все тр-ции данного овнера по вышесказанному алгоритму, только для series = LCK_tra.Нашёл, псип. Вот они, коннекты (6 и 8 для данного примера):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
LOCK BLOCK 214080
	 Series: 7 , Parent: 213184, State: 6, size: 8 length: 4 data: 0
	 Key: 000006 , Flags: 0x00, Pending request count:      0
	Hash que (3):	forward: 214904, backward:    420
	Requests (1):	forward: 214016, backward: 214016
		Request 214016, Owner: 212936, State: 6 (6), Flags: 0x00
...
LOCK BLOCK 227248
	 Series: 7 , Parent: 213184, State: 6, size: 8 length: 4 data: 0
	 Key: 000008 , Flags: 0x00, Pending request count:      0
	Hash que (1):	forward:    436, backward:    436
	Requests (1):	forward: 225392, backward: 225392
		Request 225392, Owner: 215480, State: 6 (6), Flags: 0x00

ЗЫ. Соответствие номеров серий их мнемоникам вытащу сюда, чтобы в дальнейшем не рыскать по сырцам.
Код: 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.
[root@firebird jrd]# tail --lines=+35 lck.h | cat -n
     1          LCK_database = 1,                       // Root of lock tree
     2          LCK_relation,                           // Individual relation lock
     3          LCK_bdb,                                        // Individual buffer block
     4          LCK_tra,                                        // Individual transaction lock
     5          LCK_rel_exist,                          // Relation existence lock
     6          LCK_idx_exist,                          // Index existence lock
     7          LCK_attachment,                         // Attachment lock
     8          LCK_shadow,                                     // Lock to synchronize addition of shadows
     9          LCK_sweep,                                      // Sweep lock for single sweeper
    10          LCK_retaining,                          // Youngest commit retaining transaction
    11          LCK_expression,                         // Expression index caching mechanism
    12          LCK_prc_exist,                          // Procedure existence lock
    13          LCK_update_shadow,                      // shadow update sync lock
    14          LCK_backup_alloc,           // Lock for page allocation table in backup spare file
    15          LCK_backup_database,        // Lock to protect writing to database file
    16          LCK_backup_end,                         // Lock to protect end_backup consistency
    17          LCK_rel_partners,                       // Relation partners lock
    18          LCK_page_space,                         // Page space ID lock
    19          LCK_dsql_cache,                         // DSQL cache lock
    20          LCK_monitor,                            // Lock to dump the monitoring data
    21          LCK_tt_exist,                           // TextType existence lock
    22          LCK_cancel,                                     // Cancellation lock
    23          LCK_btr_dont_gc,                        // Prevent removal of b-tree page from index
    24          LCK_shared_counter,                     // Database-wide shared counter
    25          LCK_rel_gc                                      // Allow garbage collection for relation
...
Рейтинг: 0 / 0
18.01.2013, 13:39:00
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38115554
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
ТаблоидСоответствие номеров серий их мнемоникам вытащу сюдаХм... а почему в этом списке нет краткосрочных блокировок (латчей ?), которые ставятся на страницы при их считывании ? (например, при получении gen_id, да и вообще при получении содержимого любой записи)
...
Рейтинг: 0 / 0
18.01.2013, 15:21:17
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38115837
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
страничные локи - это LCK_bdb. Страничные латчи - это несколько другое и не относится к ЛМ.
...
Рейтинг: 0 / 0
18.01.2013, 18:18:26
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38115925
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrстраничные локи - это LCK_bdb. Страничные латчи - это несколько другое и не относится к ЛМ.LCK_bdb - это блокировка, для которой Series = 3 (я выше вытряхнул из lck.h соотв-щее перечисление).
Тогда вышеприведенного примера и снимка ЛТ (файл выше в аттаче) получается 66(!) блокировок страниц:
Код: plaintext
1.
grep -i "series: 3" fb_lock_print_all_when_infinite_lock_waiting.txt  | wc -l
66

Если посмотреть на эти lock block'и, то увидим, только одна страница схвачена в режиме exclusive ( state=6 ), а все остальные - в режиме protected read (state=3):
Код: plaintext
1.
2.
3.
4.
5.
6.
bash-4.1$ grep -i "series: 3" lp_lck_dbd.txt | tail -5
        Series: 3, Parent: 213184, State: 3, size: 8 length: 8 data: 0
        Series: 3, Parent: 213184, State: 3, size: 8 length: 8 data: 0
        Series: 3, Parent: 213184, State: 3, size: 8 length: 8 data: 0
        Series: 3, Parent: 213184, State: 3, size: 8 length: 8 data: 0
        Series: 3, Parent: 213184,  State: 6 , size: 8 length: 8 data: 0

Про protected read догадываюсь: это блокировки метаданных, чтобы никто таблицу `t` не дропнул.
Но про последнюю, exclusive-блокировку:
Код: plaintext
1.
2.
3.
LOCK BLOCK 216304
        Series: 3, Parent: 213184, State: 6, size: 8 length: 8 data: 0
        Key:  0001:000170 , Flags: 0x00, Pending request count:      0
-- имею вопрос: страница базы номер 170, затолканная в hash-гнездо номер 1, сейчас заблокирована "вусмерть", т.е. её нельзя даже прочитать . Это так ?
...
Рейтинг: 0 / 0
18.01.2013, 19:26:30
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38115931
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrСтраничные латчи - это несколько другое и не относится к ЛМ.Если так, то существует ли механизм определения времени, затрачиваемого на получение этих латчей, скажем, при выполнении какого-нибудь сверхтяжкого селекта ? Т.е. вот идёт селект, ему надо прочесть огромное число страниц базы (не говоря уже про число строк таблиц!). Он запрашивает латчи на чтение каждой страницы, затем "отпускает" страницу и идёт дальше. Сколько времени у него уходит на это - как определить ?
...
Рейтинг: 0 / 0
18.01.2013, 19:31:50
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38115992
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидСколько времени у него уходит на это - как определить ?
никак. Но в твоем случае пофиг, ибо за латчи в SC/CS практически нет конкуренции. Они свои в каждом экземпляре кеша.
...
Рейтинг: 0 / 0
18.01.2013, 20:43:58
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38115993
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидимею вопрос: страница базы номер 170, затолканная в hash-гнездо номер 1, сейчас заблокирована "вусмерть", т.е. её нельзя даже прочитать . Это так ?
не так. Этот лок просто кеширован коннектом. Когда кто-либо еще будет брать эту страницу, лок отпустится по АСТу.
...
Рейтинг: 0 / 0
18.01.2013, 20:45:16
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38125996
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Очередной вопросик возник.
Создал базу, page_size = 16K, в ней - табличку:
Код: sql
1.
2.
3.
4.
create table t(id int, f01 int, f02 int);
insert into t values(1, 100, 111);
insert into t values(2, 200, 222);
commit;

Дальше отсоединился и выполнил b/r. Таблица с двумя записями, очевидно, влезла в одну страницу базы:
gstat -r
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
<...>
T (128)
    Primary pointer page: 141, Index root page: 142
    Average record length: 16.00, total records: 2
    Average version length: 10.00, total versions: 1, max versions: 1
    Data pages: 1, data page slots: 1, average fill: 1%
<...>

Затем запускаю два isql окошка и в каждом них делаю апдейты строк без lock conflict'ов:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
 session #1 
C:\1INSTALL\FIREBIRD\Data>isql -n localhost:C:\1INSTALL\FIREBIRD\Data\TT.FDB
Database:  localhost:C:\1INSTALL\FIREBIRD\Data\TT.FDB
SQL>  select current_connection,current_transaction from rdb$database;

CURRENT_CONNECTION CURRENT_TRANSACTION
================== ===================
                 3                   7

SQL>  update t set f01=-f02, f02=-f01 where id=1;

 session #2 
C:\1INSTALL\FIREBIRD\Data>isql localhost:C:\1INSTALL\FIREBIRD\Data\TT.FDB -n
Database:  localhost:C:\1INSTALL\FIREBIRD\Data\TT.FDB
SQL> select current_connection,current_transaction from rdb$database;

CURRENT_CONNECTION CURRENT_TRANSACTION
================== ===================
                 4                   8

SQL> update t set f01=-f02, f02=-f01 where id=2;
Теперь делаю снимок ЛТ:
Код: plaintext
fb_lock_print -c -a -d TT.FDB >fb_lp_two_connects_updated_two_diff_records.txt

Если я правильно понимаю, снимок ЛТ должен содержать множество lock block'ов с сериями = 3 (это LCK_bdb - Individual buffer block). Причём, та единственная страница базы, в которой живут две записи таблицы `T`, должна встречаться в двух lock block'ах - ведь два коннекта держут "свои" блокировки записей, которые живут на этой самой странице.
И в каждом из этих лок-блоков должны быть блокировки уровня shared write, что соответствует "state: 4".

Я не вижу в упор, где это в ЛТ (она в аттаче).
Ибо команда поиска:
Код: plaintext
type fb_lp_two_connects_updated_two_diff_records.txt | findstr /i /n /c:"series: 3" > series_3_rows.txt
- выдаёт 48 строк со "State: 3" (protected read) и одну (49-ю) строку с "State: 6" (exclusive).
 
findstr result
Код: 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.
1178:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1201:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1223:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1231:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1252:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1260:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1268:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1276:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1292:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1300:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1308:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1316:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1324:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1332:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1340:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1356:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1364:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1380:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1388:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1396:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1404:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1412:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1420:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1428:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1436:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1444:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1452:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1460:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1468:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1476:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1484:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1492:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1500:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1508:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1516:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1524:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1532:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1540:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1548:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1556:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1564:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1572:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1580:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1588:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1596:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1604:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1612:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1628:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1636:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1644:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1652:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1660:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1668:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1692:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1700:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1708:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1716:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1724:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1732:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1740:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1748:   Series: 3, Parent:  18892, State: 6, size: 8 length: 8 data: 0
...
Рейтинг: 0 / 0
27.01.2013, 00:16:58
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126001
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Таблоиддва коннекта держут "свои" блокировки записей

Ничего они не держут. Заблокировали что нужно, сделали своё грязное дело и давно уже
блокировки отпустили так, что ты и глазом моргнуть не успел.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.01.2013, 00:26:45
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126002
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Dimitry SibiryakovНичего они не держут. Заблокировали что нужно, сделали своё грязное дело и давно уже
блокировки отпустили так, что ты и глазом моргнуть не успел.Это как это ?! а "кто" тогда мешает третьему коннекту проапдейтить эти же строки ?
...
Рейтинг: 0 / 0
27.01.2013, 00:28:22
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126008
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Таблоида "кто" тогда мешает третьему коннекту проапдейтить эти же строки ?

Совесть. Он видит наличие незакоммиченных версий.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.01.2013, 00:46:40
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126019
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Dimitry SibiryakovОн видит наличие незакоммиченных версий.Этого мало. Он также должен видеть, живые ли соотв-щие транзакции.
Тогда получается, что составить картину типа "Кто чего сейчас держит заблокированным" практически нереально: надо пройтись по всем незакоммиченным версиям и попробовать "тихо" их залочить, чтобы понять, живы ли соотв-щие транзакции - владельцы блокировок, а затем "разлочить".
Этот процесс будет выполняться долго и всё загнётся. Я прав в своей догадке ?
...
Рейтинг: 0 / 0
27.01.2013, 00:57:59
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126028
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
ТаблоидОн также должен видеть, живые ли соотв-щие транзакции.

А для этого у него есть TIP и возможность послать сигнал "есть кто живой" другой транзакции.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.01.2013, 01:09:36
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126049
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидПричём, та единственная страница базы, в которой живут две записи таблицы `T`, должна встречаться в двух lock block'ахНет, ибо страница - одна, значит и блокировка у неё тоже одна.
Вот request'ов может быть много. А lock - один.

Таблоидведь два коннекта держут "свои" блокировки записейНет никаких блокировок записей. НЕТ ИХ.

Таблоидблокировки уровня shared writeНет конечно.

События происходили примерно так:
1. первый коннект собирается читать страницу с данными и просит SR блокировку
- блокировка получена, можно читать страницу
2. первый коннект собирается менять страницу с данными и просит PW блокировку
- блокировка получена, можно менять страницу
- старая SR при этом отпускается
3. второй коннект собирается читать с данными и просит SR блокировку
- первый коннект получает сигнал и отпускает свою PW блокировку, при этом он пишет страницу на диск
- второй коннект получает SR блокировку и читает страницу с диска
4. второй коннект собирается менять страницу с данными и просит PW блокировку
...

Итого: у последнего писателя есть PW блокировка, у остальных - нет никаких блокировок
этой страницы.
...
Рейтинг: 0 / 0
27.01.2013, 02:16:44
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126051
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Чтобы ещё больше запутать Таблоида, уточню - то, что движок считает блокировками, на самом деле лишь запросы на блокировки. Т.е. в лок-менеджере им соответствуют REQUEST'ы.

Есть две основные сущности - владельцы ресурсов (OWNER'ы) и собственно ресурсы, точнее их блокировки (LOCK'и). Владельцы делают запросы (REQUEST'ы) на владение ресурсами. Можно сказать, что владельцы и ресурсы связаны как M:N посредством запросов.

С точки зрения владельца его список запросов есть список ресурсов которыми он владеет или хочет овладеть.

С точки зрения ресурса, его список запросов можно разделить на две части:
- удовлетворённые запросы (их владельцы совместно владеют ресурсом), и
- ожидающие запросы (их владельцы хотят получить доступ, несовместимый с доступом первой группы)

Например, из твоего файла:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
LOCK BLOCK  22120
	Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
	Key: 0001:000143, Flags: 0x00, Pending request count:      0
	Hash que (1):	forward:   1500, backward:   1500
	Requests (2):	forward:  22068, backward:  31892
		Request  22068, Owner:  18744, State: 3 (3), Flags: 0x00
		Request  31892, Owner:  20992, State: 3 (3), Flags: 0x00
Это блокировка страницы (Series: 3) с номером 143.
Её состояние - PR (State: 3).
Ею владеют 2 владельца (18744, 20992)

А вот совсем другая блокировка
Код: plaintext
1.
2.
3.
4.
5.
6.
LOCK BLOCK  30476
	Series: 4, Parent:  18892, State: 6, size: 8 length: 4 data: 7
	Key: 000008, Flags: 0x00, Pending request count:      0
	Hash que (3):	forward:  30360, backward:  22584
	Requests (1):	forward:  30424, backward:  30424
		Request  30424, Owner:  20992, State: 6 (6), Flags: 0x00
Это блокировка транзакции (Series: 4) с номером 8.
Её состояние - EX (State: 6).
Ею безраздельно владеет владелец 20992


PS в предыдущем посте читать вместо SR и PW соответственно PR и EX
...
Рейтинг: 0 / 0
27.01.2013, 02:31:58
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126113
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
С учетом вот этой фразы:hvladчитать вместо SR и PW соответственно PR и EX- подправил тот текст и получаю:hvladСобытия происходили примерно так:
1. первый коннект собирается читать страницу с данными и просит SR Protected Read блокировку
- блокировка получена, можно читать страницу
2. первый коннект собирается менять страницу с данными и просит PW Exclusive блокировку
- блокировка получена, можно менять страницу
- старая SR при этом отпускается ВОПРОС-1. Первый коннект выдал команду UPDATE, смысл которой - поменять содержимое страницы. Да, понятно, что сначала надо найти эту страницу. Но почему нельзя после её нахождения сразу поставить exclusive-блокировку, без промежуточной PR ? И почему, кстати, нужна именно EX, разве Protected Write не будет достаточной ? (страница ведь обновляется целиком, никаких там "частичных записей" со 153-его по 234-й байт нету ==> никто не сможет прочитать её в "несогласованном" виде. Или не так ?)

И еще вопрос.hvlad
Код: plaintext
1.
2.
3.
4.
5.
6.
LOCK BLOCK  22120
	Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
	Key: 0001 :000143 , Flags: 0x00, Pending request count:      0
	Hash que (1):	forward:   1500, backward:   1500
	Requests (2):	forward:  22068, backward:  31892
		Request  22068, Owner:  18744, State: 3 (3), Flags: 0x00
		Request  31892, Owner:  20992, State: 3 (3), Flags: 0x00

Это блокировка страницы (Series: 3) с номером 143 .
Её состояние - PR (State: 3). Там еще десятки аналогичных лок-блоков:
 
Код: 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.
...
LOCK BLOCK  23860
        Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
        Key: 0001:0000 79 , Flags: 0x00, Pending request count:      0
        Hash que (1):   forward:    988, backward:    988
        Requests (2):   forward:  23808, backward:  30904
                Request  23808, Owner:  18744, State: 3 (3), Flags: 0x00
                Request  30904, Owner:  20992, State: 3 (3), Flags: 0x00

LOCK BLOCK  26180
        Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
        Key: 0001:0000 80 , Flags: 0x00, Pending request count:      0
        Hash que (1):   forward:    996, backward:    996
        Requests (2):   forward:  26128, backward:  29372
                Request  26128, Owner:  18744, State: 3 (3), Flags: 0x00
                Request  29372, Owner:  20992, State: 3 (3), Flags: 0x00

LOCK BLOCK  22700
        Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
        Key: 0001:0000 81 , Flags: 0x00, Pending request count:      0
        Hash que (1):   forward:   1004, backward:   1004
        Requests (2):   forward:  22648, backward:  31528
                Request  22648, Owner:  18744, State: 3 (3), Flags: 0x00
                Request  31528, Owner:  20992, State: 3 (3), Flags: 0x00
...
Они отличаются только номерами внутри хеш-гнёзда ("0001:000NNN"), а еще ID'шниками forward/backward.
Все они в том же самом Protected Read, т.е. эти страницы (..., 79, 80, 81, ...) сейчас можно читать, но в них нельзя записывать.

ВОПРОС-2. Что это за страницы ? Как понять, к какому объекту базы они относятся ? В gstat'e по пользовательским таблицам нет инфы о номерах страниц, а rdb$-таблицы так вообще не отображаются никак.

hvlad3. второй коннект собирается читать с данными и просит Protected Read SR блокировку
- первый коннект получает сигнал и отпускает свою Exclusive PW блокировку, при этом он пишет страницу на диск
- второй коннект получает Protected Read SR блокировку и читает страницу с диска ВОПРОС-3. По каким правилам owner-"А", получивший сигнал "отпусти ресурс!" от owner'a-"Б", решает, можно ли это делать ? Или он делает это всегда, а уж owner-"Б" должен сам позаботиться о сохранности изменений owner'a-"A" ?
...
Рейтинг: 0 / 0
27.01.2013, 11:21:23
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126157
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид ВОПРОС-1. Первый коннект выдал команду UPDATE, смысл которой - поменять содержимое страницы. Да, понятно, что сначала надо найти эту страницу. Но почему нельзя после её нахождения сразу поставить exclusive-блокировку, без промежуточной PR ?
потому что update "изнутри" - это а-ля for select + update where current of. Нафига лочить страницу на запись, если предикат может оказаться ложным и мы запись не будем менять? Но иногда таки ставится сразу EX еще при чтении, если оптимизатор сочтет это более удачным. Это экономит конверсию лока.

ТаблоидИ почему, кстати, нужна именно EX, разве Protected Write не будет достаточной ?
в случае страничных блокировок монопенисуально, т.к. поведение читателей от этого никак не изменится

ТаблоидОни отличаются только номерами внутри хеш-гнёзда ("0001:000NNN")
0001 - это не хеш-гнездо, а номер page space

Таблоид ВОПРОС-2. Что это за страницы ? Как понять, к какому объекту базы они относятся ?
никак (без отладчика)

Таблоид ВОПРОС-3. По каким правилам owner-"А", получивший сигнал "отпусти ресурс!" от owner'a-"Б", решает, можно ли это делать ? Или он делает это всегда, а уж owner-"Б" должен сам позаботиться о сохранности изменений owner'a-"A" ?
всегда, при условии что owner A в данный момент не меняет страницу. Если меняет - то отпустит "как только так сразу". О сохранности заботится owner A, записывая измененную страницу на диск - читай ответ Влада внимательнее.
...
Рейтинг: 0 / 0
27.01.2013, 13:05:50
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126162
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
ТаблоидВ gstat'e по пользовательским таблицам нет инфы о номерах страниц
IBSurgeonViewer покажет. правда, не на "живой" базе.
...
Рейтинг: 0 / 0
27.01.2013, 13:14:25
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126168
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrНафига лочить страницу на запись, если предикат может оказаться ложным и мы запись не будем менять?Ну так мы всё равно её лочим, только в режиме protected read.

К тому же, предикат окажется ложным после получения protected read-блокировки только в случае, когда эта же запись подверглась модификации другой транзакцией
 
оно ?
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
 connect #1 
SQL> select * from t;

          ID          F01          F02
============ ============ ============
           1         -111         -100
           2          200          222

SQL> delete from t where id=1;

 connect #2 
SQL> update t set f01=-f01 where id=1;

 connect #1 
SQL> commit;

 connect #2 
Statement failed, SQLSTATE = 40001
deadlock
-update conflicts with concurrent update
-concurrent transaction number is 12
Не так уж часто сиё бывает по сравнению с числом страниц, которые остаются неизменными после первоначального создания и многократных дальнейших их чтений.
Почему нельзя так:
1) запрашиваем страницу 123 в режиме protected write
2) получили, проверяем предикат
3) предикат не изменился ==> сразу же меняем содержимое, без затрат на повышение блокировки
4) предикат изменился ==> отвал.
Ы ?

dimitr0001 - это не хеш-гнездо, а номер page spaceЧто это за "единица измерения", в где-то про неё написано ?
...
Рейтинг: 0 / 0
27.01.2013, 13:27:19
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126181
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидНу так мы всё равно её лочим, только в режиме protected read.
это не мешает остальным коннектам ее читать в этот момент, в отличие от

ТаблоидК тому же, предикат окажется ложным после получения protected read-блокировки только в случае, когда эта же запись подверглась модификации другой транзакцией
серверу глубоко фиолетово, какой именно у тебя предикат. Может там условие 1=0. Тоже лочить все страницы на запись?

ТаблоидПочему нельзя так
потому что фигню написал. Я не знаю что такое "предикат изменился".

ТаблоидЧто это за "единица измерения", в где-то про неё написано ?
оно тебе не надо. Это область со своей нумерацией страниц. В первом приближении это файл. Для основной базы это всегда 1, для GTT - ID экземпляра данных (временного файла).
...
Рейтинг: 0 / 0
27.01.2013, 13:52:30
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126182
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvIBSurgeonViewer покажет. правда, не на "живой" базе.Дык интересуют именно возможности анализа ЛТ живой базы, на которой юзера лбами сталкиваются :-)
Впрочем, любопытная штука, спасибо.
Только и по ней непонятка есть - см иллюстр.

ЗЫ. Этот вьювер развивается или нет ? там указан 2004-й год...
...
Рейтинг: 0 / 0
27.01.2013, 13:53:21
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126185
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидНу так мы всё равно её лочим, только в режиме protected read.Ты разницу между shared и exclusive понимаешь ? А то, что кроме тебя, эту страницу могут хотеть прочитать ещё 100500 коннектов - тоже понимаешь ?

ТаблоидК тому же, предикат окажется ложным после получения protected read-блокировки только в случае, когда эта же запись подверглась модификации другой транзакциейУ тебя всегда и везде доступ только по ПК ?
Вот откуда эта категоричность ?

ТаблоидНе так уж часто сиё бываетВ конкурентной среде записи могут меняться гораздо быстрее, чем ты себе можешь представить.

ТаблоидПочему нельзя такДмитрий выше написал, что так иногда делается.

ТаблоидЧто это за "единица измерения", в где-то про неё написано ?Это не есть инф-ция для конечного пользователя. Посему - кому надо, те и так знают.

PageSpace ввели для реализации GTT. В данный момент есть PageSpace = 1, в которой учитываются страницы основной БД, и все остальные PageSpace, в которых живут данные GTT.
...
Рейтинг: 0 / 0
27.01.2013, 14:02:27
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126190
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrэто не мешает остальным коннектам ее читать в этот момент, в отличие отhvladТаблоидНу так мы всё равно её лочим, только в режиме protected read.Ты разницу между shared и exclusive понимаешь ? А то, что кроме тебя, эту страницу могут хотеть прочитать ещё 100500 коннектов - тоже понимаешь ?я всё это понимаю. Поэтому про exclusive и не говорил ни разу. Наоборот, заменить её хотел на PW :-)
А спрашивал про protected write , которая запрещает другим писать, но НЕ запрещает читать.
hvladУ тебя всегда и везде доступ только по ПК ?
Вот откуда эта категоричность ?Нет, конечно. Но причём тут вид доступа ?

ЗЫ. Табличка в Книге про совместимость блокировок - пущай тут тоже будет.
...
Рейтинг: 0 / 0
27.01.2013, 14:15:48
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126195
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидспрашивал про protected write , которая запрещает другим писать, но НЕ запрещает читать
будет читаться несогласованная чухня. Единственное теоретически возможное исключение - страница генераторов, о чем DS уже стонет который год.
...
Рейтинг: 0 / 0
27.01.2013, 14:22:22
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126200
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Таблоидспрашивал про protected write, которая запрещает другим писать, но НЕ
запрещает читать.
Запрещает, поскольку другие таки читают в PR, которая не совместима с PW. Вот если бы они
читали с SR...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.01.2013, 14:31:10
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126208
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
dimitrбудет читаться несогласованная чухня. Единственное теоретически возможное
исключение - страница генераторов, о чем DS уже стонет который год.

Ну, во-первых, не единственное. Во-вторых с "несогласованной чухнёй" тоже не всё так
просто: в системах с shared cache не используются локи, а у латчей нет уровней PW-SR.
Остальные архитектуры не в состоянии прочитать страницу, изменённую наполовину, поскольку
она не запишется на диск. Правда, я не знаю как там с этим сейчас в тройке.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.01.2013, 14:41:55
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126209
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrбудет читаться несогласованная чухня.НЕ врубился я что-то.
Вот есть некая страница N, транзакция Т1 делает попытку установить на ней PW (при выполнении DML, конечно же).
Ждёт, т.к. другая транзакция еще дописывает что-то в эту страницу.
Дождалась, установила.
Пишет на эту страницу что-то там.

В это время транзакция Т2 читает страницу в режиме SR.

ВОПРОС. Может ли Т2 прочесть эту страницу в "частично изменённом" виде ?
То есть, если страница у нас 16 К, в ней было записано, скажем, rpad('', 16384, 'A'), и транзакция Т1 должна записать в неё rpad('', 16384, 'B') - то может ли Т2 прочесть в некоторое мгновение чухню типа "BBBBBBBBBBBBBAAAAAAAAAAAAAAAAAAAAA...AAA"
...
Рейтинг: 0 / 0
27.01.2013, 14:43:19
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126217
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
dimitrЕдинственное теоретически возможное исключение - страница генераторовЯ не вижу, каким образом это исключение возможно. Разве что добавлять локи уровня генератора.
Но, при наличии совершенно нормальных прикладных способов обхода "проблемы", я не считаю нужным даже смотреть в эту сторону.
...
Рейтинг: 0 / 0
27.01.2013, 14:49:31
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126225
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидВОПРОС. Может ли Т2 прочесть эту страницу в "частично изменённом" виде ?
при общем кеше - запросто. При раздельном - нет, но там другие проблемы будут.
...
Рейтинг: 0 / 0
27.01.2013, 14:56:27
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126226
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
hvladпри наличии совершенно нормальных прикладных способов обхода "проблемы", я не считаю нужным даже смотреть в эту сторону
+1 :-)
...
Рейтинг: 0 / 0
27.01.2013, 14:57:13
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126230
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
hvladРазве что добавлять локи уровня генератора.
Interlocked* функций недостаточно?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.01.2013, 14:59:32
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126245
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Dimitry SibiryakovhvladРазве что добавлять локи уровня генератора.
Interlocked* функций недостаточно?..Ой, а что это ? Расскажи да научи

Нет, нет и ещё раз нет.
Начни смотреть уже не на одну страницу\один генератор, а на всю систему целиком.

PS Если тебе нужны генераторы только в памяти, без D, сделай себе уже UDF с ними...
...
Рейтинг: 0 / 0
27.01.2013, 15:40:05
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126267
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
hvlad> Начни смотреть уже не на одну страницу\один генератор

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

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.01.2013, 16:17:58
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126294
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Гаджимурадов Рустамситуация разве не облегчитсяКакая ситуация ?
...
Рейтинг: 0 / 0
27.01.2013, 16:59:02
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126308
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
hvlad> Какая ситуация ?

Проблема с конкуренцией за одну страницу генераторов.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.01.2013, 17:17:43
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126310
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Гаджимурадов Рустамhvlad> Какая ситуация ?

Проблема с конкуренцией за одну страницу генераторов.Нет такой проблемы.
...
Рейтинг: 0 / 0
27.01.2013, 17:18:55
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126312
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
ОК, нет так нет.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.01.2013, 17:22:16
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38199044
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
dimitrТаблоид ВОПРОС-2. Что это за страницы ? Как понять, к какому объекту базы они относятся ?
никак (без отладчика)

А если я хочу без отладчика (2.5 classic), сколько это может стоить и к кому обращаться? Меня устроит специализированная отладочная сборка (пусть работает вдвое медленнее). Можно писать на 'server03s'||chr(64)||'m'||'a'||'i'||'l'||chr(46)||'r'||'u' или контактную информацию сюда.
...
Рейтинг: 0 / 0
26.03.2013, 17:06:04
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38199074
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
хотя, пожалуй, нет, отдельная сборка не устроит - это либо должна быть отдельная утилита, либо какой-то способ запуска программы из дистрибутива (пусть собранной под отладку).
...
Рейтинг: 0 / 0
26.03.2013, 17:16:36
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38199357
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
budden,
чего надо-то? Понимать, какая страница к какому объекту относится? Так возьми ods.h, доку по структуре базы на firebirdsql.org, и вперед.
Вопрос только в том, зачем это надо.
...
Рейтинг: 0 / 0
26.03.2013, 20:07:37
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38199409
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
kdvbudden,
чего надо-то? Понимать, какая страница к какому объекту относится? Так возьми ods.h, доку по структуре базы на firebirdsql.org, и вперед.
Вопрос только в том, зачем это надо.

Надо понять, почему система зависла. Зависнуть она могла, вообще говоря, по куче причин, т.к. в ней есть, помимо сервера БД, ещё два вида клиентов. Но, чтобы найти причину, нужно уметь анализировать все компоненты, в т.ч. и СУБД.
...
Рейтинг: 0 / 0
26.03.2013, 21:03:33
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38199411
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
kdvbudden,
чего надо-то? Понимать, какая страница к какому объекту относится? Так возьми ods.h, доку по структуре базы на firebirdsql.org, и вперед.
Вопрос только в том, зачем это надо.
Вот я готов обсудить вопрос, чтобы кто-нибудь написал программулину, которая будет делать "вперёд" вместо меня.
...
Рейтинг: 0 / 0
26.03.2013, 21:04:30
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38199414
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
buddenНадо понять, почему система зависла.
Для этого принадлежность страницы не нужна.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
26.03.2013, 21:07:45
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38199495
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
buddenнужно уметь анализировать все компоненты, в т.ч. и СУБД.
не выйдет. В том смысле, что когда надо "анализировать", ну вот как мы (IBSurgeon/iBase.ru), просто берем debug билд, и смотрим, где затык, именно в отладчике.
А ты просишь не просто "отладочную сборку", которую сам отлаживать не собираешься, но еще и какую-то непонятную утилиту.

buddenкоторая будет делать "вперёд" вместо меня.
которая заодно будет и кофе варить...
Если бы БЫЛА такая утилита, уже бы давно ею все пользовались. Но ее нет, и вряд ли будет.
...
Рейтинг: 0 / 0
26.03.2013, 22:23:54
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38199568
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
kdv, ну ведь отладчик пользуется той инфой, к-рая уже есть в программе. Или нет?
...
Рейтинг: 0 / 0
26.03.2013, 23:44:15
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38199995
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
budden,

а может я с утра не так понял, в общем, не знаю.
Чтобы отладчик мог отлаживать программу, ее компилируют с отладочной информацией. Отладочная информация позволяет сопоставить исходный код и код, выполняемый процессором, ставить точки останова, проверять значение переменных, и т.д.

Кто такой отладчик в вашем понимании, и какой "инфой" и как он пользуется - я не представляю. То есть, да, отладчик пользуется информацией из программы, но вы в эти слова вкладываете какой-то свой, причем совершенно фантастический смысл.
...
Рейтинг: 0 / 0
27.03.2013, 10:08:45
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38200237
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
kdvbuddenkdv, ну ведь отладчик пользуется той инфой, к-рая уже есть в программе. Или нет?
эту ужасную фразу можно простить, если ты никогда не отлаживал программу ни в какой среде разработки.

Занимался, ничего ужасного, просто ты не понял.
"Отладчик" - это средство для РУЧНОЙ отладки приложений разработчиком.

Отладчик - это средство. Для ручной или нет - это уже зависит от пользователя. gdb - это ведь консольная программа с REPL, значит, можно написать для неё клиента, который будет подавать команды и интерпретировать их результаты. Я именно это и предложил рассмотреть как вариант, видимо, слишком тонко намекнул :) . Тогда (в теории) можно (попробовать) написать утилиту, которая будет использовать не модифицированную отладочную сборку. Всегда запускать серверные процессы под gdb или аттачиться по мере надобности. Но это должен делать специалист, знающий начинку FB, каковым я не являюсь, становиться не хочу и готов от этого откупаться.

Я не говорю, что это просто или возможно в данном случае - я не знаю. Но это - первый вариант, к-рый я бы рассмотрел, если бы решал такую задачу сам. Правда, у меня файрбёрд под виндой и я не знаю, есть ли консольные отладчики для него, но можно ради такого дела и сменить серверную ОС.

Если с одной частью вопроса понятно, перейдём ко второй. Ты предлагал взять "доку по структуре базы на firebirdsql.org". Значит ли это, что мне нужно ещё открыть отдельно файл базы и по нему шарить, или я могу получить всю нужную инфу, анализируя данные программы, не выходя из отладчика? Именно отсутствие данных в сессии gdb является причиной для невозможности написания такой программы. Хотя,с другой стороны, клиент gdb может параллельно делать и другие действия, например, открыть файл базы и шарить по нему.
...
Рейтинг: 0 / 0
27.03.2013, 12:15:27
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38200306
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
buddenзначит, можно написать для неё клиента, который будет подавать команды и интерпретировать их результаты.
неужели?
buddenЗначит ли это, что мне нужно ещё открыть отдельно файл базы и по нему шарить, или я могу получить всю нужную инфу, анализируя данные программы, не выходя из отладчика?
в отладчике можно понять, на какой странице сервер сковырнулся.

у меня попутный вопрос - вы программист? программы отлаживали? Сколько лет уже программируете?
Извиняюсь, но без ответов на эти вопросы я просто не могу понять, что у вас за идея. Пока что она напоминает приделать крылья к трактору. Ну вот крылья же у него теперь есть, значит он должен взлететь. Нет?

Или ближе к теме. Вот Firebird. Вот разработчики. И им говорят - у вас тут зависает. Они говорят - нам нужен дамп, лок-принт, и т.д.
А вы им - не, вы лучше напишите софтину, которая вам скажет, что вот тут и здесь у вас криво, и в результате зависло.
Так, примерно?
...
Рейтинг: 0 / 0
27.03.2013, 12:48:05
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38200309
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
buddenя могу получить всю нужную инфу, анализируя данные программы

Спрошу ещё раз, медленно: какую информацию ты хочешь получать и как её будешь анализировать?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.03.2013, 12:49:13
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38200358
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
DarkMasterПосле этого выпал в осадок... Травы отсыпьте, а?
да все путем, ты просто не в теме
http://www.gnu.org/software/gdb/
GDB, the GNU Project debugger, allows you to see what is going on `inside' another program while it executes -- or what another program was doing at the moment it crashed.

только вот у budden странные представления о процессе отладки и использовании отладочной информации.
...
Рейтинг: 0 / 0
27.03.2013, 13:11:01
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38200384
Фотография DarkMaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DarkMaster
Участник
kdv,

Про GDB я в теме - мне все остальное не понятно ;) Ну да ладно - утро добрым не бывает ;)
...
Рейтинг: 0 / 0
27.03.2013, 13:24:23
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38200562
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
buddenу меня попутный вопрос - вы программист? программы отлаживали? Сколько лет уже программируете?

Я, в общем-то, уже ответил выше. Я программист уже довольно давно (ну уж не меньше 10 лет). Естественно, отладчиками пользоваться приходится регулярно. Правда, gdb видел всего раза два - работаю под виндой обычно. Но в мануал заглядывал.

Вот Firebird. Вот разработчики. И им говорят - у вас тут зависает. Они говорят - нам нужен дамп, лок-принт, и т.д.
А вы им - не, вы лучше напишите софтину, которая вам скажет, что вот тут и здесь у вас криво, и в результате зависло.
Так, примерно?

Я пока не говорю "у вас". Я пока говорю "у меня", причины могут быть и внутри моих клиентов.

На данный момент задача видится так: имеется сервер (классик 2.5), работающий и прямой. Хотим увидеть граф блокировок. Типа такого:
клиент PID 2343, транзакция 4345, блокирует запись с ROWID таким-то в таблице такой-то,блокировка такая-то
... и остальные блокировки
ожидает ввод запроса
клиент PID 4343, транзакция 6689, запросила блокировку такую-то записи с ROWID таким-же в таблице такой-же, ждёт блокировки
... и остальные блокировки

Полезность данного отчёта надо обосновывать?

Если я правильно понял, fb_lock_print такую инфу не выдаёт, но если подключиться gdb к отладочной сборке, то эту информцию можно извлечь в ходе диалога с gdb. Поэтому, методически предлагается запускать отладочную сборку, аттачиться gdb в нужный момент и извлекать инфу об объектах в человекочитабельном виде тем же путём, к-рым обычно это делает человек в отладчике, анализирующий (отлаживающий) работающий экземпляр сервера.

Конечно, может оказаться, что в моём случае FB сломался и мне эта тулзень не поможет, но это - уже мой риск, готов ли я на него пойти - зависит от того, найдутся ли желающие делать такую тулзень и сколько запросят денег за неё.
...
Рейтинг: 0 / 0
27.03.2013, 14:49:55
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38200583
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
buddenТипа такого: клиент PID 2343, транзакция 4345, блокирует запись с ROWID
таким-то в таблице такой-то,блокировка такая-то
Обломись. Firebird - версионник, он не блокирует записи.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.03.2013, 14:55:11
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38200595
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Hello, Dimitry Sibiryakov!
You wrote on 27 марта 2013 г. 14:58:20:

Dimitry Sibiryakov> Обломись.
> Firebird - версионник, он не блокирует записи.ой!
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.03.2013, 14:58:46
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38200707
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
budden,

в лок-таблице нет ничего про ROWID. Максимум - транзакция А ждет транзакцию Б. А какие именно записи первая изменила, даже в отладчике не узнаешь.
...
Рейтинг: 0 / 0
27.03.2013, 15:46:45
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38201253
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
dimitr, ну, вот я потому и спрашивал, какая инфа есть в дебаггере. Если хотя бы на уровне таблиц и других объектов будет инфа, то уже будет не так уж плохо.
...
Рейтинг: 0 / 0
27.03.2013, 20:00:50
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38201291
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
buddenЕсли хотя бы на уровне таблиц и других объектов будет инфа, то уже будет не
так уж плохо.
Эта инфа есть в в текущем выводе fb_lock_print.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.03.2013, 20:35:33
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38201308
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
Dimitry Sibiryakov,
мдя. Прошу прощения у уважаемого сообщества и иду RTFM.
...
Рейтинг: 0 / 0
27.03.2013, 20:52:27
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38201415
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
По номеру страницы невозможно сказать - к какому объекту она принадлежит.
Нужно или иметь карту распределения страниц, которой нет ни в ОДС, ни в рантайм структурах, или прочитать заголовок самой страницы.
...
Рейтинг: 0 / 0
27.03.2013, 23:55:15
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38201419
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
hvladПо номеру страницы невозможно сказать - к какому объекту она принадлежит.

А в RDB$PAGES какие номера страниц перечислены?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
28.03.2013, 00:05:02
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38201487
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Dimitry SibiryakovА в RDB$PAGES какие номера страниц перечислены?PIP, TIP, IRT, GEN
...
Рейтинг: 0 / 0
28.03.2013, 02:27:08
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38204532
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
hvlad,
мануал я ещё не прочитал, но я правильно понял, что всё же, вообще говоря, нельзя понять, из-за какой таблицы одна транзакция ждёт другую? И значит, поставленный мной вопрос актуален.
...
Рейтинг: 0 / 0
29.03.2013, 16:13:47
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38204538
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
buddenнельзя понять, из-за какой таблицы одна транзакция ждёт другую?

Можно посмотреть на активный запрос в таблицах мониторинга.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
29.03.2013, 16:15:21
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38204552
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
hvladPIP, TIP, IRT, GENНе PIP, а PP конечно же
...
Рейтинг: 0 / 0
29.03.2013, 16:22:43
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38204554
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
buddenвообще говоря, нельзя понять, из-за какой таблицы одна транзакция ждёт другую?Вообще говоря - да, нельзя.
...
Рейтинг: 0 / 0
29.03.2013, 16:23:30
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38204563
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
hvladВообще говоря - да, нельзя.
В результатах lock_print для 0001:ХХХХХХХ, ХХХХХХ это физический номер страницы в базе или
логический номер в каком-нибудь внутреннем списке?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
29.03.2013, 16:28:44
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38204662
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
Dimitry Sibiryakov, активный запрос может быть хранимкой. В одной транзакции может быть несколько запросов. Могут быть триггеры на таблицу. Так что через мониторинг - недостаточно хорошо.

hvlad, ну тогда запрос об утилите, которая покажет вышенарисованный граф ожиданий, тоже остаётся актуальным. Если будут предложения - предлагайте.
...
Рейтинг: 0 / 0
29.03.2013, 16:58:46
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38204703
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
buddenВ одной транзакции может быть несколько запросов.

Активный - только один. Он один на весь коннект чисто технически.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
29.03.2013, 17:22:00
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38204747
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Dimitry SibiryakovВ результатах lock_print для 0001:ХХХХХХХ, ХХХХХХ это физический номер страницы в базе или
логический номер в каком-нибудь внутреннем списке?Физический в табличном пространстве
...
Рейтинг: 0 / 0
29.03.2013, 17:46:56
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38204748
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Dimitry SibiryakovbuddenВ одной транзакции может быть несколько запросов.

Активный - только один. Он один на весь коннект чисто технически.Вот процедура с 3-мя апдейтами. Какой из них в данный момент ждёт конкурирующую тр-цию ?
...
Рейтинг: 0 / 0
29.03.2013, 17:48:17
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38204769
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
hvladФизический в табличном пространстве
Значит можно перевести базу в режим бэкапа и натравить на неё сургеонный инструментарий,
чтобы по этому номеру достать тип страницы и принадлежность? При отсутствии массовых
удалений эта информация должна быть довольно стабильна.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
29.03.2013, 17:58:58
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38204813
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Dimitry SibiryakovЗначит можно перевести базу в режим бэкапа и натравить на неё сургеонный инструментарий,
чтобы по этому номеру достать тип страницы и принадлежность?Только, если тебя устроит актуальность этой инф-ции на момент перевода в stalled режим.
Плюс, оный инструментарий должен уметь работать с файлами БД в read-only режиме.

PS маразм, как по мне
...
Рейтинг: 0 / 0
29.03.2013, 18:20:52
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38204870
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
hvladТолько, если тебя устроит актуальность этой инф-ции на момент перевода в
stalled режим.
Чтобы изменился тип или принадлежность страницы данных нужно чтобы с неё были удалены все
записи и собраны как мусор. Нет удалений - не информация остаётся актуальной. Я неправ?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
29.03.2013, 18:50:34
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38204890
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Dimitry SibiryakovЧтобы изменился тип или принадлежность страницы данных нужно чтобы с неё были удалены все
записи и собраны как мусор. Нет удалений - не информация остаётся актуальной. Я неправ?Это не верно, если:
а) Речь не о data page
б) Данные были удалены неделю назад, но до сих пор не собраны мусорщиком. И тут он проснулся. Внезапно (ц)
в) и т.д.

А к чему ты ведёшь ? Объяснись ;)
...
Рейтинг: 0 / 0
29.03.2013, 19:07:37
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38205000
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
hvladА к чему ты ведёшь ? Объяснись ;)
К тому, что утилиту, которую требует будден писать не обязательно, всю информацию можно
получить существующими средствами. Но, конечно, если ты хочешь на этом подзаработать, то я
не хочу тебе мешать и заткнусь.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
29.03.2013, 20:29:40
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38205072
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Dimitry SibiryakovК тому, что утилиту, которую требует будден писать не обязательно, всю информацию можно
получить существующими средствамиЭто слишком оптимистично

Dimitry SibiryakovНо, конечно, если ты хочешь на этом подзаработатьТо я бы так и сказал.
...
Рейтинг: 0 / 0
29.03.2013, 21:57:01
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38208638
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
hvlad,
> Физический в табличном пространстве
Неужели обычному клиенту эта информация недоступна?
...
Рейтинг: 0 / 0
02.04.2013, 11:34:14
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38208777
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
buddenhvlad,
> Физический в табличном пространстве
Неужели обычному клиенту эта информация недоступна?Ничё не понял. Какому клиенту ? Какая информация ?
...
Рейтинг: 0 / 0
02.04.2013, 12:22:17
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38209309
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
hvlad, имелся в виду обычный сервер. Т.е., fb_inet_server в случае классика.
...
Рейтинг: 0 / 0
02.04.2013, 15:30:21
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38209368
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
budden,

почему я должен за тебя додумывать детали вопроса ?
...
Рейтинг: 0 / 0
02.04.2013, 15:49:31
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38213099
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
Предполагаю, что fb_inet_server (или отладчику при отладке fb_inet_server), в принципе, доступна информация о соответствии между физическим адресом страницы в эээ... табличном пространстве и тем, какому объекту принадлежит эта страница. Т.е., в gdb, отлаживая сервер и имея на руках данные из таблицы блокировок, наверняка в REPL можно вызвать функцию "считать заголовок страницы по физическому адресу" и тем самым получить нужную информацию об имени объекта (если она ещё не устарела). Конечно, это - лишь моя гипотеза.
...
Рейтинг: 0 / 0
04.04.2013, 15:45:34
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38213241
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
budden,

гипотеза совершенно не верная.
Например, блокировка страницы запрашивается до того, как сама страница читается с диска и помещается в кеш.
...
Рейтинг: 0 / 0
04.04.2013, 16:43:58
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38220597
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
hvlad, в общем, я понял: дело ясное, что дело тёмное. Ладно, будем мучиться покудова.
...
Рейтинг: 0 / 0
10.04.2013, 15:55:24
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38220693
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
budden,

если бы дело было ясное, тебе уже давно так бы и сказали :)
...
Рейтинг: 0 / 0
10.04.2013, 16:34:56
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38221024
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
hvlad, спасибо за внимание и звиняйте за безпокойство :)
...
Рейтинг: 0 / 0
10.04.2013, 21:04:29
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38484178
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Подниму-ка топег...

Что такое "Mutex wait: N.m%" ?
Слайды доклада ДЕ ясности не вносят.
Нарыл объяснение тёти Ани:
авторThe mutex wait is amount of time processes spend waiting their turn to update the lock table . <...> When a process wants to request or release a lock, it puts itself on a queue for the mutex that guards the table. When it gets that mutex, it makes its changes - sending signals as necessary - and releases the mutex.Если так, то вопрос. Допустим, 200 isql'ей делают вставки в одну и ту же таблицу (вставки небольшие, до 100 строк, с передыхом).
Понятно, что им надо лезть в TIP. Также понятно, что они все лезут на страницу генераторов.

Но число этих окон - постоянное.
А лок-таблица показывает плавный рост mutex wait'a, примерно на 0.1% каждые три-пять минут.

Откудова он тут, рост мьютекса ? И за какой промежуток времени считается этот процент, от начала работы с базой самого первого аттача ?
...
Рейтинг: 0 / 0
29.11.2013, 23:42:08
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38484273
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид,

mutex wait - это просто acquire blocks / acquires * 100%. Считается от момента инициализации лок-таблицы (первого коннекта к базе), fb_lock_print в ФБ3 выводит это время. Со временем запросто может расти по мере того, как уходят другие задержки и лок-таблица становится более нагружена - например в результате заполнения кеша ФБ или кеша файловой системы.
...
Рейтинг: 0 / 0
30.11.2013, 09:25:32
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38484351
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrТаблоид,

mutex wait - это просто acquire blocks / acquires * 100%. Считается от момента инициализации лок-таблицы (первого коннекта к базе), fb_lock_print в ФБ3 выводит это время. Со временем запросто может расти по мере того, как уходят другие задержки и лок-таблица становится более нагружена - например в результате заполнения кеша ФБ или кеша файловой системы.Но тогда это то же самое, что среднее значение температуры с начала многолетних наблюдений. Текущую погоду этим параметром не опишешь.

Раз оба счетчика (acquire blocks, acquires) есть накопительные результаты от царя Гороха, то их отношение в текущий момент времени t может совсем не отражать действительную степень занятости лок таблицы в этот момент t.

Мну кажется, что логичнее было бы выводить отношение разностей этих счетчиков за интервал 1, 5 или 10 сек (задавать его ключиком к fb_lock_print'у).

То есть, если есть два замера в течение 10 сек:
Код: plaintext
1.
2.
Sat Nov 30 12:38:23 2013:       Acquires: 6257278, Acquire blocks:  21592, Spin count:   0
Sat Nov 30 12:38:33 2013:       Acquires: 6273533, Acquire blocks:  21644, Spin count:   0
- то выводить
Код: plaintext
 (21644-21592) / 10 / (6273533-6257278) * 100%

И если это эпический бред и "надо мерять" именно так, как сейчас, то прошу обосновать, почему именно %-)
...
Рейтинг: 0 / 0
30.11.2013, 12:52:08
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38484352
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидТо есть, если есть два замера
fb_lock_print ничего не знает о твоем предыдущем замере
...
Рейтинг: 0 / 0
30.11.2013, 12:55:33
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38484361
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitr,

дык я к тому и говорю: пусть он сам делает два замера, с интервалом, который я ему скажу (default = 1sec).
...
Рейтинг: 0 / 0
30.11.2013, 13:03:15
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38484365
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоид,

fb_lock_print -i

и обзамеряйся по самое нехочу
...
Рейтинг: 0 / 0
30.11.2013, 13:14:17
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38484393
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladfb_lock_print -i

и обзамеряйся по самое нехочуэто я знаю, делал. Хотца видеть "всё в одну строку и сразу", а не натравливать затем парсинг и изобретать одно и то же :-)
...
Рейтинг: 0 / 0
30.11.2013, 13:51:00
| Ответить | Цитировать | Написать  
119 сообщений из 119, показаны все 5 страниц
  все  
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Понимание результатов fb_lock_print
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=40&tid=1564097]:
 0ms
get settings:
 5ms
get forum list:
 9ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 238ms
get topic data:
 7ms
get forum data:
 2ms
get page messages:
 82ms
get tp. blocked users:
 1ms
others: 185ms
total:  533ms
созд. / загр.: 533ms
x
x
Закрыть


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