|
|
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
hi all Хотелось бы понять, что можно получить с помощью этого инструмента. Начну со следующего теста. Дано: Код: plaintext 1. 2. 3. 4. Код: plaintext Далее: Код: plaintext 1. Запускаю еще один isql: Код: plaintext 1. 2. Код: plaintext 1. 2. 3. 4. 5. 6. 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 Если подключить третье 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) Где можно почитать описание столбцов этого лога ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2013, 20:35:38 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
ТаблоидВОПРОСЫ. RTFM firebird.conf на предмет DeadlockTimeout. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2013, 20:44:10 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2013, 20:55:40 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
ТаблоидЗатем стал срубать все ждущие isql-окна (Ctrl-Break) думаю, что замена локального коннекта на локалхост и/или использование ctrl-c вместо ctrl-break привнесут разницу. И таки да, тебе об этом уже говорили, причем по обоим пунктам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2013, 09:23:13 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2013, 12:40:19 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
Таблоидо чём "об этом"? о том, что: - ctrl-break не равен ctrl-c и не прерывает текущую операцию на сервере - сервер обнаруживает отвал клиента (твой ctrl-break) и сразу закрывает коннет только в TCP ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2013, 12:54:13 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
Вижу (не в первый не в первый раз уже), что когда в логе fb_lock_print -i N M значения равны нулям, то это означает сильный (или полный) ступор. Создал пустую базу, в ней: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. Создал следующий .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. Этот скрипт будет в бесконечном цикле дёргать генератор `g`, засекая время этой операции и записывая его в таблицу `log` в случае превышения некоторого порога (например, 500 мс). Кроме того, если на очередной итерации выяснится, что значение генератора оказалось меньше нуля, то будет немедленное прекращение работы скрипта. Батник для старта произвольного числа isql-окон: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Перед началом теста запустил в двух окнах накопительное логирование: 1) fb_lock_print -d: Код: plaintext 1. 2. 3. 4. 5. 6. Код: plaintext 1. 2. 3. Затем запустил с трёх машин в общей сложности около 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 Первому моменту времени в логе fb_lock_print -i 1 N соответствует вот это: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Код: plaintext 1. 2. 3. 4. 5. 6. 2 dimitr: я помню, что ты мне говорил про эти "нулевые строки", когда шло исследование долгих коннектов. Они возникали при снятии бактрассы fb_smp_server'a одним из мониторных окон. Но сейчас этого нет. Идёт снятие только ЛТ, причём без ключика '-c'. Отчего тогда могут возникать эти затыки ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2013, 16:42:30 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
ТаблоидОтчего тогда могут возникать эти затыки ? от ожидания на блокировках ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2013, 17:15:37 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
dimitrот ожидания на блокировкахну, так вот я и хочу понять: где-то видны эти ожидания ? в развернутом отчете fb_lock_print'a ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2013, 17:21:51 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
Таблоидгде-то видны эти ожидания ? в развернутом отчете fb_lock_print'a ? конечно. С ключом -w, например. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2013, 17:23:01 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидгде-то видны эти ожидания ? в развернутом отчете fb_lock_print'a ? конечно. С ключом -w, например.Хорошо, вернусь к начальному примеру. Код: plaintext 1. 2. 3. 4. Снимаю ЛТ на этот момент: fb_lock_print -w -d T1.FDB Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Код: plaintext 1. Снимаю еще раз ЛТ: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Далее делал снимок ЛТ в этом же состоянии еще несколько раз: Код: plaintext 1. 2. 3. 4. 5. 6. 7. С интервалом, равным указанному в 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. А как понять, какая транзакция (или коннект ?) и чего именно ждёт ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2013, 20:57:32 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
ТаблоидА как понять, какая транзакция (или коннект ?) и чего именно ждёт ? смотреть вывод утилиты ниже заголовка и интерпретировать его. Я об этом рассказывал на конфе, запись доступна в онлайне. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2013, 21:12:31 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
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 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. я никогда не видел такого кошмара: thread id = 140170150016784, как мне сопоставить сиё с выводом потоков для fb_smp_server'a: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ЗЫ-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. Жаль, что доклада нет в читабельном виде. На слух трудно, буду переслушивать заново. Так что вопросы еще будут, это точно :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2013, 21:40:18 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
0) на LockMemSize 1) блокирующему был доставлен АСТ и с этого момента он считается оповещенным (ждем его реакции) 2.1) до 2.5 в ФБ-руте, после - в темпе 2.2) ЛТ - это расшаренная между процессами память, сиречь MMP (memory-mapped file) 3) объекты для повторного использования, т.к. ЛТ никогда не уменьшается в размере 4) счетчики операций. enq - новый лок, cnv - изменение статуса лока, rej - отказ в локе, blk - факт блокировки кого-либо 5.1) gdb и сорцы тебе в руки 5.2) забей, это поле только для отладки, ибо отражает не текущее, а последнее известное состояние ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2013, 00:37:01 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
dimitr5.1) gdb и сорцы тебе в рукиАааа!!! Правильно ли я понял, что: 1. Создав примитивную БД с master & detail табличками: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 2. Запустив два isql, в первом из которых удаляю master-запись ( без commit'a), а во втором - пытаясь добавить в detail строку: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 3. Создав снимок лок-таблицы с ключиками -a -m (см аттач) - я всё равно НЕ получу никакой инфы о номере транзакции / коннекта, который не даёт добавить строку в detail-таблицу ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2013, 00:54:26 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
Вывод 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. Тут какие-то lrq_own _requests и lrq_lbl _requests появились - о них в докладе я тоже не засёк ничего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2013, 01:10:01 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
dimitr5.1) gdb и сорцы тебе в рукиа это... что делать тем, кто под виндузой сидит, у них же gdb нету ? (да и знать бы еще, куда там в логе gdb смотреть... ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2013, 01:12:56 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
dimitr2.2) ЛТ - это расшаренная между процессами память, сиречь MMP (memory-mapped file)А зачем это же распространять на SuperClassic, в котором процесс - один ? (потоки - они могут видеть шаред-область без "материализации" её в виде файла или нет ?) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2013, 01:25:29 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
ТаблоидА зачем это же распространять на SuperClassic, в котором процесс - один ? кто тебе такое сказал? Твои embedded-коннекты от isql/gfix/gbak/etc святым духом с базой работают, ага. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2013, 08:36:00 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
Таблоидя всё равно НЕ получу никакой инфы о номере транзакции / коннекта, который не даёт добавить строку в detail-таблицу? для NOWAIT транзакции есс-но не получишь, ибо не сможешь в ЛТ найти ожидающий коннект. Для WAIT - номер коннекта найдешь при желании. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2013, 08:39:20 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
ТаблоидВывод REQUEST BLOCK'ов (<==> ресурсов ) для каждого из двух owner'ов (<==> коннектов ) какой-то сверхъестественный: примерно по 700 строк на каждый коннект. Что можно было запросить у базы, удаляя одну строку в мастере (и еще одну же в детали), либо делая запрос на добавление строки ? на каждую занятую страницу кеша - по одному риквесту, плюс локи на метаданные ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2013, 08:43:03 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
Таблоидчто делать тем, кто под виндузой сидит, у них же gdb нету? у них есть Visual Studio ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2013, 08:46:05 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
ТаблоидНе понимаю, как можно разбираться в этом без надлежащего инструмента-парсераПытаюсь разобраться в "минимально возможных дебрях". Будет много букаф, извиняйте. Создана пустая база и единственный коннект к ней: Код: plaintext 1. 2. 3. Единственный коннект (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. На три "объекта" были запрошены и получены exclusive -блокировки (оба "поля": state & mode - равны 6). Эти три request-блока имеют в полях Lock id'шники = 18892, 19704 & 19876 . Идём в секцию полученных локов (lock block's, ниже request'ов). Блок 18892 (последний в выводе) имеет вид: Код: plaintext 1. 2. 3. 4. 5. 6. 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. 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 bloсk, id = 19240, имеет state = 5 ( protected write: "is used for constsency mode (table stability)"): Код: plaintext 1. 2. 3. 4. 5. Но что это за объект - непонятно. В Большой Книге типы объектов ("серии") заканчиваются номером 17 (LCK_update_shadow). ================ Блок с id = 19016 имеет state = 3 ( protected read: все могут читать этот блок, но никто не может в него записывать - правильно ?). Код: plaintext 1. 2. 3. 4. 5. ================ Остальные блоки имеют статус = 2 ( shared read): Код: plaintext 1. Код: plaintext 1. Код: plaintext 1. 2. 3. 4. 5. 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 (в смысле наглядности инфы) - тяжко... Ну, и чувствуется, что Большая Книга устарела кое-где: не все типы серий расписаны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2013, 09:25:41 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
dimitrДля WAIT - номер коннекта найдешь при желании.А кто работает в wait-режиме ? Это же камикадзе надо быть... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2013, 09:30:23 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
ТаблоидНЕТ ни одной таблицы в базе (за исключением словарных), чего тут блокировать надо ? системные таблицы тоже надо блокировать, они отнюдь не волшебные. А на "книгу" забей, ты ей только голову себе задурил. Смотри в своих сорцах /src/jrd/lck.h, вопросы отпадут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2013, 09:55:33 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=38111442&tid=1564097]: |
0ms |
get settings: |
8ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
175ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
65ms |
get tp. blocked users: |
1ms |
| others: | 205ms |
| total: | 488ms |

| 0 / 0 |
