|
|
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovЧтобы изменился тип или принадлежность страницы данных нужно чтобы с неё были удалены все записи и собраны как мусор. Нет удалений - не информация остаётся актуальной. Я неправ?Это не верно, если: а) Речь не о data page б) Данные были удалены неделю назад, но до сих пор не собраны мусорщиком. И тут он проснулся. Внезапно (ц) в) и т.д. А к чему ты ведёшь ? Объяснись ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2013, 19:07:37 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
hvladА к чему ты ведёшь ? Объяснись ;) К тому, что утилиту, которую требует будден писать не обязательно, всю информацию можно получить существующими средствами. Но, конечно, если ты хочешь на этом подзаработать, то я не хочу тебе мешать и заткнусь. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2013, 20:29:40 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovК тому, что утилиту, которую требует будден писать не обязательно, всю информацию можно получить существующими средствамиЭто слишком оптимистично Dimitry SibiryakovНо, конечно, если ты хочешь на этом подзаработатьТо я бы так и сказал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2013, 21:57:01 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
hvlad, > Физический в табличном пространстве Неужели обычному клиенту эта информация недоступна? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2013, 11:34:14 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
buddenhvlad, > Физический в табличном пространстве Неужели обычному клиенту эта информация недоступна?Ничё не понял. Какому клиенту ? Какая информация ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2013, 12:22:17 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
hvlad, имелся в виду обычный сервер. Т.е., fb_inet_server в случае классика. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2013, 15:30:21 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
budden, почему я должен за тебя додумывать детали вопроса ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2013, 15:49:31 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
Предполагаю, что fb_inet_server (или отладчику при отладке fb_inet_server), в принципе, доступна информация о соответствии между физическим адресом страницы в эээ... табличном пространстве и тем, какому объекту принадлежит эта страница. Т.е., в gdb, отлаживая сервер и имея на руках данные из таблицы блокировок, наверняка в REPL можно вызвать функцию "считать заголовок страницы по физическому адресу" и тем самым получить нужную информацию об имени объекта (если она ещё не устарела). Конечно, это - лишь моя гипотеза. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2013, 15:45:34 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
budden, гипотеза совершенно не верная. Например, блокировка страницы запрашивается до того, как сама страница читается с диска и помещается в кеш. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2013, 16:43:58 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
hvlad, в общем, я понял: дело ясное, что дело тёмное. Ладно, будем мучиться покудова. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 15:55:24 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
budden, если бы дело было ясное, тебе уже давно так бы и сказали :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 16:34:56 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
hvlad, спасибо за внимание и звиняйте за безпокойство :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 21:04:29 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
Подниму-ка топег... Что такое "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% каждые три-пять минут. Откудова он тут, рост мьютекса ? И за какой промежуток времени считается этот процент, от начала работы с базой самого первого аттача ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2013, 23:42:08 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
Таблоид, mutex wait - это просто acquire blocks / acquires * 100%. Считается от момента инициализации лок-таблицы (первого коннекта к базе), fb_lock_print в ФБ3 выводит это время. Со временем запросто может расти по мере того, как уходят другие задержки и лок-таблица становится более нагружена - например в результате заполнения кеша ФБ или кеша файловой системы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2013, 09:25:32 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
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. Код: plaintext И если это эпический бред и "надо мерять" именно так, как сейчас, то прошу обосновать, почему именно %-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2013, 12:52:08 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
ТаблоидТо есть, если есть два замера fb_lock_print ничего не знает о твоем предыдущем замере ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2013, 12:55:33 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
dimitr, дык я к тому и говорю: пусть он сам делает два замера, с интервалом, который я ему скажу (default = 1sec). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2013, 13:03:15 |
|
||
|
Понимание результатов fb_lock_print
|
|||
|---|---|---|---|
|
#18+
Таблоид, fb_lock_print -i и обзамеряйся по самое нехочу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2013, 13:14:17 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=38204890&tid=1564097]: |
0ms |
get settings: |
7ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
177ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
42ms |
get tp. blocked users: |
1ms |
| others: | 185ms |
| total: | 439ms |

| 0 / 0 |
