Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3 4 5 6 7 8 9      [все]
 fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Появилось еще несколько вопросов по юзанию fbtracemgr. Они не связаны друг с другом и какие-то "мелкие", частично это wishlist. Нет смысла на каждый заводить отдельный топег, поэтому пусть будут сгруппированы в одном месте.

1. При последовательных запусках под win-2000 каждая новая сессия получает номер, на единицу больше предыдущей (завершённой по ctrl-C):
+
C:\1INSTALL\FIREBIRD\FB_2_5\bin>fbtracemgr -se localhost:service_mgr -start -config ..\fbtrace_probe01.conf
Trace session ID 1 started

C:\1INSTALL\FIREBIRD\FB_2_5\bin>fbtracemgr -se localhost:service_mgr -start -config ..\fbtrace_probe01.conf
Trace session ID 2 started

C:\1INSTALL\FIREBIRD\FB_2_5\bin>fbtracemgr -se localhost:service_mgr -start -config ..\fbtrace_probe01.conf
Trace session ID 3 started
В тоже время в линухе номер будет на единицу больше только в случае, если к базе есть коннект. Если коннектов нет, то новая сессия на линухе получает снова номер = 1. Это так и было задумано ?

2. Можно ли добавить параметр в conf, заставляющий трейс писать сообщения в лог и формирующий имя этого лога автоматически (например, по принципу database_name.session_ID.yyyymmdd_hh_mi_ss) ?

3. Если включены log_statement_finish true и print_perf true, то по каким принципам выводятся в статистику системные таблицы (помимо тех, что задействованы в самом DML) ?
Например, есть таблица с двумя записями:
recreate table tmpfixed(id int, f01 int) 
Выполняю ISQL-коннект, далее делаю два раза подряд
select * from tmpfixed;
Вижу в консоли fbtracemgr:
* для первого селекта:

Statement 596:
------------------------------------------------------
select * from tmpfixed
2 records fetched
0 ms, 15 fetch(es)

Table Natural Index
RDB$CHARACTER_SETS 1

RDB$COLLATIONS 1


TMPFIXED 2

* для второго селекта:
Statement 598:
----------------------------------------------------
select * from tmpfixed
2 records fetched
0 ms, 7 fetch(es)

Table Natural Index
TMPFIXED 2

PS. Получено при следующем содержимом трейс_конфига:
<database %[\\/](employee|idx_under_load_test).FDB>
enabled true
max_log_size 1
log_transactions true
log_statement_finish true
print_perf true
time_threshold 0
</database>

4. При включенном log_transactions в лог трейса попадут ВСЕ старты и завершения транзакций, в том числе и read only read committed. Можно ли добавить параметр, по которому будут отслеживаться только rollback'и (да и то не всех трн, а лишь тех, что длились свыше указанного в настройках порога, a`la time_threshold для продолжительности стейтментов) ?

5. Можно ли НЕ логгировать все DML к GTT, но логгировать к fixed-таблицам ?

6. Можно ли добавить bool-параметр, при котором в случае переполнения вместо создания новых логов будет просто обнуляться и заполняться заново текущий (он же и единственный) лог ?
24 мар 11, 00:19    [10416513]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 57224

Таблоид> Это так и было задумано ?

По идее нет, но ничем нехорошим это не грозит.

Таблоид> 2. Можно ли добавить параметр в conf, заставляющий трейс писать
Таблоид> сообщения в лог и формирующий имя этого лога автоматически

Лично я не понял. Это уже есть сейчас и для аудита,
и для трассировки - можно как самостоятельно
(через сервисы) писать в файл, так и просто
перенаправить вывод консоли в файл (твой случай).

Или ты что-то другое хочешь?

Таблоид> 5. Можно ли НЕ логгировать все DML к GTT, но логгировать к fixed-таблицам ?

Юзай инклуд фильтр. Желать фильтр на тип таблиц
(кто-то отдельно внешние таблицы захочет обязательно,
кому-то вьюхи отдельно понадобятся и т.д.) глупо,
ибо фильтр пишется один раз, руки не отсохнут. Да и
сама необходимость log_temporary_tables неочевидна.

Таблоид> 6. Можно ли добавить bool-параметр, при котором
Таблоид> в случае переполнения вместо создания новых логов
Таблоид> будет просто обнуляться и заполняться заново текущий
Таблоид> (он же и единственный) лог ?

А это вообще смешно, ей Богу. Расстреляют же ведь и за дело.
Тебе место на диске жалко или в чем проблема? :-)

Posted via ActualForum NNTP Server 1.4

24 мар 11, 01:11    [10416568]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
1. При последовательных запусках под win-2000 каждая новая сессия получает номер, на единицу больше предыдущей (завершённой по ctrl-C):
...
В тоже время в линухе номер будет на единицу больше только в случае, если к базе есть коннект. Если коннектов нет, то новая сессия на линухе получает снова номер = 1. Это так и было задумано ?
Ты не внимателен. На линуксе у тебя CS и кроме тебя нет других коннектов.
А на win-2000 или не CS, или есть другие коннекты во время твоих экспериментов.

Нумерация трейс сессий начинается заново тогда, когда "стартует сервер".
Для SS\SC "старт сервера" это первый коннект после запуска процесса, "стоп сервера" - это завершение процесса.
Для CS нет единого процесса, поэтому "старт сервера" == первый коннект, "стоп сервера" == полный дисконнект.

В любом случае, нумерация сессий не должна тебя особо волновать. Она нужна больше для оперативной работы со списком сессий администратору.

Таблоид
2. Можно ли добавить параметр в conf, заставляющий трейс писать сообщения в лог и формирующий имя этого лога автоматически (например, по принципу database_name.session_ID.yyyymmdd_hh_mi_ss) ?
Такой параметр уже есть. Для аудита.
Если ты хочешь его для пользовательского трейса, то учти, что конфигурацию интерпретирует только трейс-плагин и сам ответь почему не возможно задавать имя файла лога на клиенте в конфигурации трейса.

Таблоид
3. Если включены log_statement_finish true и print_perf true, то по каким принципам выводятся в статистику системные таблицы (помимо тех, что задействованы в самом DML) ?
По простым. Что было задействованно при выполнении запроса, то и выводится.

Таблоид
4. При включенном log_transactions в лог трейса попадут ВСЕ старты и завершения транзакций, в том числе и read only read committed. Можно ли добавить параметр, по которому будут отслеживаться только rollback'и (да и то не всех трн, а лишь тех, что длились свыше указанного в настройках порога, a`la time_threshold для продолжительности стейтментов) ?
В принципе - можно.

Таблоид
5. Можно ли НЕ логгировать все DML к GTT, но логгировать к fixed-таблицам ?
Про фильтры тебе уже сказали.

Таблоид
6. Можно ли добавить bool-параметр, при котором в случае переполнения вместо создания новых логов будет просто обнуляться и заполняться заново текущий (он же и единственный) лог ?
См. ответ на вопрос 2 и сам скажи, почему этот вопрос бессмысленен.
24 мар 11, 02:01    [10416601]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Еще пожелание. Можно ли заменить двойные переводы строк в логе трейса одинарными CR/LF, а также убрать отчеркивающие линии (звездочки, черточки) ?
26 мар 11, 16:08    [10427434]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Пример статистики в fbtrace:
select count(*) from zzz$tmp
1 records fetched
1692 ms, 20429 read(s), 874 write(s), 2040838 fetch(es)

По сравнению с ISQL, не хватает инфы по buffers. Нельзя ли добавить, чтобы не вспоминать это через gstat -h или fb.conf ?

Кроме того, в одном из тестов было выявлено заметное (30%!) влияние FileSystemCacheThreshold на время выполнения "тяжелого запроса". Это был тот самый тест на сравнение скорости джойна трёх таблиц в ФБ и в m$ sql, который тут недавно обсуждался. Можно ли FileSystemCacheThreshold тоже выводить в трейсе ?
26 мар 11, 20:25    [10428074]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид,

autoexec.bat не нужно выводить в трейсе ?
26 мар 11, 20:36    [10428106]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad,

зачем тогда в ISQL стали выводить buffers ? не выводили бы вообще - не было бы вопроса.
Хочется удобный вывод, чтобы всё было видно сразу, без лишних телодвижений.
26 мар 11, 20:52    [10428148]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 57224

Таблоид> Хочется удобный вывод, чтобы всё было видно сразу, без лишних телодвижений.

Фигней не майся. В трейс нужно выводить то, что имеет прямое отношение к самому событию.
Параметры конфига, как ты сам можешь догадаться, к нему отношения не имеют.

Posted via ActualForum NNTP Server 1.4

26 мар 11, 21:41    [10428260]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Еще вопрос + пожелание.

1) есть некая база (допустим, 192.168.0.1:/var/db/firebird/my_prod.fdb). есть также алиас к этой базе (у него имя = my_prod). Львиная доля ярлыков на рабочих местах усеров настроена так, что обращение к этой базе идет через алиас, т.е. "192.168.0.1:my_prod". Разработчики же стучатся к ней методом явного указания пути и файла.
Так вот: надо указать в трейс-конфиге, чтобы при старте польз. сессии он отлавливал обращения как к файлу, так и к алиасу.
Попробовал так:
<database %[\\/](my_prod.fdb|my_prod)>
    enabled true
    log_connections true
    log_transactions true
...
</database>
- не получается, обращения к базе через алиас НЕ отлавливаются.
Пробовал еще вот так:
<database %[\\/]my_prod[.fdb]%>
...
- не перехватывается вообще ничего.

ВОПРОС. Как правильно указывать (перечислять) в секции <database> имя файла и его алиаса ?

2) идёт сессия, вывод направлен на экран. Часто желательно очистить экран, чтобы легче было отследить начало некоего "важного события", без выхода из трейса и выполнения cls с повторным запуском. Можно ли добавить некий "хоткей" для этого ?
30 мар 11, 01:16    [10442920]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Таблоид
4. При включенном log_transactions в лог трейса попадут ВСЕ старты и завершения транзакций, в том числе и read only read committed. Можно ли добавить параметр, по которому будут отслеживаться только rollback'и (да и то не всех трн, а лишь тех, что длились свыше указанного в настройках порога, a`la time_threshold для продолжительности стейтментов) ?
Алаверды к этому пункту (см стартовый пост). Можно ли фильтровать транзакции еще и по уровням изолированности и типам ? (к примеру, exclude read only read committed или include read write concurrency).
+
Открыл только что трейс нашего продакшена, установив временно дефолтную database-секцию в .conf'e, и вижу "нечто": каждую секунду от аттачей (с невыключенных компов) создается и коммитится по 2-3 транзакции, все они read only read committed. Что это такое, еще буду выяснять. Но поскольку они не влияют на OIT - зачем они мне в логе ?
30 мар 11, 01:24    [10442927]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
ВОПРОС. Как правильно указывать (перечислять) в секции <database> имя файла и его алиаса ?
Проверяй свой шаблон, используя SIMILAR TO
30 мар 11, 02:55    [10442983]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
Можно ли добавить некий "хоткей" для этого ?
Нет.
fbtracemgr - тупая консольная утилита ибо таковой задумана и останется.
Хотите сервиса - пользуйтесь другими утилитами. В том же ИБЕ есть базовая поддержка трассировки.
30 мар 11, 02:57    [10442984]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad,

еще вопрос (может, он и не по fbtracemgr, не знаю).
Начинаю отслеживать что-то с выводом лога в файл, работа идёт под win-2000.
Файл просматриваю в третьем окне.
Вижу, что содержимое файла "отстаёт" от того, что реально должно быть, примерно на 3...4 Кб.
Например, после завершения вот этих команд:
isql -n idx_under_test.fdb
Database: IDX_UNDER_LOAD_TEST.FDB
SQL> select 1 from rdb$database;

CONSTANT
============
1

SQL> commit;
SQL> recreate global temporary table tmp$xxx(id int); commit;
SQL> insert into tmp$xxx values(1); commit;
SQL> exit;
- в файле окажется далеко не всё. Остальное сбросится на диск только при закрытии сессии.
Вот "хвост" того, что вижу в логе:
+
-------------------------------------------------------------------------------

recreate global temporary table tmp$xxx(id int)

0 records fetched

0 ms



2011-03-30T09:01:21.4680 (428:01FDC274) COMMIT_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\IDX_TEST\IDX_UNDER_LOAD_TEST.FDB (ATT_121, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1380

(TRA_2341, CONCURRENCY | WAIT | READ_WRITE)

193 ms, 7 read(s), 26 write(s), 193 fetch(es), 21 mark(s)



2011-03-30T09:01:40.2650 (428:01FDC274) START_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\IDX_TEST\IDX_UNDER_LOAD_TEST.FDB (ATT_121, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1380

(TRA_2342, CONCURRENCY | WAIT | READ_WRITE)



2011-03-30T09:01:40.2650 (428:01FDC274) EXECUTE_STATEMENT_START

C:\1INSTALL\FIREBIRD\DATA\IDX_TEST\IDX_UNDER_LOAD_TEST.FDB (ATT_121, SYSDBA:NONE,
А вот что оказалось возможным увидеть только после завершения сессии:
+
Statement 116:

-------------------------------------------------------------------------------

insert into tmp$xxx values(1)



2011-03-30T09:01:40.2960 (428:01FDC274) EXECUTE_STATEMENT_FINISH

C:\1INSTALL\FIREBIRD\DATA\IDX_TEST\IDX_UNDER_LOAD_TEST.FDB (ATT_121, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1380

(TRA_2342, CONCURRENCY | WAIT | READ_WRITE)



Statement 116:

-------------------------------------------------------------------------------

insert into tmp$xxx values(1)

0 records fetched

24 ms, 3 write(s), 16 fetch(es), 13 mark(s)



Table Natural Index Update Insert Delete Backout Purge Expunge

***************************************************************************************************************

TMP$XXX 1



2011-03-30T09:01:40.3430 (428:01FDC274) COMMIT_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\IDX_TEST\IDX_UNDER_LOAD_TEST.FDB (ATT_121, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1380

(TRA_2342, CONCURRENCY | WAIT | READ_WRITE)

52 ms, 1 read(s), 5 write(s), 1 fetch(es), 1 mark(s)



2011-03-30T09:01:43.3590 (428:01FDC274) DETACH_DATABASE

C:\1INSTALL\FIREBIRD\DATA\IDX_TEST\IDX_UNDER_LOAD_TEST.FDB (ATT_121, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1380



2011-03-30T09:01:43.3590 (428:01FDC274) TRACE_FINI

SESSION_1

ВОПРОС-1. Как сделать, чтобы лог сразу сбрасывался на диск ? Если в реестре винды надо что-то подкрутить, то в где ?
ВОПРОС-2. Возможен ли "параллельный" вывод сообщений на консоль и в файл ?
30 мар 11, 09:09    [10443227]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
ВОПРОС-1. Как сделать, чтобы лог сразу сбрасывался на диск ? Если в реестре винды надо что-то подкрутить, то в где ?
CORE-3324
Таблоид
ВОПРОС-2. Возможен ли "параллельный" вывод сообщений на консоль и в файл ?
У нас вроде нет утилит с таким функционалом ? В принципе - возможно, но сейчас точно не до того.
30 мар 11, 11:38    [10444164]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 43636

hvlad
У нас вроде нет утилит с таким функционалом ? В принципе - возможно, но сейчас точно не до
того.

А что, обязательно должны быть "наши" аналоги всех стандартных утилит? Для тех идиотов,
которые неспособны воспользоваться tee/WinTee?..

Posted via ActualForum NNTP Server 1.4

30 мар 11, 11:47    [10444247]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
LI-V6.3.0.26084 Firebird 2.5, Classic.

Есть в firebird.conf такой параметр: MaxUserTraceLogSize, default = 10 Mb.
В комментариях указано, что при превышении логом этого размера трейс будет приостановлен до "прочтения интерактивным сервисом пользователя и удаления некоторых лог-файлов".
Я его установил равным 1, после чего включил трейс.
Лог быстро достиг размера 1 Мб и прёт дальше, никакой остановки нет.

2 hvlad: можно ли всё-таки подправить трейс, чтобы он по достижении пользовательским логом размера, который указан в MaxUserTraceLogSize, не останавливался, а переименовывал добавлением суффикса в формате yyyymmdd_hhmmss, после чего открывал новый файл и возобновлял в него запись новых данных ?

PS. Объясню причину этой паранойи: мне нужно найти sql-операторы, которые выполнялись в OIT. У нас какая-то странная картина: то по 5-10 дней OAT-OIT=1, то вдруг совершенно дикие разницы по полтора-два миллиона, с утра и до ночного пылесоса.
Причем, "набор высоты" происходит за каких-то 1-2 часа. Откуда могут у нас быть по 400-500 транзакций в СЕКУНДУ - пока не ведаю. Разработчики божатся, что никакие пакетные операции не выдают транзакции с такой частотой.
Чтобы найти эти операторы, надо логгировать долго и много. Чтобы не загадить диск, хочу добавить в крон задание на упаковку "суффиксных логов" и отправку их мне в почту, с последующим удалением. Как только увижу "дикий зазор", буду поднимать архивы логов.
1 апр 11, 00:05    [10454570]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
LI-V6.3.0.26084 Firebird 2.5, Classic.

Есть в firebird.conf такой параметр: MaxUserTraceLogSize, default = 10 Mb.
В комментариях указано, что при превышении логом этого размера трейс будет приостановлен до "прочтения интерактивным сервисом пользователя и удаления некоторых лог-файлов".
Я его установил равным 1, после чего включил трейс.
Лог быстро достиг размера 1 Мб и прёт дальше, никакой остановки нет.
Это касается временных файлов, создаваемых сервером для ещё не прочитанной юзером инф-ции.
Никакого отношения к файлам на клиенте оно не имеет.

Таблоид
2 hvlad: можно ли всё-таки подправить трейс, чтобы он по достижении пользовательским логом размера, который указан в MaxUserTraceLogSize, не останавливался, а переименовывал добавлением суффикса в формате yyyymmdd_hhmmss, после чего открывал новый файл и возобновлял в него запись новых данных ?
Нет.

Таблоид
PS. Объясню причину этой паранойи: мне нужно найти sql-операторы, которые выполнялись в OIT. У нас какая-то странная картина: то по 5-10 дней OAT-OIT=1, то вдруг совершенно дикие разницы по полтора-два миллиона, с утра и до ночного пылесоса.
Это у тебя OAT застрял и стоит на месте. Next в это время движется вперёд.

Таблоид
Причем, "набор высоты" происходит за каких-то 1-2 часа. Откуда могут у нас быть по 400-500 транзакций в СЕКУНДУ - пока не ведаю. Разработчики божатся, что никакие пакетные операции не выдают транзакции с такой частотой.
Чтобы найти эти операторы, надо логгировать долго и много.
А потом OAT таки завершается и её новое значение становится намного больше застрявшего OIT.

Таблоид
Чтобы не загадить диск, хочу добавить в крон задание на упаковку "суффиксных логов" и отправку их мне в почту, с последующим удалением. Как только увижу "дикий зазор", буду поднимать архивы логов.
Тебе нужен аудит. Он как раз имеет такие настройки.
См. log_filename и max_log_size в fbtrace.conf и AuditTraceConfigFile в firebird.conf
1 апр 11, 00:16    [10454586]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
Тебе нужен аудит. Он как раз имеет такие настройки.
См. log_filename и max_log_size в fbtrace.conf и AuditTraceConfigFile в firebird.conf
А вот в релнотах сказано:
FB 2.5 RN
Administrator creates or edits the trace configuration file, sets its name via the AuditTraceConfigFile setting in firebird.conf and restarts Firebird. Later, the administrator could suspend, resume or stop this session without needing to restart Firebird.
правильно ли понимаю, что для случая CLASSIC server'a достаточно просто выгнать всех усеров из проги, т.е. просто сделать gfix -shut и затем -online &
1 апр 11, 00:32    [10454606]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
правильно ли понимаю, что для случая CLASSIC server'a достаточно просто выгнать всех усеров из проги
Да.
1 апр 11, 00:34    [10454611]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Операторы, выполняемые внутри автономных транзакций, в логе трейса не показываются:
DDL:
+
set term ^;
execute block as
  declare ddl varchar(32760);
  declare n int = 100;
  declare i int;
begin
  ddl='recreate table wide(';
  while (n>0) do begin
    ddl = ddl || 'f'||n||' int default 0' || iif(n>1, ',', ');');
    n=n-1;
  end
  execute statement :ddl;
end^
set term ;^
commit;
EB:
rollback;
set transaction read write read committed;
set term ^;
execute block as
declare k int = 3;
begin
  while (k>0) do begin
     in autonomous transaction do begin
        insert into wide default values;
        delete from wide;
     end
     k=k-1;
  end
end^
set term ;^
rollback;
Trace log:
+
2011-04-08T23:37:59.5150 (428:020DB9D0) TRACE_INIT
SESSION_1 Firebird Audit


2011-04-08T23:37:59.5150 (428:020DB9D0) ATTACH_DATABASE
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204

2011-04-08T23:37:59.5150 (428:020DB9D0) START_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34226, CONCURRENCY | WAIT | READ_WRITE)

2011-04-08T23:38:02.8590 (428:020DB9D0) ROLLBACK_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34226, CONCURRENCY | WAIT | READ_WRITE)
0 ms, 1 read(s), 1 write(s), 1 fetch(es), 1 mark(s)

2011-04-08T23:38:02.8590 (428:020DB9D0) START_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34227, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)

2011-04-08T23:38:02.8590 (428:020DB9D0) START_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34228, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)

2011-04-08T23:38:02.8590 (428:020DB9D0) COMMIT_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34228, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)
0 ms, 1 read(s), 2 write(s), 1 fetch(es), 1 mark(s)

2011-04-08T23:38:02.8590 (428:020DB9D0) START_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34229, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)

2011-04-08T23:38:02.8590 (428:020DB9D0) COMMIT_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34229, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)
0 ms, 1 read(s), 2 write(s), 1 fetch(es), 1 mark(s)

2011-04-08T23:38:02.8590 (428:020DB9D0) START_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34230, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)

2011-04-08T23:38:02.8590 (428:020DB9D0) COMMIT_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34230, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)
0 ms, 1 read(s), 2 write(s), 1 fetch(es), 1 mark(s)

2011-04-08T23:38:02.8590 (428:020DB9D0) EXECUTE_STATEMENT_FINISH
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34227, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)

Statement 35:
-------------------------------------------------------------------------------
execute block as
declare k int = 3;
begin
while (k>0) do begin
in autonomous transaction do begin
insert into wide default values;
delete from wide;
end
k=k-1;
end
end
0 records fetched
0 ms, 4 read(s), 3 write(s), 60 fetch(es), 13 mark(s)

Table Natural Index Update Insert Delete Backout Purge Expunge
***************************************************************************************************************
WIDE 3 3 3 2

2011-04-08T23:38:02.8590 (428:020DB9D0) ROLLBACK_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34227, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)
0 ms, 1 read(s), 1 write(s), 1 fetch(es), 1 mark(s)
(видно, что после старта основной трн стартуют и тут же коммитятся автономки; текста и данных по производительности выполняемых внутри них операторов не видно).
8 апр 11, 23:39    [10494307]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
Операторы, выполняемые внутри автономных транзакций, в логе трейса не показываются
Ну так и отдельные операторы внутри процедуры\триггера тоже не показываются
9 апр 11, 01:13    [10494648]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
LI-V6.3.0.26083 (Classic)

Из таблицы, содержащей 100 млн строк и 5 индексов (один ПК и 4 составных по 4 int-полям) выполняю удаление 1 млн строк.
Подключен пользовательский трейс, вывод перенаправлен в лог.
Удаление идёт больше минуты, при этом ВСЁ это время вижу в top'e, что fbtracemgr ощутимо грузит проц:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29299 firebird 20 0 128m 6772 4576 S 46.5 0.0 0:51.11 fbtracemgr
29308 firebird 20 0 104m 45m 5352 R 38.2 0.1 0:22.75 isql

Самое интересное, что:
1) в процессе выполнения в top'e (при сортировке по CPU_load desc)в первых строках видел fbtracemgr и isql - "моего" fb_inet_server'a там даже не показалось;
2) эта же загрузка (примерно 45-47%) не прекратилась и после того, как оператор удаления выполнился и в ISQL управление вернулось к подсказке.

Это почему так ?
PS. Содержимое конфига трейса:
+
[firebird@firebirdG ~]$ cat fbtrace_probe01.conf
<database %[\\/]test.fdb>
enabled true
#log_filename ./test_trace.log
max_log_size 10
log_connections true
log_transactions true
#include_filter %(SELECT|INSERT|UPDATE|DELETE|MERGE)%
#exclude_filter
#connection_id 12345
#log_statement_prepare true
#log_statement_free true
#log_statement_start true
log_statement_finish true
print_plan true
print_perf true
# max_sql_length 500
time_threshold 0
</database>
12 апр 11, 21:07    [10508898]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
PS. Забыл указать полный список процессов от user = 'firebird', которые вижу в top'e при работе трейса и "долгом запросе" к большой таблице:
+
top - 21:08:56 up 20 days,  8:57,  8 users,  load average: 2.61, 2.15, 1.70
Tasks: 269 total, 4 running, 265 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.3%us, 1.0%sy, 0.0%ni, 78.2%id, 17.2%wa, 0.0%hi, 3.3%si, 0.0%st
Cpu1 : 1.0%us, 2.6%sy, 0.0%ni, 18.6%id, 77.8%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu4 : 12.5%us, 48.9%sy, 0.0%ni, 34.6%id, 0.0%wa, 0.0%hi, 3.9%si, 0.0%st
Cpu5 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu6 : 3.3%us, 3.3%sy, 0.0%ni, 92.6%id, 0.3%wa, 0.0%hi, 0.3%si, 0.0%st
Cpu7 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 49548000k total, 32727144k used, 16820856k free, 24324k buffers
Swap: 51367828k total, 20k used, 51367808k free, 29828832k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29299 firebird 20 0 128m 6772 4576 S 47.2 0.0 5:20.06 fbtracemgr
29308 firebird 20 0 73940 14m 5532 R 3.7 0.0 0:30.03 isql
3623 firebird 20 0 97484 2056 1204 S 0.0 0.0 0:23.88 sshd
3624 firebird 20 0 105m 1844 1400 S 0.0 0.0 0:00.01 bash
3651 firebird 20 0 115m 2904 1884 S 0.0 0.0 0:15.52 mc
3653 firebird 20 0 105m 1868 1404 S 0.0 0.0 0:00.01 bash
8636 firebird 20 0 97484 2060 1204 S 0.0 0.0 0:03.77 sshd
8637 firebird 20 0 105m 1848 1400 S 0.0 0.0 0:00.00 bash
8664 firebird 20 0 115m 2756 1860 S 0.0 0.0 0:00.18 mc
8666 firebird 20 0 105m 1860 1404 S 0.0 0.0 0:00.03 bash
22612 firebird 20 0 97444 2116 1284 S 0.0 0.0 0:00.15 sshd
22613 firebird 20 0 105m 1840 1400 S 0.0 0.0 0:00.00 bash
22640 firebird 20 0 115m 3416 1936 S 0.0 0.0 0:00.10 mc
22642 firebird 20 0 105m 1856 1400 S 0.0 0.0 0:00.00 bash
25702 firebird 20 0 97484 2148 1288 S 0.0 0.0 0:00.21 sshd
25703 firebird 20 0 105m 1840 1400 S 0.0 0.0 0:00.00 bash
25730 firebird 20 0 115m 3068 2016 S 0.0 0.0 0:00.51 mc
25732 firebird 20 0 105m 1860 1404 S 0.0 0.0 0:00.04 bash
25793 firebird 20 0 97484 2148 1288 S 0.0 0.0 0:00.12 sshd
25794 firebird 20 0 105m 1848 1400 S 0.0 0.0 0:00.00 bash
25821 firebird 20 0 115m 3052 2020 S 0.0 0.0 0:00.45 mc
25823 firebird 20 0 105m 1860 1404 S 0.0 0.0 0:00.04 bash
29249 firebird 20 0 135m 10m 5348 S 0.0 0.0 0:06.67 fb_inet_server
29317 firebird 20 0 15076 1340 912 R 0.0 0.0 0:01.50 top
29442 firebird 20 0 97484 2020 1180 S 0.0 0.0 0:00.00 sshd
29443 firebird 20 0 105m 1844 1400 S 0.0 0.0 0:00.00 bash
29470 firebird 20 0 115m 3016 1936 S 0.0 0.0 0:00.11 mc
29472 firebird 20 0 105m 1848 1396 S 0.0 0.0 0:00.00 bash

Прошу обратить внимание на то, что fb_inet_server вообще не грузит ЦПУ и находится явно среди "аутсайдеров".
12 апр 11, 21:13    [10508919]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
LI-V6.3.0.26083 (Classic)

Из таблицы, содержащей 100 млн строк и 5 индексов (один ПК и 4 составных по 4 int-полям) выполняю удаление 1 млн строк.
Подключен пользовательский трейс, вывод перенаправлен в лог.
Удаление идёт больше минуты, при этом ВСЁ это время вижу в top'e, что fbtracemgr ощутимо грузит проц:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29299 firebird 20 0 128m 6772 4576 S 46.5 0.0 0:51.11 fbtracemgr
29308 firebird 20 0 104m 45m 5352 R 38.2 0.1 0:22.75 isql

Самое интересное, что:
1) в процессе выполнения в top'e (при сортировке по CPU_load desc)в первых строках видел fbtracemgr и isql - "моего" fb_inet_server'a там даже не показалось;
2) эта же загрузка (примерно 45-47%) не прекратилась и после того, как оператор удаления выполнился и в ISQL управление вернулось к подсказке.
а) В логе трейса только искомое удаление оказалось или куча параллельной активности от других коннектов тоже ?
б) коннект в isql небось локальный ?
12 апр 11, 21:29    [10508982]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
а) В логе трейса только искомое удаление оказалось или куча параллельной активности от других коннектов тоже ?
б) коннект в isql небось локальный ?
a) только аттач + каунт строк в ИБЭ (т.е. еще всего лишь 1 коннект, который сделал предварительный подсчет числа удаляемых строк).
б) да, локальный... а что? :-)
12 апр 11, 21:34    [10508997]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Дело в том, что мусор не могу теперь собрать... :-)
Вот:
+
[firebird@firebirdG firebird]$ isql -n test.fdb
Database: test.fdb
SQL> set stat on;
SQL> delete from tmp where f01 between 50000 and 51000; -- это удалился 1 млн строк из начальных 100 млн
Current memory = 22614088
Delta memory = 17956624
Max memory = 36252496
Elapsed time= 74.39 sec
Cpu = 0.00 sec
Buffers = 512
Reads = 577475
Writes = 573763
Fetches = 5000966
SQL> commit;
Current memory = 4796048
Delta memory = -17818040
Max memory = 36252496
Elapsed time= 0.04 sec
Cpu = 0.00 sec
Buffers = 512
Reads = 1
Writes = 506
Fetches = 1
SQL> select count(*) from tmp;
- висит, зараза, уже минут 20, не меньше... :-( И непонятно, сервер вообще занимается моим запросом или "обслуживает" только fbtracemgr + ... isql!
12 апр 11, 21:38    [10509009]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
б) да, локальный... а что? :-)
Ну так какого fb_inet_server'а ты ждёшь ? :-)
Это линукс, тут нет локального протокола, только embedded.
12 апр 11, 21:49    [10509044]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
Таблоид
б) да, локальный... а что? :-)
Ну так какого fb_inet_server'а ты ждёшь ? :-)
Это линукс, тут нет локального протокола, только embedded.
тьфу, ёлыпалы... так я и думал, что глупость опять напорол :-)
Но вот скажи всё равно: срубил я этот самый подсчет каунтов в ISQL, выполнил дисконнект из другого окна (ИБЭ).
Теперь никаких подключений к серверу нет, а fbtracemgr всё равно грузит проц! на те же самые 45-47%.
Отчего это ?
+
top - 21:56:24 up 20 days,  9:44,  8 users,  load average: 1.50, 1.92, 1.92
Tasks: 256 total, 2 running, 254 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.7%us, 0.7%sy, 0.0%ni, 98.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.0%us, 0.3%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu4 : 11.9%us, 37.9%sy, 0.0%ni, 46.3%id, 0.0%wa, 0.0%hi, 3.9%si, 0.0%st
Cpu5 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu6 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu7 : 5.7%us, 10.5%sy, 0.0%ni, 82.8%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st
Mem: 49548000k total, 35035632k used, 14512368k free, 31180k buffers
Swap: 51367828k total, 20k used, 51367808k free, 32223148k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29299 firebird 20 0 128m 6776 4580 S 47.1 0.0 27:35.81 fbtracemgr
29317 firebird 20 0 15076 1340 912 R 0.3 0.0 0:09.52 top
3623 firebird 20 0 97484 2056 1204 S 0.0 0.0 0:23.92 sshd
3624 firebird 20 0 105m 1844 1400 S 0.0 0.0 0:00.01 bash
3651 firebird 20 0 115m 2904 1884 S 0.0 0.0 0:15.52 mc
3653 firebird 20 0 105m 1868 1404 S 0.0 0.0 0:00.01 bash
8636 firebird 20 0 97484 2060 1204 S 0.0 0.0 0:03.79 sshd
8637 firebird 20 0 105m 1848 1400 S 0.0 0.0 0:00.00 bash
8664 firebird 20 0 115m 2756 1860 S 0.0 0.0 0:00.18 mc
8666 firebird 20 0 105m 1860 1404 S 0.0 0.0 0:00.03 bash
22612 firebird 20 0 97444 2116 1284 S 0.0 0.0 0:00.18 sshd
22613 firebird 20 0 105m 1840 1400 S 0.0 0.0 0:00.00 bash
22640 firebird 20 0 115m 3416 1936 S 0.0 0.0 0:00.10 mc
22642 firebird 20 0 105m 1856 1400 S 0.0 0.0 0:00.00 bash
25702 firebird 20 0 97484 2148 1288 S 0.0 0.0 0:00.53 sshd
25703 firebird 20 0 105m 1840 1400 S 0.0 0.0 0:00.00 bash
25730 firebird 20 0 115m 3068 2016 S 0.0 0.0 0:00.83 mc
25732 firebird 20 0 105m 1860 1404 S 0.0 0.0 0:00.04 bash
25793 firebird 20 0 97484 2148 1288 S 0.0 0.0 0:00.15 sshd
25794 firebird 20 0 105m 1848 1400 S 0.0 0.0 0:00.00 bash
25821 firebird 20 0 115m 3052 2020 S 0.0 0.0 0:00.45 mc
25823 firebird 20 0 105m 1860 1404 S 0.0 0.0 0:00.04 bash
29308 firebird 20 0 73940 14m 5700 S 0.0 0.0 4:26.29 isql
29442 firebird 20 0 97484 2020 1180 S 0.0 0.0 0:00.00 sshd
29443 firebird 20 0 105m 1844 1400 S 0.0 0.0 0:00.00 bash
29470 firebird 20 0 115m 3088 1936 S 0.0 0.0 0:00.16 mc
29472 firebird 20 0 105m 1848 1396 S 0.0 0.0 0:00.00 bash
12 апр 11, 21:57    [10509061]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
Теперь никаких подключений к серверу нет, а fbtracemgr всё равно грузит проц! на те же самые 45-47%.
Если это не связано с запись лога в файл, то понятия не имею.
Можешь снять с него бектрейс - посмотрим
12 апр 11, 22:14    [10509142]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
Таблоид
Теперь никаких подключений к серверу нет, а fbtracemgr всё равно грузит проц! на те же самые 45-47%.
Если это не связано с запись лога в файл, то понятия не имею.
Можешь снять с него бектрейс - посмотрим
Это уже завтра только смогу.
Сейчас повторил, приконнектился через TCP - всё та же значительная загрузка от fbtracemgr и капля отведена на fb_inet_server:
+
top - 22:15:17 up 20 days, 10:03,  8 users,  load average: 2.08, 1.25, 1.36
Tasks: 258 total, 1 running, 257 sleeping, 0 stopped, 0 zombie
Cpu0 : 3.8%us, 37.4%sy, 0.0%ni, 9.3%id, 46.4%wa, 0.0%hi, 3.1%si, 0.0%st
Cpu1 : 1.4%us, 14.9%sy, 0.0%ni, 37.5%id, 45.3%wa, 0.0%hi, 1.0%si, 0.0%st
Cpu2 : 2.3%us, 3.7%sy, 0.0%ni, 93.6%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
Cpu3 : 1.1%us, 7.9%sy, 0.0%ni, 90.6%id, 0.0%wa, 0.0%hi, 0.4%si, 0.0%st
Cpu4 : 0.0%us, 0.3%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu5 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu6 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu7 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 49548000k total, 34909588k used, 14638412k free, 32220k buffers
Swap: 51367828k total, 20k used, 51367808k free, 32202440k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
30150 firebird 20 0 127m 5996 4088 S 46.5 0.0 1:32.90 fbtracemgr
30165 firebird 20 0 135m 10m 5120 S 6.0 0.0 0:36.79 fb_inet_server
12 апр 11, 22:18    [10509159]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Последняя попытка: удаляю всё тот же 1 млн строк, но трейс выключен. В топе вижу загрузку ЦПУ от fb_inet_server'a:
1) от оператора delete - только на 50-55%;.
2) от последующего за этим select count(*) from tmp - всего на 17-19%.
Это тоже непонятно: никаких других процессов сейчас на этом серваке нет, что ему мешает загрузить проц по-полной ?
Если затык при count'e из-за очереди на диск, то где он тут, покажите, плз:
+
top - 22:30:46 up 20 days, 10:19,  8 users,  load average: 0.88, 1.14, 1.41
Tasks: 259 total, 1 running, 258 sleeping, 0 stopped, 0 zombie
Cpu0 : 5.6%us, 7.3%sy, 0.0%ni, 32.8%id, 52.3%wa, 0.0%hi, 2.0%si, 0.0%st
Cpu1 : 1.9%us, 3.2%sy, 0.0%ni, 65.3%id, 29.5%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu4 : 0.0%us, 0.3%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu5 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu6 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu7 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 49548000k total, 45913316k used, 3634684k free, 34264k buffers
Swap: 51367828k total, 20k used, 51367808k free, 43136944k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
30295 firebird 20 0 135m 9320 4552 S 18.6 0.0 0:57.92 fb_inet_server
29317 firebird 20 0 15076 1340 912 R 0.7 0.0 0:15.11 top
1 root 20 0 19244 1424 1156 S 0.0 0.0 0:06.91 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root RT 0 0 0 0 S 0.0 0.0 0:00.06 migration/0
4 root 20 0 0 0 0 S 0.0 0.0 21:52.08 ksoftirqd/0
5 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
6 root RT 0 0 0 0 S 0.0 0.0 0:00.31 migration/1
7 root 20 0 0 0 0 S 0.0 0.0 5:46.92 ksoftirqd/1
8 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/1
9 root RT 0 0 0 0 S 0.0 0.0 0:00.15 migration/2
10 root 20 0 0 0 0 S 0.0 0.0 4:49.02 ksoftirqd/2
12 апр 11, 22:32    [10509212]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
miwaonline
Member

Откуда:
Сообщений: 2232
Таблоид
Если затык при count'e из-за очереди на диск, то где он тут

Прошу прощения, что вмешиваюсь, но нагрузку на диск сподручнее смотреть через iotop.
12 апр 11, 23:08    [10509388]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 6668
Таблоид,

дисковый ввод-вывод даже при пустой очереди (отсутствии конкуренции) все равно "отрубает" процессор на время операции, так что IMHO тут все нормально - сборка мусора просто сильнее грузит диск, чем удаление.
12 апр 11, 23:10    [10509404]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
miwaonline
нагрузку на диск сподручнее смотреть через iotop.
спасибо, я этого не знал; учту в след. раз.
dimitr
сборка мусора просто сильнее грузит диск, чем удаление.
оказалось неожиданным, НАСКОЛЬКО сильнее. Само удаление идёт чуть больше минуты. Каунт после него - 40 минут! Каунт "обычный", не вызывающий сборку мусора, - 45 сек.
Вот что вижу сейчас, по итогам томной ночи:
+
[fb@fbG fb]$ isql -n 192.168.1.1:/u01/db/firebird/test.fdb
Database: 192.168.1.1:/u01/db/firebird/test.fdb
SQL> set stat on;
SQL> delete from tmp where f01 between 50000 and 51000;
Current memory = 18863640
Delta memory = 17952264
Max memory = 32507816
Elapsed time= 63.64 sec
Cpu = 0.00 sec
Buffers = 75 -- ?!
Reads = 577466
Writes = 574196
Fetches = 5000892

SQL> commit;
Current memory = 1045592
Delta memory = -17818048
Max memory = 32507816
Elapsed time= 0.02 sec
Cpu = 0.00 sec
Buffers = 75
Reads = 1
Writes = 73
Fetches = 1
SQL> select count(*) from tmp;

COUNT
============
99000438

Current memory = 1059808
Delta memory = 13120
Max memory = 32507816
Elapsed time= 2369.86 sec
Cpu = 0.00 sec
Buffers = 75
Reads = 10141603
Writes = 5660541
Fetches = 235789600

SQL> select count(*) from tmp;

COUNT
============
99000438

Current memory = 1059808
Delta memory = 0
Max memory = 32507816
Elapsed time= 45.69 sec
Cpu = 0.00 sec
Buffers = 75
Reads = 807294
Writes = 32
Fetches = 199614623

2 hvlad, dimitr: и еще две странности.
1) Статистика (в спойлере) показывает, что буферов у меня 75. Базу создавал без явного указания числа буферов, в firebird.conf'e давно уже установлено 512. Откуда ISQL берёт значение buffers=75 ?!
2) поменял число буферов в заголовке базы (gfix -buffers 512). Подсчет числа строк на исходной таблице (100 млн), к сож-ю, остался практически таким же, как и при buf=75: 43 сек. Размер страницы = 8К, памяти на сервере навалом. Хорошо помню, что раньше увеличение числа буферов влияло гораздо сильнее, и на чтение и на запись.

ЗЫ. LI-V2.5.0.26083
13 апр 11, 09:01    [10510110]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
оказалось неожиданным, НАСКОЛЬКО сильнее. Само удаление идёт чуть больше минуты. Каунт после него - 40 минут! Каунт "обычный", не вызывающий сборку мусора, - 45 сек.
- удаление не трогает индексы
- сборка мусора - чистит и данные, и индексы
- 5 индексов приводят к random IO
- кеш в 75 буферов постоянно вытесняется и одно и то же заново читается и пишется
- чтения амортизируются файловым кешем, а вот записи - нет, ибо FW
13 апр 11, 10:41    [10510620]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Проблема решена.
Рулят три вещи: 1) buffers = 512; 2) FW = OFF и 3) FileSystemCacheThreshold = 65536
При установленном числе буферов = 512 сделал еще три замера.

1. FW = ON, FileSystemCacheThreshold=disabled:
SQL> delete from tmp where f01 between 50000 and 51000; commit;
Elapsed time= 82.95 sec
SQL> select count(*) from tmp;
Срубил, ждал более 15 минут

2. FW = OFF, FileSystemCacheThreshold=disabled:
SQL> delete from tmp where f01 between 50000 and 51000; commit;
Elapsed time= 24.39 sec
SQL> select count(*) from tmp;
Elapsed time= 447.00 sec

3. FW = OFF, FileSystemCacheThreshold=65536:
SQL> delete from tmp where f01 between 50000 and 51000;
Elapsed time= 10.32 sec

SQL> select count(*) from tmp;
Elapsed time= 181.58 sec // при "обычном" count'e время = 37.97 sec

Напомню: удаление 1 млн строк из таблицы, содержащей 100 млн.
Скрипт создания таблицы:
+
recreate table tmp(id int not null,f01 int,f02 int,f03 int,f04 int);
execute block as begin
execute statement 'drop sequence gen_test;'; when any do begin end
end;
create sequence gen_test;
commit;
execute block as
declare n int = 100000000;
begin
  while (n>0) do
    insert into tmp(id,f01,f02,f03,f04)
    values (:n+iif( mod(:n,1000)=0, gen_id(gen_test,1000), 0)*0, rand()*100000, rand()*100000, rand()*100000, rand()*100000)
    returning :n-1 into :n;
end;
commit;
alter table tmp add constraint tmp_pk primary key (id);
-- 15 min:
create index tmp_idx1 on tmp(f01,f02,f03,f04);
create index tmp_idx2 on tmp(f02,f03,f04,f01);
create index tmp_idx3 on tmp(f03,f04,f01,f02);
create index tmp_idx4 on tmp(f04,f01,f02,f03);
commit;


2 dimitr, hvlad.
Так и не понимаю:
1) зачем по дефолту до сих пор 75. Инсталлятор надо срочно менять и проставить там хотя бы 256. А лучше 512.
2) зачем по дефолту FW = ON, если в природе давно есть HDD-контроллеры, "обманывающие" OS и пишущие не так, как мы просим, а так, как "им надо" (т.е. меняющие последовательность записей). Если некая база крутится в продакшене с FW = OFF и там никто не делает backup'ы, то при жестком обрубе сервака часть их данных ВСЁ РАВНО будет потеряна. Так чего ради этот FW по дефолту = ON ?
3) зачем вырублено кеширование средствами OS, если сам ФБ пока еще не делает упреждающего чтения и отложенной записи.

В итоге, получаем нападки типа этой. И ведь нечем опровергнуть, пока не подкрутишь штатные настройки!
13 апр 11, 11:14    [10510913]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид,

FileSystemCacheThreshold=disabled - это что ?
13 апр 11, 11:51    [10511213]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 26550
Таблоид
Инсталлятор надо срочно менять и проставить там хотя бы 256. А лучше 512.

если я правильно помню, конфиг ориентирован на суперсервер, и там прописано значение в 2048. У сервера есть умолчательные значения в кэше, если в конфиге ничего не прописано - 75 для классика и 2048 для супера. Так что, если чего и менять, то умолчательные значения в сервере (а не в конфиге).
13 апр 11, 13:49    [10512231]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
FileSystemCacheThreshold=disabled - это что ?
это когда пробовал с .conf'ом, в котором закомментирована строка с этим параметром:
#FileSystemCacheThreshold = 65536

Я понимаю, что это значение (65536) в закомментированном виде должно работать так, как и в раскомментированном. Но тогда эффект от удаления комментария был бы нулевым. А он совсем не нулевой - см выше статистику (сборка мусора уменьшилась со 447 до 181 сек).
13 апр 11, 13:51    [10512258]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
kdv
Так что, если чего и менять, то умолчательные значения в сервере (а не в конфиге).
OFF. 2 KDV. А вот вопросик имею, еще вчера хотел задать. Когда тестировалась терабайтная база, то выполнялись ли DML-действия ? (апдейты, делиты ?)
13 апр 11, 13:55    [10512312]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
hvlad
FileSystemCacheThreshold=disabled - это что ?
это когда пробовал с .conf'ом, в котором закомментирована строка с этим параметром:
#FileSystemCacheThreshold = 65536

Я понимаю, что это значение (65536) в закомментированном виде должно работать так, как и в раскомментированном.
Именно так оно и работает

Таблоид
Но тогда эффект от удаления комментария был бы нулевым. А он совсем не нулевой - см выше статистику (сборка мусора уменьшилась со 447 до 181 сек).
Где-то ты опять ошибаешься :)
13 апр 11, 14:23    [10512643]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 6668
Таблоид
Так и не понимаю:
1) зачем по дефолту до сих пор 75. Инсталлятор надо срочно менять и проставить там хотя бы 256. А лучше 512.
2) зачем по дефолту FW = ON, если в природе давно есть HDD-контроллеры, "обманывающие" OS и пишущие не так, как мы просим, а так, как "им надо" (т.е. меняющие последовательность записей). Если некая база крутится в продакшене с FW = OFF и там никто не делает backup'ы, то при жестком обрубе сервака часть их данных ВСЁ РАВНО будет потеряна. Так чего ради этот FW по дефолту = ON ?
3) зачем вырублено кеширование средствами OS, если сам ФБ пока еще не делает упреждающего чтения и отложенной записи

1) уже обсуждалось. В 3.0 увеличили.
2) не у каждого нуба есть такой хитрожопый контроллер. А дефолтная конфигурация рассчитана как раз на нубов.
3) вырублено оно лишь для очень больших кешей, чтобы избежать драки с осью за виртуалку
13 апр 11, 15:26    [10513140]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 26550
Таблоид
Когда тестировалась терабайтная база, то выполнялись ли DML-действия ? (апдейты, делиты ?)

нет. тупо налито, и все. планировали tpc-c на ней покрутить, соответственно было бы и то и другое. Но не задалось, диск с базой лежит возле компа, отключенный.
13 апр 11, 15:32    [10513183]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Ivan_Pisarevsky
Member

Откуда: НН
Сообщений: 7676
Таблоид
2) зачем по дефолту FW = ON, если в природе давно есть HDD-контроллеры, "обманывающие" OS и пишущие не так, как мы просим, а так, как "им надо" (т.е. меняющие последовательность записей). Если некая база крутится в продакшене с FW = OFF и там никто не делает backup'ы, то при жестком обрубе сервака часть их данных ВСЁ РАВНО будет потеряна. Так чего ради этот FW по дефолту = ON ?
Ты тащишь за уши железячный вопрос, для того, чтоб при отрубе питания не развалился рэйд при кэшировании записи на винты есть такое устройство в простонародье батарейка/бабуин, по науке bbu или bbwc (разные вендоры называют по разному). В общем хочешь кэшировать запись на контроллере доукомплектуй его соответствующим устройством, на фоне остальной сметы 100$ не заметно и не парь мозг SQL серверу и его разработчикам. :)
13 апр 11, 16:01    [10513440]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Поднимаю тему, т.к. сижу в ступоре: меняю в firebird.conf'e значение AuditTraceConfigFile (указываю другой файл с настройками трейса), подключаюсь к базе, выполняю запрос, отключаюсь. И вижу, что... создается по-прежнему старый лог.
Подумал, что может это вообще другой firebird.conf, поменял в нём DefaultDBCachePages на вычурное значение = 1234.
Снова подключился к FB (LI-V2.5.1.26353, classic), выполнил set stat on + select 1 from rdb$database - вижу в статистике новое значение для buffers (только что установленное 1234).
Отключил вообще AuditTraceConfigFile, но настройка не подействовала, лог трейса всё пишется.
Перезапустил xinetd - не помогло! "Кто-то" упрямо пишет в лог трейса!

2 hvlad: можно ли в заголовке файла однократно писать, настройки КАКОГО trace.conf'а используются в данный момент ?
Т.е. можно ли вот тут дописать что-то типа того, что зелёным цветом:

2011-09-09T11:15:01.2770 (26477:0x7f0637436750) TRACE_INIT
SESSION_1 Firebird Audit USING SETTINGS FROM: /opt/firebird/trace_probe01.conf


2011-09-09T11:15:01.2770 (26477:0x7f0637436750) ATTACH_DATABASE
/u01/db/firebird/test5.fdb (ATT_27, SYSDBA:NONE, NONE, <internal>)

2011-09-09T11:15:01.2780 (26477:0x7f0637436750) START_TRANSACTION
/u01/db/firebird/test5.fdb (ATT_27, SYSDBA:NONE, NONE, <internal>)
(TRA_772, CONCURRENCY | WAIT | READ_WRITE)
<...>
9 сен 11, 11:34    [11252553]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
Поднимаю тему, т.к. сижу в ступоре: меняю в firebird.conf'e значение AuditTraceConfigFile (указываю другой файл с настройками трейса), подключаюсь к базе, выполняю запрос, отключаюсь. И вижу, что... создается по-прежнему старый лог.
Потому что нужен полный дисконнект.

Таблоид
Подумал, что может это вообще другой firebird.conf, поменял в нём DefaultDBCachePages на вычурное значение = 1234.
Снова подключился к FB (LI-V2.5.1.26353, classic), выполнил set stat on + select 1 from rdb$database - вижу в статистике новое значение для buffers (только что установленное 1234).
Потому что классик перечитывает конфиг при старте.

Но для существующего аудита это не работает.
Как и для пар-ров лок-менеджера, например.

Таблоид
2 hvlad: можно ли в заголовке файла однократно писать, настройки КАКОГО trace.conf'а используются в данный момент ?
Нет, потому что в самом трейсе нет никаких файлов конфига.

В принципе, можно при создании трейс-сессии аудита писать об этом в firebird.log...
9 сен 11, 12:11    [11252946]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
Таблоид
Поднимаю тему, т.к. сижу в ступоре: меняю в firebird.conf'e значение AuditTraceConfigFile (указываю другой файл с настройками трейса), подключаюсь к базе, выполняю запрос, отключаюсь. И вижу, что... создается по-прежнему старый лог.
Потому что нужен полный дисконнект.
что значит "полный дисконнект" ?! я не только отрубился от базы, но и вообще xinet рестартовал.
Неужто и этого недостаточно ?
hvlad
Таблоид
Подумал, что может это вообще другой firebird.conf, поменял в нём DefaultDBCachePages на вычурное значение = 1234.
Снова подключился к FB (LI-V2.5.1.26353, classic), выполнил set stat on + select 1 from rdb$database - вижу в статистике новое значение для buffers (только что установленное 1234).
Потому что классик перечитывает конфиг при старте.

Но для существующего аудита это не работает.
Как и для пар-ров лок-менеджера, например.
Звучит как приговор :-) Как его хотя бы вырубить-то, трейс этот ?

hvlad
Таблоид
2 hvlad: можно ли в заголовке файла однократно писать, настройки КАКОГО trace.conf'а используются в данный момент ?
Нет, потому что в самом трейсе нет никаких файлов конфига.

В принципе, можно при создании трейс-сессии аудита писать об этом в firebird.log...
Добавил просьбу: CORE-3595
9 сен 11, 12:23    [11253034]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
что значит "полный дисконнект" ?! я не только отрубился от базы
Полный - значит не должно быть ни одного процесса FB. Это что-то новое ???

Таблоид
но и вообще xinet рестартовал. Неужто и этого недостаточно ?
Ты вчера ФБ впервые увидел ? При чём тут xinetd ??? Я плакалъ :'(

Таблоид
Как его хотя бы вырубить-то, трейс этот ?
Суть аудита в том, чтобы ничего не пропускать. По уму, его должно быть невозможно вырубить. Но лазейка есть. Сам найдёшь :)

Ты мне вот что скажи - зачем ты из пушки (аудит) стреляешь по воробьям (свои частные сиюминутные задачи), когда есть личное оружие (пользовательский трейс) ???
9 сен 11, 12:29    [11253076]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
Ты мне вот что скажи - зачем ты из пушки (аудит) стреляешь по воробьям (свои частные сиюминутные задачи), когда есть личное оружие (пользовательский трейс) ???
Потому что так удобнее: не надо запускать ничего (fbtracemgr -se localhost:service_mgr -start -config /opt/firebird/fbtrace_probe01.conf ), просто подключился к тестовой базе - и вот он лог, уже готовый.
К тому же, старт пользовательского трейса выводит мессаги на консоль, а не в файл. Для логирования вывода в файл надо бубен в виде tee использовать.
И наконец, в "моём" линухе трейс надо запускать не через fbtracemgr, а с использованием fbsvcmgr - иначе его остановка по Упр-Це приводит к созданию какого-то дампа (см http://tracker.firebirdsql.org/browse/CORE-3405). Хотя Алекс и сказал, что этот тикет есть дубликат пролеченного, у меня дамп всё равно создается.
9 сен 11, 13:04    [11253358]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид,

а то ты не в IBE работаешь ?

Пользуйся инструментом по-назначению, и будет тебе счастье. Аудит не для этого.
9 сен 11, 13:07    [11253380]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
а то ты не в IBE работаешь ?
Поначалу что-то могу делать в ИБЭ, но когда надо выложить что-то сюда, то делаю это только в ISQL.
hvlad
Пользуйся инструментом по-назначению, и будет тебе счастье. Аудит не для этого.
Не понял что-то... про какой ИНСТРУМЕНТ ты говоришь ? чем лог аудита отличается от польз. трейса ?
9 сен 11, 13:12    [11253410]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
hvlad
Пользуйся инструментом по-назначению, и будет тебе счастье. Аудит не для этого.
Не понял что-то... про какой ИНСТРУМЕНТ ты говоришь ? чем лог аудита отличается от польз. трейса ?
Аудит и пользовательский трейс отличаются способом использования и предназначением. И это описано в релизнотах.
Повторю - для твоих (озвученных) задач аудит не предназначен. Ибо не рассчитан на частое изменение конфигурации.
Более того, для изменения конфигурации аудита нужно полностью всё остановить. Ибо в этом суть аудита - ничего не должно быть пропущено.

Нет, конечно можно и молотком винтики в очках закручивать...
9 сен 11, 13:17    [11253462]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Можно ли сделать точность выводимого времени настраиваемой (скажем, до микросекунд) ?
31 окт 11, 20:17    [11529280]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
И еще вопрос. Нужно иметь возможность "фильтрации" попыток НЕ всех коннектов, а приходящих с определенного IP-адреса (или маски адресов).
То есть, реально ли сделать вот что:
<database mydatabase.fdb>
enabled true
connection_ip_mask '192.168.13.*'
</database>
-?
10 ноя 11, 19:23    [11577939]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Да, и хотел давно вот что прояснить: почему fbtracemgr "подхватывает" переменные окружения ISC_USER + ISC_PASSWORD в случае пропуска параметров -U sysdba и -P masterke, а fbsvcmgr в аналогичной ситуации хоть и запускает сессию трейса, но ничего там не выводит ?
Вот примеры запуска fbtracemgr vs fbsvcmgr и результаты:
-- запускает трейс-сессию и ВЫВОДИТ в окне все деяния над базой:
./bin/fbtracemgr -SE service_mgr -STA -C ./fbtrace_probe01.conf  -U sysdba -P masterke

-- также запускает трейс-сессию и ВЫВОДИТ в окне все деяния над базой, 
-- но только если в окружении есть переменные ISC_USER + ISC_PASSWORD:
./bin/fbtracemgr -SE service_mgr -STA -C ./fbtrace_probe01.conf 

-- запускает трейс-сессию и ВЫВОДИТ в окне все деяния над базой:
./bin/fbsvcmgr service_mgr action_trace_start trc_name "p1" trc_cfg ./fbtrace_probe01.conf user sysdba password masterke 

-- запускает сессию, но НИЧЕГО не выводит в консоли. Хотя ISC-переменные - определены.
./bin/fbsvcmgr service_mgr action_trace_start trc_name "p1" trc_cfg ./fbtrace_probe01.conf 
10 ноя 11, 20:14    [11578052]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
Да, и хотел давно вот что прояснить: почему fbtracemgr "подхватывает" переменные окружения ISC_USER + ISC_PASSWORD в случае пропуска параметров -U sysdba и -P masterke, а fbsvcmgr в аналогичной ситуации хоть и запускает сессию трейса, но ничего там не выводит ?
А с каким же именем он логинится ? (hint: в трейсе это видно)
11 ноя 11, 11:48    [11580342]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
Таблоид
Да, и хотел давно вот что прояснить: почему fbtracemgr "подхватывает" переменные окружения ISC_USER + ISC_PASSWORD в случае пропуска параметров -U sysdba и -P masterke, а fbsvcmgr в аналогичной ситуации хоть и запускает сессию трейса, но ничего там не выводит ?
А с каким же именем он логинится ? (hint: в трейсе это видно)
Не понял, кто - "он" ?
Вот первое окно, запускаю там:
./bin/fbtracemgr -SE service_mgr -STA -C ./fbtrace_probe01.conf
Получаю в нём:
Trace session ID 19 started
2011-11-11T13:14:44.4720 (29926:0x7f4897cda0a8) TRACE_INIT
SESSION_19

Вот второе окно, запускаю там:
./bin/fbsvcmgr service_mgr action_trace_start trc_name "p1" trc_cfg ./fbtrace_probe01.conf
Получаю ответ:
Trace session ID 20 started

Вот третье окно, в нём делаю коннект к базе:
[firebird@firebird firebird]$ isql test123.fdb
Database: test123.fdb

В первом окне вывод *идёт*, вижу:
2011-11-11T13:14:44.4720 (29926:0x7f4897cda0a8) TRACE_INIT
SESSION_19

2011-11-11T13:14:44.4730 (29926:0x7f4897cda0a8) ATTACH_DATABASE
/var/db/firebird/test123.fdb (ATT_7, SYSDBA:NONE, NONE, <internal>)

Во втором окне - тишина.
11 ноя 11, 13:23    [11581222]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
Не понял, кто - "он" ?
fbtracemgr
11 ноя 11, 13:27    [11581265]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
hvlad
Таблоид
Не понял, кто - "он" ?
fbtracemgr
Тьфу, fbsvcmgr конечно же
11 ноя 11, 13:27    [11581276]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad,

я добавил в fbtrace_probe01.conf вот это вот:
<services>
  enabled true
  log_services true
</services>
И вижу теперь при запуске что fbtracemgr что при fbsvcmgr нечто странное: он выводит зачем-то мой fbtrace_probe01.conf :-)
Ну и "сам себя" тоже выводит:

./bin/fbtracemgr -SE service_mgr -STA -C ./fbtrace_probe01.conf
Trace session ID 23 started
2011-11-11T13:33:45.7440 (31599:0x7f04ce317978) TRACE_INIT
SESSION_23


2011-11-11T13:33:45.7500 (31599:0x7f04ce317978) START_SERVICE
service_mgr, (Service 0x7f04d09d1cc0, SYSDBA, internal)
"Start Trace Session"
-TRUSTED_SVC SYSDBA -START -CONFIG <services>
enabled true
log_services true
</services>
<database %[\\/](test123).fdb>
enabled true
log_filename /var/db/firebird/fbtrace_probe01.log
log_connections true
time_threshold 0
</database>

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

./bin/fbsvcmgr service_mgr action_trace_start trc_name "p1" trc_cfg ./fbtrace_probe01.conf
Trace session ID 24 started
2011-11-11T13:35:34.2800 (31731:0x7fc608043810) TRACE_INIT
SESSION_24 p1


2011-11-11T13:35:34.2800 (31731:0x7fc608043810) START_SERVICE
service_mgr, (Service 0x7fc60a1dccc0, firebird, internal)
"Start Trace Session"
-TRUSTED_SVC firebird -START -NAME p1 -CONFIG <services>
enabled true
log_services true
</services>
<database %[\\/](test123).fdb>
enabled true
log_filename /var/db/firebird/fbtrace_probe01.log
log_connections true
time_threshold 0
</database>

Вроде прояснилось: fbsvcmgr берёт имя, отличное от SYSDBA. Но по каким причинам он не ищет ISC_, я так и не понял.
И почему они оба стали выводить на консоль содержимое трейс_конфига ? :-)
11 ноя 11, 13:48    [11581532]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
fbsvcmgr берёт имя, отличное от SYSDBA.
Видимо, имя пользователя под которым ты залогинен.

Таблоид
Но по каким причинам он не ищет ISC_, я так и не понял
Это нужно Алекса пытать.

Таблоид
И почему они оба стали выводить на консоль содержимое трейс_конфига ? :-)
Они выводят все параметры, с которыми запущен сервис.
11 ноя 11, 14:01    [11581688]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
hvlad
Таблоид
Но по каким причинам он не ищет ISC_, я так и не понял
Это нужно Алекса пытать.
Под пытками, он посоветовал занести этот вопрос в трекер.
11 ноя 11, 14:30    [11581999]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
hvlad
пропущено...
Это нужно Алекса пытать.
Под пытками, он посоветовал занести этот вопрос в трекер.
Легко. http://tracker.firebirdsql.org/browse/CORE-3658
11 ноя 11, 15:48    [11582788]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
fbtrace.conf
# Maximum size of log file (megabytes). Used by system audit trace for
# log's rotation : when current log file reached this limit it is renamed
# using current date and time and new log file is created. Value of zero
# means that the log file size is unlimited and rotation will never happen.
max_log_size 0
Допустим, я выставил max_log_size = 20. Запустил что-то молотить, через некоторое время начинаю смотреть в лог аудита (у меня его имя = 'zaudit.log').
Молотилка тем временем доводит размер лога до 20 мегов и тут его надо переименовать. Но переименовать не получается, т.к. я держу файл открытым.
В этот момент в логе сервера появляется запись:
Trace plugin fbtrace.dll returned error on call tpl_event_dsql_execute.
Error details: PluginLogWriter: MoveFile failed on file "C:\1INSTALL\FIREBIRD\FB_2_5\zaudit.log". Error is : 32
- и логирование полностью прекращается.

ИМХО, разумнее было бы создать новый файл с каким-нибудь расширением или суффиксом в имени, отражающим возникшую проблему (например, '.part01', '.part02' etc - как в RAR'e), но не прекращать логирование.
17 ноя 11, 07:29    [11610171]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Очередное "чудо" одно вылезло.
Есть некая программа, выполняющая в цикле перенос данных из таблицы 'TC' (100'000 строк) в базе T1.FDB в одноимённую таблицу в базе T2.FDB.
На обе базы натравлен аудит со след. параметрами:
  enabled true
log_context true
log_filename zaudit.log
max_log_size 0
log_connections true
log_transactions true
log_statement_finish true
print_perf true
time_threshold 0
max_sql_length 2000
max_dyn_length 2000

Аудит показывает, как идёт цикл, начиная с первого ID'шника и далее до 100-тысячного:
+
Statement 41:
-------------------------------------------------------------------------------
UPDATE TC SET S=? WHERE ID=?
param0 = varchar(1000), "24932376-B882-5843-867D-FCD40DFD3C4A24932376-B882-5843-867D-FCD40DFD3C4A"
param1 = integer, "1"
...
Statement 41:
-------------------------------------------------------------------------------
UPDATE TC SET S=? WHERE ID=?
param0 = varchar(1000), "77D62AFB-657B-9643-9DE9-B5AE0BCA092C77D62AFB-657B-9643-9DE9-B5AE0BCA092C"
param1 = integer, "2"
...
Statement 41:
-------------------------------------------------------------------------------
UPDATE TC SET S=? WHERE ID=?
param0 = varchar(1000), "4284E36C-2943-E543-BD33-3FE0AD2A1A2F4284E36C-2943-E543-BD33-3FE0AD2A1A2F"
param1 = integer, "3"
После итерации номер 100'000 программа выполняет полную "вычитку" всех 100 тыс строк и в логе должно было появиться следующее:
+
2011-11-17T08:00:25.0460 (1516:01BDCBA4) EXECUTE_STATEMENT_FINISH
C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_71, SYSDBA:NONE, WIN1251, TCPv4:127.0.0.1)
D:\dataporter.exe:396
(TRA_417, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)
Statement 39:
-------------------------------------------------------------------------------
SELECT ID,S FROM TC ORDER BY ID
100000 records fetched
48152 ms, 3764 read(s), 300322 fetch(es)

Table Natural Index Update Insert Delete Backout Purge Expunge
***************************************************************************************************************
RDB$CHARACTER_SETS 1
RDB$COLLATIONS 1
TC 100000

2011-11-17T08:00:25.0460 (1516:01BDDEE0) EXECUTE_STATEMENT_FINISH
C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_11, SYSDBA:NONE, WIN1251, TCPv4:127.0.0.1)
D:\dataporter.exe:396
(TRA_19, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)
Statement 39:
-------------------------------------------------------------------------------
SELECT ID,S FROM TC ORDER BY ID
100000 records fetched
61675 ms, 3900 read(s), 610 write(s), 907847 fetch(es), 203762 mark(s)

Table Natural Index Update Insert Delete Backout Purge Expunge
***************************************************************************************************************
RDB$CHARACTER_SETS 1
RDB$COLLATIONS 1
TC 100000 100000

А теперь самое интересное.
Записи в логе о фетче всех 100 тыс строк действительно есть, но расположены они почему-то... между итерациями 99774 и 99775, т.е. вот так:
+
2011-11-17T08:00:25.0460 (1516:01BDDEE0) EXECUTE_STATEMENT_FINISH
C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_11, SYSDBA:NONE, WIN1251, TCPv4:127.0.0.1)
D:\dataporter.exe:396
(TRA_19, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)

Statement 41:
-------------------------------------------------------------------------------
UPDATE TC SET S=? WHERE ID=?

param0 = varchar(1000), "C362D8E6-15DB-DD4C-9A0D-B16456F9C7ABC362D8E6-15DB-DD4C-9A0D-B16456F9C7AB"
param1 = integer, "99774"
......

2011-11-17T08:00:25.0460 (1516:01BDCBA4) EXECUTE_STATEMENT_FINISH
C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_71, SYSDBA:NONE, WIN1251, TCPv4:127.0.0.1)
D:\dataporter.exe:396
(TRA_417, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)

Statement 39:
-------------------------------------------------------------------------------
SELECT ID,S FROM TC ORDER BY ID
100000 records fetched
48152 ms, 3764 read(s), 300322 fetch(es)

Table Natural Index Update Insert Delete Backout Purge Expunge
***************************************************************************************************************
RDB$CHARACTER_SETS 1
RDB$COLLATIONS 1
TC 100000

2011-11-17T08:00:25.0460 (1516:01BDDEE0) EXECUTE_STATEMENT_FINISH
-- T2.FDB - это база-приёмник! откуда в ней могут быть сейчас 100 тыс строк ??
C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_11, SYSDBA:NONE, WIN1251, TCPv4:127.0.0.1)
D:\dataporter.exe:396
(TRA_19, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)

Statement 39:
-------------------------------------------------------------------------------
SELECT ID,S FROM TC ORDER BY ID
100000 records fetched -- <<< как это могло оказаться ЗДЕСЬ, за 225 итераций до окончания цикла ???
61675 ms, 3900 read(s), 610 write(s), 907847 fetch(es), 203762 mark(s)

Table Natural Index Update Insert Delete Backout Purge Expunge
***************************************************************************************************************
RDB$CHARACTER_SETS 1
RDB$COLLATIONS 1
TC 100000 100000


.....
2011-11-17T08:00:25.0460 (1516:01BDDEE0) EXECUTE_STATEMENT_FINISH
C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_11, SYSDBA:NONE, WIN1251, TCPv4:127.0.0.1)
D:\dataporter.exe:396
(TRA_19, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)

Statement 41:
-------------------------------------------------------------------------------
UPDATE TC SET S=? WHERE ID=?

param0 = varchar(1000), "916E8D7F-CAC1-DE46-8124-7A3EB7E364A7916E8D7F-CAC1-DE46-8124-7A3EB7E364A7"
param1 = integer, "99775"
......

Это как-то можно объяснить ? Откуда он "узнал" на итерации номер 99774, что в таблице-приемнике уже 100 тыс строк ??

PS. 2 hvlad: лог, если надо, могу выслать в мыло.
17 ноя 11, 09:21    [11610355]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Таблоид
Откуда он "узнал" на итерации номер 99774, что в таблице-приемнике уже 100 тыс строк ??
Вопрос к трейсу снят, я запутался в двух соснах: вместо вставки в пустую таблицу начал апдейтить старую её версию, а там уже было 100 тыс строк.
17 ноя 11, 10:23    [11610688]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 43636

Таблоид
После итерации номер 100'000 программа выполняет полную "вычитку" всех 100 тыс строк

Сколько раз тебе повторять, что не после, а перед. Цикл же итераций именно по этим строкам
и идёт.

Таблоид
Откуда он "узнал" на итерации номер 99774, что в таблице-приемнике уже 100
тыс строк ??

Оттуда, что оставшиеся 226 строк уже были упакованы в сетевой буфер. И хотя на клиенте
отфетчено только 99774, то сервер ему выслал все 100000.

Posted via ActualForum NNTP Server 1.4

17 ноя 11, 15:01    [11614174]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Кажется, я что-то доломал: на моей бедной машине трейс больше не хочет работать :'(
Сейчас получаю швабры:
1) .\bin\fbtracemgr -SE service_mgr -STA -C .\zaudit.conf   -U sysdba -P masterke
Cannot attach to services manager

2) .\bin\fbsvcmgr service_mgr user sysdba password masterke action_trace_start trc_name "p1" trc_cfg .\zaudit.conf
Cannot attach to services manager

3) .\bin\fbsvcmgr service_mgr action_trace_start trc_name "p1" trc_cfg .\zaudit.conf user sysdba password masterke
Unknown switch "user"
Пробовал сначала из-под FAR'a, затем непосредственно в cmd.exe.
В логе сервера - тишина полная.

Хотя сама служба ФБ работает (только что скачал последний билд):
C:\1INSTALL\FIREBIRD\FB_2_5>.\bin\isql -z localhost/3050:C:\1INSTALL\FIREBIRD\FB_2_5\TEST5.fdb
ISQL Version: WI-V2.5.2.26390 Firebird 2.5
Server version:
WI-V2.5.2.26390 Firebird 2.5
WI-V2.5.2.26390 Firebird 2.5/tcp (balaha)/P12
WI-V2.5.2.26390 Firebird 2.5/tcp (balaha)/P12
Database: localhost/3050:C:\1INSTALL\FIREBIRD\FB_2_5\TEST5.fdb

ЗЫ. Конфиг для трейса, который всегда успешно отрабатывал (в т.ч. и сегодняшним утром):
C:\1INSTALL\FIREBIRD\FB_2_5>type zaudit.conf
<database %[\\/](t1|t2).fdb>
enabled true
log_context true
log_filename zaudit.log
max_log_size 0
log_connections true
log_transactions true
log_statement_finish true
print_perf true
time_threshold 0
max_sql_length 2000
max_dyn_length 2000
#log_statement_prepare true
#log_procedure_finish true
</database>
#<database %[\\/](empl`oyee|i`dx_under_load_test|test|test2|test3|test4|test5|t1|t2).fdb>

Куда рыть ?
17 ноя 11, 23:00    [11617304]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Попробуй localhost:service_mgr
17 ноя 11, 23:02    [11617313]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
Попробуй localhost:service_mgr
Вахх!.. заработало, псип! :-)
Однако... почему до этого дождливого вечера всё работало без локалхоста, а теперь вдруг с ним надо ??
17 ноя 11, 23:05    [11617328]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид,

у тебя в путях старый\левый клиент, либо ты умудрился запустить сервер без поддержки XNET.
18 ноя 11, 00:29    [11617576]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
у тебя в путях старый\левый клиент, либо ты умудрился запустить сервер без поддержки XNET.

Клиент был от сентября 2011, я его заменил на нынешний, от 15-11-2011.
Службу ФБ запускаю так: C:\1INSTALL\FIREBIRD\FB_2_5\bin\fb_inet_server.exe -i -s FB_DEFAULT -m
В firebird.conf'e ей назначен порт RemoteServicePort = 3050 - в общем, ничего не менял уже давно.

Не знаю, что произошло, но с утра аудит опять включился автоматом на тестовой базе.
Наверное, помутнение у него было какое-то... :-)
18 ноя 11, 08:38    [11617903]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид,

а как ты думаешь, что ключ -i означает ?
18 ноя 11, 11:48    [11618991]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
а как ты думаешь, что ключ -i означает ?
Этот ключик нужен для того, чтобы запретить подключения по локальному протоколу, который раньше звался IPC, а начиная с 2.0 называется почему-то XNET (при чём тут "net", если он ЛОКАЛЬНЫЙ ?). Про XNET прочитано тут: doc/README.xnet.txt, а вот про ключик '-i' сначала узнал приватным образом, а совсем недавно и тут что-то было, но найти теперь не могу :'(

Если не добавлять ключ '-i' в строку запуска службы fb_inet_server, то при старте второй и последующих ФБ-служб в firebird.log'e будет ошибка о наличии инстанса, запущенного перед этим.
Я это ключик установил несколько месяцев назад, когда понадобилось потестировать одну из "спецсборок".
Аудит юзаю почти через день. А "вдруг сломалось" и также "внезапно починилось" всё только вчера вечером и сегодня утром соотв-но.
Странно всё как-то...

ОФФ. Кстати, вопрос: где в доке почитать про все возможные ключики запуска служб ФБ (классика и суперклассика) ? Например, в %fb_home%\doc\*.txt по строке ' -i' ничего релевантного найти нельзя.
-----
tags: fb_inet_server -i, XNET
18 ноя 11, 12:44    [11619666]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 6668
Таблоид
Этот ключик нужен для того, чтобы запретить подключения по локальному протоколу

и при этом ты почему-то пытаешься подключаться к сервисам именно по локальному протоколу
18 ноя 11, 13:02    [11619872]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
dimitr
почему-то пытаешься подключаться к сервисам именно по локальному протоколу
потому что со временем забыл про то, что я сам же его задушил :-)
А подключиться к сервису через fbsvcmgr (fbtracemgr) я попытался просто потому, что аудит перестал работать.
18 ноя 11, 13:09    [11619932]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
Этот ключик нужен для того, чтобы запретить подключения по локальному протоколу
Не совсем так.
По умолчанию, слушатель использует все три имеющихся протокола (локальный - XNET, winsock - INET, named pipes - WNET).
Если же использовать ключ любого протокола, то остальные протоколы отключаются и требуют явного задания своих ключей.

ключ протокол
-x XNET
-i INET
-w WNET

Т.е. если ключи протоколов не заданы, то работают все протоколы. Иначе - только те, чьи ключи заданы.
18 ноя 11, 13:55    [11620434]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
Таблоид
Этот ключик нужен для того, чтобы запретить подключения по локальному протоколу
Не совсем так.
По умолчанию, слушатель использует все три имеющихся протокола (локальный - XNET, winsock - INET, named pipes - WNET).
Если же использовать ключ любого протокола, то остальные протоколы отключаются и требуют явного задания своих ключей.

ключ протокол
-x XNET
-i INET
-w WNET

Т.е. если ключи протоколов не заданы, то работают все протоколы. Иначе - только те, чьи ключи заданы.
Понятно. Значит, я напротив сказал всем четырём службам (2.0, 2.1, 2.5.1 и 2.5.2) слушать только XNET.
Но тогда тем более непонятно, как мог остановиться аудит! Вот ты выше говорил мне: "ты умудрился запустить сервер без поддержки XNET" - а оказалось, что именно на локальном протоколе у меня всё и было запущено.
18 ноя 11, 14:24    [11620796]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
Понятно. Значит, я напротив сказал всем четырём службам (2.0, 2.1, 2.5.1 и 2.5.2) слушать только XNET.
Вот ты как читаешь - по диагонали, через слово или выборочные буквы ?
Какой, нафиг, XNET с опцией -i ?
18 ноя 11, 14:39    [11620962]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
Вот ты как читаешь - по диагонали, через слово или выборочные буквы ?
Какой, нафиг, XNET с опцией -i ?
Да, каюсь. По диагонали было прочитано...
Итак, у меня fb_inet_server -i ==> работа только через winsock - INET.

Но когнитивный диссонанс-таки остается:
1) Уже много дней сервисы (все) запущены БЕЗ поддержки локального протокола.
2) Аудит работает при этом нормально вплоть до вчерашнего мрачного ночера - т.е. я просто указал в firebird.conf'e файл конфигурации аудита (zaudit.conf) и совершенно не заботился о том, как он там подключается к ФБ (через INET, XNET или еще как-то ?)
3) Вчера ночером аудит внезапно перестаёт реагировать на правки в его конфиге (при отсутствии коннектов и вообще вЫключенной ФБ-службе).
4) Сегодня утром внезапно аудит опять заработал - просто комп включил, ничего не исправлял. Новость скорее пугающая, чем радостная.
18 ноя 11, 15:13    [11621317]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
1) Уже много дней сервисы (все) запущены БЕЗ поддержки локального протокола.
Но не перезапущены (как минимум один из них) после правки строки запуска в реестре.

Таблоид
2) Аудит работает при этом нормально вплоть до вчерашнего мрачного ночера - т.е. я просто указал в firebird.conf'e файл конфигурации аудита (zaudit.conf) и совершенно не заботился о том, как он там подключается к ФБ (через INET, XNET или еще как-то ?)
Аудит никак не подключается к движку. Он там внутри живёт.
Опят начинаешь путать себя и остальных.

Таблоид
3) Вчера ночером аудит внезапно перестаёт реагировать на правки в его конфиге (при отсутствии коннектов и вообще вЫключенной ФБ-службе).
Я не понимаю, что на что должно реагировать при "вообще вЫключенной ФБ-службе"

Таблоид
4) Сегодня утром внезапно аудит опять заработал - просто комп включил, ничего не исправлял. Новость скорее пугающая, чем радостная
См (2)

Ты начал с того, что не мог получить локальный коннект. А сейчас говоришь про аудит, который вообще не имеет к этому ни малейшего отношения. Определись уже...
18 ноя 11, 15:19    [11621371]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
Ты начал с того, что не мог получить локальный коннект. А сейчас говоришь про аудит, который вообще не имеет к этому ни малейшего отношения. Определись уже...
История такова: я решил поизучать с помощью аудита активность "некоторой программы", копирующей данные из одной ФБ-базы в другую (тоже ФБ).
Отключил ФБ, создал тестовую базу и её клон, добавил их имена в конфиг аудита. Включил ФБ, запустил "некоторую программу" - в логе аудита почему-то ничего не проявилось.
Дальше обратил внимание, что аудит вообще перестал работать и с другими базами, перечисленными в списке <databases>.
Тогда снова перезапустил ФБ, вспомнил про свою же шпаргалку и попытался стартануть user-trace.
Через fbsvcmgr - не вышло: он сначала вообще бред сказал ("Unknown switch "user"), а затем - что "Cannot attach to services manager". Тоже самое было с fbtracemgr.

ЗЫ. У меня ФБ на домашней машине только для тестирования (по кр. мере, сейчас).
User-трейс на этой машине я никогда не запускаю - зачем лишние телодвижения, когда есть аудит, работающий всегда.
Аудит же внезапно заглох. Отсюда и был тот вопрос.
18 ноя 11, 15:59    [11621796]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Таблоид
hvlad
а как ты думаешь, что ключ -i означает ?
Этот ключик нужен для того, чтобы запретить подключения по локальному протоколу, который раньше звался IPC, а начиная с 2.0 называется почему-то XNET (при чём тут "net", если он ЛОКАЛЬНЫЙ ?). Про XNET прочитано тут: doc/README.xnet.txt, а вот про ключик '-i' сначала узнал приватным образом, а совсем недавно и тут что-то было, но найти теперь не могу :'(
Внезапно нашёл. Спасибо теме про nbackup ;-)
http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=877895&msg=11222986

И вот еще про ключ '-i' при запуске fb_inet_server.exe (дублирую тут эти ссылки, т.к. они гораздо нужнее здесь, чем в топике про nbackup):
http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=853630&msg=10710107
http://comments.gmane.org/gmane.comp.db.firebird.russian/39446
21 ноя 11, 17:57    [11633948]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Очередной вопрос.

Должна ли активность gbak'a, который читает/пишет в таблицы при бекапе/восстановлении, отражаться как-то в трейсе (я имею в виду статистику его обращений к конкретным таблицам) ?
Есть, к примеру, база с одной таблицей в 1 млн строк.
Вот что вижу в трейсе при её бекапе:
+
Trace session ID 6 started
2011-11-26T22:01:48.8430 (3908:020ED584) TRACE_INIT

SESSION_6





2011-11-26T22:01:48.8430 (3908:020ED584) ATTACH_DATABASE

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_4, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3844



2011-11-26T22:01:48.8430 (3908:020ED584) START_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_4, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3844

(TRA_36, CONCURRENCY | WAIT | READ_WRITE)



2011-11-26T22:02:07.6400 (3908:020ED584) COMMIT_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_4, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3844

(TRA_36, CONCURRENCY | WAIT | READ_WRITE)

49 ms, 1 read(s), 2 write(s), 1 fetch(es), 1 mark(s)



2011-11-26T22:02:07.6400 (3908:020ED584) DETACH_DATABASE

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_4, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3844



2011-11-26T22:02:07.6400 (3908:020ED584) TRACE_FINI

SESSION_6
И вот что при ресторе:
+ (многа букф, но всё не то)
Trace session ID 7 started
2011-11-26T22:03:53.4530 (3908:020ED584) TRACE_INIT

SESSION_7





2011-11-26T22:03:53.4530 (3908:020ED584) ATTACH_DATABASE

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_5, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100



2011-11-26T22:03:53.4530 (3908:020ED584) DROP_DATABASE

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_5, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100



2011-11-26T22:03:53.4530 (3908:020ED584) TRACE_FINI

SESSION_7





2011-11-26T22:03:53.8280 (3908:020ED584) TRACE_INIT

SESSION_7





2011-11-26T22:03:53.8280 (3908:020ED584) CREATE_DATABASE

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100



2011-11-26T22:03:53.8280 (3908:020ED584) START_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_1, CONCURRENCY | WAIT | READ_WRITE)



2011-11-26T22:03:53.8280 (3908:020ED584) START_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_2, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



2011-11-26T22:03:53.8430 (3908:020ED584) COMMIT_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_1, CONCURRENCY | WAIT | READ_WRITE)

3 ms, 10 read(s), 22 write(s), 170 fetch(es), 23 mark(s)



2011-11-26T22:03:53.8430 (3908:020ED584) START_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_3, CONCURRENCY | WAIT | READ_WRITE)



2011-11-26T22:04:39.0620 (3908:020ED584) COMMIT_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_3, CONCURRENCY | WAIT | READ_WRITE)

4812 ms, 42 read(s), 12413 write(s), 3380 fetch(es), 455 mark(s)



2011-11-26T22:04:39.0620 (3908:020ED584) START_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_4, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



2011-11-26T22:04:43.8280 (3908:020ED584) COMMIT_RETAINING

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_4, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)

4759 ms, 1211 write(s), 2027181 fetch(es), 2417 mark(s)



2011-11-26T22:04:43.8430 (3908:020ED584) COMMIT_RETAINING

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_5, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)

5 ms, 7 write(s), 69 fetch(es), 9 mark(s)



2011-11-26T22:04:43.8430 (3908:020ED584) COMMIT_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_6, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)

0 ms, 1 write(s), 1 fetch(es), 1 mark(s)



2011-11-26T22:04:43.8430 (3908:020ED584) START_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_7, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



2011-11-26T22:04:43.8430 (3908:020ED584) COMMIT_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_7, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)

0 ms, 1 write(s), 1 fetch(es), 1 mark(s)



2011-11-26T22:04:43.8430 (3908:020ED584) COMMIT_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_2, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)

0 ms, 1 write(s), 1 fetch(es), 1 mark(s)



2011-11-26T22:04:43.8430 (3908:020ED584) START_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_8, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



2011-11-26T22:04:43.8430 (3908:020ED584) EXECUTE_STATEMENT_START

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_8, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



Statement 408:

-------------------------------------------------------------------------------

EXECUTE BLOCK AS DECLARE VARIABLE maxInTable INT; DECLARE VARIABLE currentGen INT; BEGIN SELECT FIRST(1) CAST(SUBSTRING(RDB$CONSTRAINT_NAME FROM 7 FOR 32) AS INT) FROM RDB$RELATION_CONSTRAINTS WHERE SUBSTRING(RDB$CONSTRAINT_NAME FROM 7 FOR 32) < '999999999999999999999999999999' AND RDB$CONSTRAINT_NAME STARTING WITH 'INTEG_' ORDER BY 1 DESC INTO :maxInTable; currentGen = gen_id(RDB$CONSTRAINT_NAME, 0); IF (currentGen < maxInTable) THEN EXECUTE STATEMENT 'SET GENERATOR RDB$CONSTRAINT_NAME TO ' || maxInTable; END



2011-11-26T22:04:43.8430 (3908:020ED584) EXECUTE_STATEMENT_FINISH

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_8, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



Statement 408:

-------------------------------------------------------------------------------

EXECUTE BLOCK AS DECLARE VARIABLE maxInTable INT; DECLARE VARIABLE currentGen INT; BEGIN SELECT FIRST(1) CAST(SUBSTRING(RDB$CONSTRAINT_NAME FROM 7 FOR 32) AS INT) FROM RDB$RELATION_CONSTRAINTS WHERE SUBSTRING(RDB$CONSTRAINT_NAME FROM 7 FOR 32) < '999999999999999999999999999999' AND RDB$CONSTRAINT_NAME STARTING WITH 'INTEG_' ORDER BY 1 DESC INTO :maxInTable; currentGen = gen_id(RDB$CONSTRAINT_NAME, 0); IF (currentGen < maxInTable) THEN EXECUTE STATEMENT 'SET GENERATOR RDB$CONSTRAINT_NAME TO ' || maxInTable; END

0 records fetched

0 ms, 3 fetch(es)



2011-11-26T22:04:43.8590 (3908:020ED584) EXECUTE_STATEMENT_START

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_8, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



Statement 409:

-------------------------------------------------------------------------------

EXECUTE BLOCK AS DECLARE VARIABLE maxInTable INT; DECLARE VARIABLE currentGen INT; BEGIN SELECT FIRST(1) CAST(SUBSTRING(RDB$FIELD_NAME FROM 5 FOR 32) AS INT) FROM RDB$FIELDS WHERE SUBSTRING(RDB$FIELD_NAME FROM 5 FOR 32) < '999999999999999999999999999999' AND RDB$FIELD_NAME STARTING WITH 'RDB$' ORDER BY 1 DESC INTO :maxInTable; currentGen = gen_id(RDB$FIELD_NAME, 0); IF (currentGen < maxInTable) THEN EXECUTE STATEMENT 'SET GENERATOR RDB$FIELD_NAME TO ' || maxInTable; END



2011-11-26T22:04:43.8590 (3908:020ED584) EXECUTE_STATEMENT_START

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_8, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



Statement 410:

-------------------------------------------------------------------------------

SET GENERATOR RDB$FIELD_NAME TO 2



2011-11-26T22:04:43.8590 (3908:020ED584) EXECUTE_STATEMENT_FINISH

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_8, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



Statement 410:

-------------------------------------------------------------------------------

SET GENERATOR RDB$FIELD_NAME TO 2

0 records fetched

0 ms, 1 fetch(es), 1 mark(s)



2011-11-26T22:04:43.8590 (3908:020ED584) EXECUTE_STATEMENT_FINISH

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_8, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



Statement 409:

-------------------------------------------------------------------------------

EXECUTE BLOCK AS DECLARE VARIABLE maxInTable INT; DECLARE VARIABLE currentGen INT; BEGIN SELECT FIRST(1) CAST(SUBSTRING(RDB$FIELD_NAME FROM 5 FOR 32) AS INT) FROM RDB$FIELDS WHERE SUBSTRING(RDB$FIELD_NAME FROM 5 FOR 32) < '999999999999999999999999999999' AND RDB$FIELD_NAME STARTING WITH 'RDB$' ORDER BY 1 DESC INTO :maxInTable; currentGen = gen_id(RDB$FIELD_NAME, 0); IF (currentGen < maxInTable) THEN EXECUTE STATEMENT 'SET GENERATOR RDB$FIELD_NAME TO ' || maxInTable; END

0 records fetched

1 ms, 247 fetch(es)



Table Natural Index Update Insert Delete Backout Purge Expunge

***************************************************************************************************************

RDB$FIELDS 122



2011-11-26T22:04:43.8590 (3908:020ED584) EXECUTE_STATEMENT_START

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_8, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



Statement 411:

-------------------------------------------------------------------------------

EXECUTE BLOCK AS DECLARE VARIABLE maxInTable INT; DECLARE VARIABLE currentGen INT; BEGIN SELECT FIRST(1) CAST(SUBSTRING(RDB$INDEX_NAME FROM 5 FOR 32) AS INT) FROM RDB$INDICES WHERE SUBSTRING(RDB$INDEX_NAME FROM 5 FOR 32) < '999999999999999999999999999999' AND RDB$INDEX_NAME STARTING WITH 'RDB$' ORDER BY 1 DESC INTO :maxInTable; currentGen = gen_id(RDB$INDEX_NAME, 0); IF (currentGen < maxInTable) THEN EXECUTE STATEMENT 'SET GENERATOR RDB$INDEX_NAME TO ' || maxInTable; END



2011-11-26T22:04:43.8590 (3908:020ED584) EXECUTE_STATEMENT_FINISH

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_8, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



Statement 411:

-------------------------------------------------------------------------------

EXECUTE BLOCK AS DECLARE VARIABLE maxInTable INT; DECLARE VARIABLE currentGen INT; BEGIN SELECT FIRST(1) CAST(SUBSTRING(RDB$INDEX_NAME FROM 5 FOR 32) AS INT) FROM RDB$INDICES WHERE SUBSTRING(RDB$INDEX_NAME FROM 5 FOR 32) < '999999999999999999999999999999' AND RDB$INDEX_NAME STARTING WITH 'RDB$' ORDER BY 1 DESC INTO :maxInTable; currentGen = gen_id(RDB$INDEX_NAME, 0); IF (currentGen < maxInTable) THEN EXECUTE STATEMENT 'SET GENERATOR RDB$INDEX_NAME TO ' || maxInTable; END

0 records fetched

0 ms, 390 fetch(es), 97 mark(s)



Table Natural Index Update Insert Delete Backout Purge Expunge

***************************************************************************************************************

RDB$INDICES 47 47



2011-11-26T22:04:43.8590 (3908:020ED584) EXECUTE_STATEMENT_START

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_8, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



Statement 412:

-------------------------------------------------------------------------------

EXECUTE BLOCK AS DECLARE VARIABLE maxInTable INT; DECLARE VARIABLE currentGen INT; BEGIN SELECT FIRST(1) CAST(SUBSTRING(RDB$INDEX_NAME FROM 12 FOR 32) AS INT) FROM RDB$INDICES WHERE SUBSTRING(RDB$INDEX_NAME FROM 12 FOR 32) < '999999999999999999999999999999' AND RDB$INDEX_NAME STARTING WITH 'RDB$PRIMARY' ORDER BY 1 DESC INTO :maxInTable; currentGen = gen_id(RDB$INDEX_NAME, 0); IF (currentGen < maxInTable) THEN EXECUTE STATEMENT 'SET GENERATOR RDB$INDEX_NAME TO ' || maxInTable; END



2011-11-26T22:04:43.8590 (3908:020ED584) EXECUTE_STATEMENT_FINISH

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_8, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



Statement 412:

-------------------------------------------------------------------------------

EXECUTE BLOCK AS DECLARE VARIABLE maxInTable INT; DECLARE VARIABLE currentGen INT; BEGIN SELECT FIRST(1) CAST(SUBSTRING(RDB$INDEX_NAME FROM 12 FOR 32) AS INT) FROM RDB$INDICES WHERE SUBSTRING(RDB$INDEX_NAME FROM 12 FOR 32) < '999999999999999999999999999999' AND RDB$INDEX_NAME STARTING WITH 'RDB$PRIMARY' ORDER BY 1 DESC INTO :maxInTable; currentGen = gen_id(RDB$INDEX_NAME, 0); IF (currentGen < maxInTable) THEN EXECUTE STATEMENT 'SET GENERATOR RDB$INDEX_NAME TO ' || maxInTable; END

0 records fetched

0 ms, 3 fetch(es)



2011-11-26T22:04:43.8590 (3908:020ED584) EXECUTE_STATEMENT_START

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_8, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



Statement 413:

-------------------------------------------------------------------------------

EXECUTE BLOCK AS DECLARE VARIABLE maxInTable INT; DECLARE VARIABLE currentGen INT; BEGIN SELECT FIRST(1) CAST(SUBSTRING(RDB$INDEX_NAME FROM 12 FOR 32) AS INT) FROM RDB$INDICES WHERE SUBSTRING(RDB$INDEX_NAME FROM 12 FOR 32) < '999999999999999999999999999999' AND RDB$INDEX_NAME STARTING WITH 'RDB$FOREIGN' ORDER BY 1 DESC INTO :maxInTable; currentGen = gen_id(RDB$INDEX_NAME, 0); IF (currentGen < maxInTable) THEN EXECUTE STATEMENT 'SET GENERATOR RDB$INDEX_NAME TO ' || maxInTable; END



2011-11-26T22:04:43.8590 (3908:020ED584) EXECUTE_STATEMENT_FINISH

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_8, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



Statement 413:

-------------------------------------------------------------------------------

EXECUTE BLOCK AS DECLARE VARIABLE maxInTable INT; DECLARE VARIABLE currentGen INT; BEGIN SELECT FIRST(1) CAST(SUBSTRING(RDB$INDEX_NAME FROM 12 FOR 32) AS INT) FROM RDB$INDICES WHERE SUBSTRING(RDB$INDEX_NAME FROM 12 FOR 32) < '999999999999999999999999999999' AND RDB$INDEX_NAME STARTING WITH 'RDB$FOREIGN' ORDER BY 1 DESC INTO :maxInTable; currentGen = gen_id(RDB$INDEX_NAME, 0); IF (currentGen < maxInTable) THEN EXECUTE STATEMENT 'SET GENERATOR RDB$INDEX_NAME TO ' || maxInTable; END

0 records fetched

0 ms, 3 fetch(es)



2011-11-26T22:04:43.8590 (3908:020ED584) EXECUTE_STATEMENT_START

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_8, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



Statement 414:

-------------------------------------------------------------------------------

EXECUTE BLOCK AS DECLARE VARIABLE maxInTable INT; DECLARE VARIABLE currentGen INT; BEGIN SELECT FIRST(1) CAST(SUBSTRING(RDB$TRIGGER_NAME FROM 7 FOR 32) AS INT) FROM RDB$TRIGGERS WHERE SUBSTRING(RDB$TRIGGER_NAME FROM 7 FOR 32) < '999999999999999999999999999999' AND RDB$TRIGGER_NAME STARTING WITH 'CHECK_' ORDER BY 1 DESC INTO :maxInTable; currentGen = gen_id(RDB$TRIGGER_NAME, 0); IF (currentGen < maxInTable) THEN EXECUTE STATEMENT 'SET GENERATOR RDB$TRIGGER_NAME TO ' || maxInTable; END



2011-11-26T22:04:43.8590 (3908:020ED584) EXECUTE_STATEMENT_FINISH

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_8, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



Statement 414:

-------------------------------------------------------------------------------

EXECUTE BLOCK AS DECLARE VARIABLE maxInTable INT; DECLARE VARIABLE currentGen INT; BEGIN SELECT FIRST(1) CAST(SUBSTRING(RDB$TRIGGER_NAME FROM 7 FOR 32) AS INT) FROM RDB$TRIGGERS WHERE SUBSTRING(RDB$TRIGGER_NAME FROM 7 FOR 32) < '999999999999999999999999999999' AND RDB$TRIGGER_NAME STARTING WITH 'CHECK_' ORDER BY 1 DESC INTO :maxInTable; currentGen = gen_id(RDB$TRIGGER_NAME, 0); IF (currentGen < maxInTable) THEN EXECUTE STATEMENT 'SET GENERATOR RDB$TRIGGER_NAME TO ' || maxInTable; END

0 records fetched

0 ms, 3 fetch(es)



2011-11-26T22:04:43.8590 (3908:020ED584) COMMIT_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100

(TRA_8, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)

1 ms, 13 write(s), 102 fetch(es), 22 mark(s)



2011-11-26T22:04:43.8590 (3908:020ED584) DETACH_DATABASE

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_1, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100



2011-11-26T22:04:43.8590 (3908:020ED584) TRACE_FINI

SESSION_7





2011-11-26T22:04:44.8750 (3908:020ED584) TRACE_INIT

SESSION_7





2011-11-26T22:04:44.8750 (3908:020ED584) ATTACH_DATABASE

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_2, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100



2011-11-26T22:04:44.8900 (3908:020ED584) DETACH_DATABASE

C:\1INSTALL\FIREBIRD\DATA\T2.FDB (ATT_2, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:3100



2011-11-26T22:04:44.8900 (3908:020ED584) TRACE_FINI

SESSION_7

В писании утверждается:
Кооп. сборка мусора
gbak является обычной программой, как и любые другие, которые можете написать и вы. Она подсоединяется к базе данных, стартует транзакцию snapshot и затем вычитывает все данные в БД
Тогда вопрос очевидный: раз gbak весь такой обычный, то почему в трейсе не видно, как он таблицы молотит и, главное, сколько времени у него на это уходит ?

PS. Содержимое конфигурации трейса:
<database %[\\/](t1|t2|t3).fdb>
enabled true
log_context true
log_filename zaudit.log
max_log_size 0
log_connections true
log_transactions true
log_statement_start true
log_statement_finish true
print_perf true
time_threshold 0
max_sql_length 2000
max_dyn_length 2000
#log_statement_prepare true
#log_procedure_finish true
</database>
26 ноя 11, 22:18    [11664973]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
Должна ли активность gbak'a, который читает/пишет в таблицы при бекапе/восстановлении, отражаться как-то в трейсе (я имею в виду статистику его обращений к конкретным таблицам) ?
Да.
Включи трассировку BLR запросов.
27 ноя 11, 00:59    [11665456]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
Таблоид
Должна ли активность gbak'a, который читает/пишет в таблицы при бекапе/восстановлении, отражаться как-то в трейсе (я имею в виду статистику его обращений к конкретным таблицам) ?
Да.
Включи трассировку BLR запросов.
Включил. Но как-то не бросилось в глаза.
DDL:
create database "test.fdb" pagesize 4096;
commit;
connect test.fdb user sysdba password masterke;
recreate table tmp(id int);
commit;
set term ^;
execute block as 
declare n int = 100000;
begin
  while (n>0) do insert into tmp values(:n) returning :n-1 into n;
end^
set term ;^
commit;
Trace config:
C:\1INSTALL\FIREBIRD\FB_2_5>type zaudit.conf
<services>
  enabled true
  # Put service attach, detach and start records
  log_services true
  # Put service query records
  #log_service_query true
</services>
<database %[\\/](test|t1|t2|t3).fdb>
  enabled true
  log_context true
  log_filename zaudit.log
  max_log_size 0
  log_connections true
  log_transactions true
  log_statement_start true
  log_statement_finish true
  log_blr_requests true
  print_perf true
  print_blr true
  time_threshold 0
  max_sql_length 2000
  max_blr_length 2000
  max_dyn_length 2000
  #log_statement_prepare true
  #log_procedure_finish true
</database>
Запускаю fbsvcmgr:
fbsvcmgr service_mgr user sysdba password masterke 
   action_trace_start trc_name "p1" trc_cfg zaudit.conf > fbsvcmgr.txt
Запускаю во втором окне gbak:
gbak -b test.fdb test.fbk

По завершении бекапа завершаю fbsvcmgr.
Содержимое лога fbsvcmgr.txt:
+
Trace session ID 3 started
2011-11-27T08:07:11.2180 (464:020DD364) TRACE_INIT

SESSION_3 p1





2011-11-27T08:07:11.2180 (464:020DD364) START_SERVICE

service_mgr, (Service 009A0FA4, SYSDBA, XNET:BALAHA, C:\1INSTALL\FIREBIRD\FB_2_5\bin\fbsvcmgr.exe:1440)

"Start Trace Session"

-TRUSTED_SVC SYSDBA -START -NAME p1 -CONFIG <services>

enabled true

# Put service attach, detach and start records

log_services true

# Put service query records

#log_service_query true

</services>

<database %[\\/](test|t1|t2|t3).fdb>

enabled true

log_context true

log_filename zaudit.log

max_log_size 0

log_connections true

log_transactions true

log_statement_start true

log_statement_finish true

log_blr_requests true

print_perf true

print_blr true

time_threshold 0

max_sql_length 2000

max_blr_length 2000

max_dyn_length 2000

#log_statement_prepare true

#log_procedure_finish true

</database>





2011-11-27T08:07:15.0000 (464:020DB6FC) TRACE_INIT

SESSION_3 p1





2011-11-27T08:07:15.0000 (464:020DB6FC) ATTACH_DATABASE

C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_5, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:924



2011-11-27T08:07:15.0000 (464:020DB6FC) START_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_5, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:924

(TRA_13, CONCURRENCY | WAIT | READ_WRITE)



2011-11-27T08:07:16.3280 (464:020DB6FC) COMMIT_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_5, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:924

(TRA_13, CONCURRENCY | WAIT | READ_WRITE)

0 ms, 1 read(s), 1 write(s), 1 fetch(es), 1 mark(s)



2011-11-27T08:07:16.3280 (464:020DB6FC) DETACH_DATABASE

C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_5, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\gbak.exe:924



2011-11-27T08:07:16.3280 (464:020DB6FC) TRACE_FINI

SESSION_3 p1
27 ноя 11, 08:12    [11666037]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Очередная непонятка. Почему fbtracemgr (LI-V2.5.2.26405) грузит одно из ядер на 75-99% ?
Строка запуска:
fbtracemgr -sta -se service_mgr -c trc.conf > my_trace.txt
Содержимое конфига:
<database %[\\/](aaa%).fdb>
enabled true
log_filename ./trace.log
log_connections true
log_transactions true
log_statement_start true
log_statement_finish true
# print_plan true
print_perf true
max_sql_length 4096
time_threshold 0
</database>

База - тестовая, активность с ней была только с одного коннекта (сейчас и его нет).

top:
top - 18:13:00 up 1 day,  6:47,  4 users,  load average: 0.04, 0.43, 0.50
Tasks: 177 total, 1 running, 176 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 29.2%us, 45.8%sy, 0.0%ni, 24.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 16445808k total, 16274500k used, 171308k free, 90124k buffers
Swap: 65537156k total, 0k used, 65537156k free, 15240860k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7094 firebird 20 0 79396 6412 4544 S 75.2 0.0 15:14.34 fbtracemgr


bash-3.2$ uname -a
Linux testracdb.localdomain 2.6.32-200.13.1.el5uek #1 SMP Wed Jul 27 21:02:33 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
27 дек 11, 19:18    [11835109]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Можно ли добавить в список конфигурируемых параметров шаблон имени, которому должен отвечать (а также НЕ должен отвечать) remote process ?
Например, включил я аудит, а там львиная доля инфы отводится вот на этот замечательный процесс: /opt/IBPReplicator/replserver. Меня ничего не интересует его активности, но PID у него может меняться (в результате рестарта). Как "закрепить" логирование за именем процесса по принципу вкл/вЫкл ?
29 дек 11, 17:31    [11847251]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
Почему fbtracemgr (LI-V2.5.2.26405) грузит одно из ядер на 75-99% ?
Попробуй Алекса спросить
29 дек 11, 17:45    [11847317]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Новый вопрос. Аудит (встроенный который) работает как-то "не везде".

Вот что делал для его запуска:
1) остановил базу
2) отключил xinetd
3) вырубил все fb_inet_server'ы:
killall fb_inet_server
проверил, что больше их нет:
ps -e | grep fb_inet_server | wc -l // получил число = нулю
4) запустил xinet.d
5) запустил базу в онлайн

Дальше вижу, что аудит почему-то идёт только при работе с двух машин: моей и... тоже моей. Ну, и репликатор тоже добавлят дровишек в лог.
Подключаюсь к машине юзера, копирую туда файлы isql и прочая, подключаюсь к базе через isql (isql 192.168.0.60:/some_path/our_production.fdb) -- всё Ок, в аудит пишется новая инфа.
Запускаю приложение (оно ес-сно тоже через tcp) - в аудите от него нет ничего.

Что может быть ? Требуется ли подключение к ФБ именно через fbclient.dll, а не gds32.dll ?
29 дек 11, 23:00    [11848230]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 43636

Таблоид
Меня ничего не интересует его активности, но PID у него может меняться (в результате
рестарта).

Так на то у него есть PID-файл из которого ты можешь новый PID взять и в конфиг подставить.

Posted via ActualForum NNTP Server 1.5

29 дек 11, 23:09    [11848256]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Dimitry Sibiryakov
новый PID взять и в конфиг подставить
конфиг аудита перечитывается только при полной отключке всех fb_inet_server'ов, даже зомби. Т.е. мне после рестарта репликатора придется всех выключать, что ОЧЕНЬ проблемно в дневное время.
29 дек 11, 23:12    [11848267]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Таблоид
Запускаю приложение (оно ес-сно тоже через tcp) - в аудите от него нет ничего.
ЗЫ. Подсунул приложению свежий fbclient.dll (только его пришлось переименовать в gds32.dll - так надо проге), - результат ноль. Аудит не наполняется :'(
29 дек 11, 23:49    [11848401]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Таблоид
Подключаюсь к машине юзера, копирую туда файлы isql и прочая, подключаюсь к базе через isql (isql 192.168.0.60:/some_path/our_production.fdb) -- всё Ок, в аудит пишется новая инфа.
Запускаю приложение (оно ес-сно тоже через tcp) - в аудите от него нет ничего.
Спасибо Владу, ситуация прояснилась.
Дело было в том, что подавляющая часть юзеров коннектятся не напрямую к файлу базы, а к её алиасу.
Аудит (и юзеровский трейс, наверное, тоже) отслеживает НЕ имя файла, а то, что указано в строке подключения. Она была у пользователей, разумеется, совсем другой.
Правильный способ перечисления в теге <databases> имён файлов и имён алиасов следующий:
<database (%[\\/](idx_test2|blob_test123|our_production).fdb)|(alias_to_our_production)>
...
</database>
30 дек 11, 00:57    [11848598]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Кузнецов Евгений
Guest
Таблоид
Дело было в том, что подавляющая часть юзеров коннектятся не напрямую к файлу базы, а к её алиасу.

Отчего бы DatabaseAccess = None не поставить?
--
BR, Евгений
30 дек 11, 09:42    [11849195]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
oleg_m
Member

Откуда:
Сообщений: 1101
Кузнецов Евгений
Таблоид
Дело было в том, что подавляющая часть юзеров коннектятся не напрямую к файлу базы, а к её алиасу.

Отчего бы DatabaseAccess = None не поставить?

вероятно потому, что регулярно создаются новые БД.
хотя бы тестовые
30 дек 11, 09:56    [11849248]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
oleg_m
вероятно потому, что регулярно создаются новые БД.
хотя бы тестовые
Да, именно так.
30 дек 11, 10:46    [11849415]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 7293
Таблоид
oleg_m
вероятно потому, что регулярно создаются новые БД.
хотя бы тестовые
Да, именно так.
Если "работают пользователи", то создание тестовых баз должно быть или упорядочено или вообще не быть.
Поэтому не вижу ни одной проблемы записать в alias.conf десяток псевдонимов вида test0 - test9 и выдать нужное число логинов каждому тестеру персонально.
Или система безопасности FB2.5 настолько отличается от FB2.1?
30 дек 11, 13:42    [11850369]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Basil A. Sidorov
Поэтому не вижу ни одной проблемы записать в alias.conf десяток псевдонимов вида test0 - test9 и выдать нужное число логинов каждому тестеру персонально.
я тут (на работе своей) один "каждый тестер", больше это никому не интересно. Так что проблема эта для меня не актуальна.
А вот в доке по аудиту/трейсу надо бы отразить ноанс 11848598, на который я вчера налетел.

ЗЫ. Аудит пришлось только что вырубить ("Operating system call pthread_mutex_destroy failed. Error code 16"), а пользовательский трейс я всегда делаю на другом серваке.
30 дек 11, 13:52    [11850451]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 7293
Таблоид
я тут (на работе своей) один "каждый тестер"
Ну так и влепи самому себе выговор за неиспользование "DatabaseAccess=None".
30 дек 11, 13:55    [11850476]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Basil A. Sidorov
Ну так и влепи самому себе выговор за неиспользование "DatabaseAccess=None".
Подумаю над этим... :-)
30 дек 11, 13:58    [11850509]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Очередной вопрос. Тем, кто знает линух :-)

Допустим, на работу приложения с большим кол-вом коннектов и большой активностью юзеров включен аудит.
Содержимое конфига аудита не оставляет сомнений, что серверу будет жарко:
<database (%[\\/](replcfg|prod_file).fdb)|(prod_alias)>
enabled true
log_filename /var/db/firebird/trace/prodtrace.log
log_connections true
log_transactions true
log_statement_finish true
log_trigger_start true
log_trigger_finish true
# print_plan true
log_procedure_start true
log_procedure_finish true
print_perf true
max_sql_length 4096
time_threshold 0
max_log_size 10
</database>
Половина сегодняшнего дня показала, что в каталоге /var/db/firebird/trace/ идёт очень серьёзная деятельность: каждые 5-10 сек создается файлик в 10 Мб (согласно директиве max_log_size 10).
Очевидно, что за "головной" лог (prodtrace.log - в который сейчас пытаются писать полторы сотни процессов) идёт борьба и fb_inet_server'ы выстраиваются в очередь.

ВОПРОС. Есть ли в линухе команда, выдающая "на гора" общее кол-во процессов, зависших в очереди на запись в заданный файл ?

PS. Модераторам: прошу пока не переносить этот вопрос в Linux-раздел. Я продублирую его там, если ответа здесь не будет.
24 янв 12, 19:53    [11963683]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Давно хотел спросить, да всё как-то стеснялся: а почему трейс для свипа показывает сначала start/commit, а только после этого attach/detach ?
Конфиг трейса:
enabled true
log_context true
log_filename zaudit.log
log_connections true
log_transactions true

log_statement_start true
log_statement_finish true

log_trigger_start true
log_trigger_finish true

log_blr_requests true
print_perf true
print_blr true

time_threshold 0
max_sql_length 2000
max_blr_length 2000
max_dyn_length 2000
max_log_size 0
Протокол деяний:
+
Trace session ID 9 started
2012-02-11T17:50:13.4840 (424:020DB798) TRACE_INIT
SESSION_9


2012-02-11T17:50:13.4840 (424:020DB798) START_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_87, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\gfix.exe:1360
(TRA_348, READ_COMMITTED | REC_VERSION | WAIT | READ_ONLY)

2012-02-11T17:50:14.0310 (424:020DB798) COMMIT_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_87, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\gfix.exe:1360
(TRA_348, READ_COMMITTED | REC_VERSION | WAIT | READ_ONLY)
0 ms

2012-02-11T17:50:14.0620 (424:020DB798) ATTACH_DATABASE
C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_87, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\gfix.exe:1360

2012-02-11T17:50:14.0620 (424:020DB798) DETACH_DATABASE
C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_87, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\gfix.exe:1360

2012-02-11T17:50:14.0620 (424:020DB798) TRACE_FINI
SESSION_9
11 фев 12, 17:56    [12074748]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 6668
Таблоид,

такова реализация свипа и трейса. Свип выполняется как часть аттача, через соответствующие тэги DPB. Т.е. начинается аттач, проверяются права, инициализируются внутренние структуры, делается свип (валидация/прочее работчающее через DPB) и только потом аттач считается завершенным. Именно в этот момент трейс и логгирует событие. Поэтому транзакция свипа оказывается в логе раньше аттача. Правильный порядок вывести затруднительно, т.к. неожиданные исключения во время свипа и т.п. будут трактоваться как неудачный аттач и его надо логгировать именно так.

Решением тут может служить разве что разбивка аттача на два события, а-ля "begin-attach" и "end-attach".
11 фев 12, 19:20    [12075047]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Решил протрассировать IBE, когда он выполняет select count(*) from some_table.
Понятно, что он лезет в кучу системных таблиц (хотя надо всего лишь count(*))
+
Statement 9026569:
-------------------------------------------------------------------------------
select count(*) from doc

1 records fetched
940 ms, 17497 read(s), 2053088 fetch(es)

Table Natural Index Update Insert Delete Backout Purge Expunge
***************************************************************************************************************
DOC 1009048

2012-02-21T19:47:03.9000 (19382:0x7f711824b448) START_TRANSACTION
kmain4trace (ATT_103803, SYSDBA:NONE, WIN1251, TCPv4:192.168.43.42)
C:\Mix\IBE\IBExpert.exe:2252
(TRA_243884712, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)

2012-02-21T19:47:03.9010 (19382:0x7f711824b448) EXECUTE_STATEMENT_START
kmain4trace (ATT_103803, SYSDBA:NONE, WIN1251, TCPv4:192.168.43.42)
C:\Mix\IBE\IBExpert.exe:2252
(TRA_243884712, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)

Statement 9026570:
-------------------------------------------------------------------------------
SELECT RDB$RELATION_ID, RDB$RELATION_NAME FROM RDB$RELATIONS
WHERE RDB$RELATION_ID IN (128)


2012-02-21T19:47:03.9020 (19382:0x7f711824b448) EXECUTE_STATEMENT_FINISH
kmain4trace (ATT_103803, SYSDBA:NONE, WIN1251, TCPv4:192.168.43.42)
C:\Mix\IBE\IBExpert.exe:2252
(TRA_243884712, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)

Statement 9026570:
-------------------------------------------------------------------------------
SELECT RDB$RELATION_ID, RDB$RELATION_NAME FROM RDB$RELATIONS
WHERE RDB$RELATION_ID IN (128)

1 records fetched
0 ms, 1 read(s), 4 fetch(es)

Table Natural Index Update Insert Delete Backout Purge Expunge
***************************************************************************************************************
RDB$RELATIONS 1

2012-02-21T19:47:03.9020 (19382:0x7f711824b448) COMMIT_TRANSACTION
kmain4trace (ATT_103803, SYSDBA:NONE, WIN1251, TCPv4:192.168.43.42)
C:\Mix\IBE\IBExpert.exe:2252
(TRA_243884712, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)
0 ms, 1 read(s), 1 write(s), 1 fetch(es), 1 mark(s)

2012-02-21T19:47:03.9050 (19382:0x7f711824b448) START_TRANSACTION
kmain4trace (ATT_103803, SYSDBA:NONE, WIN1251, TCPv4:192.168.43.42)
C:\Mix\IBE\IBExpert.exe:2252
(TRA_243884713, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)

2012-02-21T19:47:03.9060 (19382:0x7f711824b448) EXECUTE_STATEMENT_START
kmain4trace (ATT_103803, SYSDBA:NONE, WIN1251, TCPv4:192.168.43.42)
C:\Mix\IBE\IBExpert.exe:2252
(TRA_243884713, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)

Statement 9026571:
-------------------------------------------------------------------------------
select RDB$RELATION_NAME from RDB$RELATIONS
where (RDB$RELATION_NAME = 'DOC') and
(RDB$VIEW_BLR is NULL)


2012-02-21T19:47:03.9060 (19382:0x7f711824b448) EXECUTE_STATEMENT_FINISH
kmain4trace (ATT_103803, SYSDBA:NONE, WIN1251, TCPv4:192.168.43.42)
C:\Mix\IBE\IBExpert.exe:2252
(TRA_243884713, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)

Statement 9026571:
-------------------------------------------------------------------------------
select RDB$RELATION_NAME from RDB$RELATIONS
where (RDB$RELATION_NAME = 'DOC') and
(RDB$VIEW_BLR is NULL)

1 records fetched
0 ms, 1 read(s), 4 fetch(es)

Table Natural Index Update Insert Delete Backout Purge Expunge
***************************************************************************************************************
RDB$RELATIONS 1

2012-02-21T19:47:03.9070 (19382:0x7f711824b448) COMMIT_TRANSACTION
kmain4trace (ATT_103803, SYSDBA:NONE, WIN1251, TCPv4:192.168.43.42)
C:\Mix\IBE\IBExpert.exe:2252
(TRA_243884713, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)
0 ms, 1 read(s), 1 write(s), 1 fetch(es), 1 mark(s)

2012-02-21T19:47:03.9070 (19382:0x7f711824b448) START_TRANSACTION
kmain4trace (ATT_103803, SYSDBA:NONE, WIN1251, TCPv4:192.168.43.42)
C:\Mix\IBE\IBExpert.exe:2252
(TRA_243884714, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)

2012-02-21T19:47:03.9090 (19382:0x7f711824b448) EXECUTE_STATEMENT_START
kmain4trace (ATT_103803, SYSDBA:NONE, WIN1251, TCPv4:192.168.43.42)
C:\Mix\IBE\IBExpert.exe:2252
(TRA_243884714, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)

Statement 9026572:
-------------------------------------------------------------------------------
select rc.rdb$constraint_name,
iseg.rdb$field_name,
i.rdb$index_inactive
from rdb$relation_constraints rc, rdb$index_segments iseg, rdb$indices i
where (iseg.rdb$index_name = rc.rdb$index_name) and (i.rdb$index_name = rc.rdb$index_name)
and (rc.rdb$constraint_type = 'PRIMARY KEY')
and (rc.rdb$relation_name = 'DOC')
order by iseg.rdb$field_position


2012-02-21T19:47:03.9100 (19382:0x7f711824b448) EXECUTE_STATEMENT_FINISH
kmain4trace (ATT_103803, SYSDBA:NONE, WIN1251, TCPv4:192.168.43.42)
C:\Mix\IBE\IBExpert.exe:2252
(TRA_243884714, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)

Statement 9026572:
-------------------------------------------------------------------------------
select rc.rdb$constraint_name,
iseg.rdb$field_name,
i.rdb$index_inactive
from rdb$relation_constraints rc, rdb$index_segments iseg, rdb$indices i
where (iseg.rdb$index_name = rc.rdb$index_name) and (i.rdb$index_name = rc.rdb$index_name)
and (rc.rdb$constraint_type = 'PRIMARY KEY')
and (rc.rdb$relation_name = 'DOC')
order by iseg.rdb$field_position

1 records fetched
0 ms, 7 read(s), 14 fetch(es)

Table Natural Index Update Insert Delete Backout Purge Expunge
***************************************************************************************************************
RDB$INDEX_SEGMENTS 1
RDB$INDICES 1
RDB$RELATION_CONSTRAINTS 1

2012-02-21T19:47:03.9100 (19382:0x7f711824b448) COMMIT_TRANSACTION
kmain4trace (ATT_103803, SYSDBA:NONE, WIN1251, TCPv4:192.168.43.42)
C:\Mix\IBE\IBExpert.exe:2252
(TRA_243884714, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)
0 ms, 1 read(s), 1 write(s), 1 fetch(es), 1 mark(s)

2012-02-21T19:47:03.9120 (19382:0x7f711824b448) START_TRANSACTION
kmain4trace (ATT_103803, SYSDBA:NONE, WIN1251, TCPv4:192.168.43.42)
C:\Mix\IBE\IBExpert.exe:2252
(TRA_243884715, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)

2012-02-21T19:47:03.9150 (19382:0x7f711824b448) EXECUTE_STATEMENT_START
kmain4trace (ATT_103803, SYSDBA:NONE, WIN1251, TCPv4:192.168.43.42)
C:\Mix\IBE\IBExpert.exe:2252
(TRA_243884715, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)

Statement 9026573:
-------------------------------------------------------------------------------
select f.rdb$field_name,
f.rdb$field_source,
f.rdb$null_flag,
f.rdb$default_source,
fs.rdb$null_flag,
fs.rdb$field_name,
fs.rdb$field_type,
fs.rdb$field_length,
fs.rdb$field_scale,
fs.rdb$field_sub_type,
fs.rdb$segment_length,
fs.rdb$dimensions,
d.rdb$dimension,
d.rdb$lower_bound,
d.rdb$upper_bound,
fs.rdb$character_set_id,
f.rdb$collation_id,
cr.rdb$character_set_name,
co.rdb$collation_name,
f.rdb$field_position,
fs.rdb$computed_source,
fs.rdb$character_length,
fs.rdb$default_source,
f.rdb$description,
fs.rdb$collation_id
,fs.rdb$field_precision
from rdb$relation_fields f
left join rdb$fields fs on fs.rdb$field_name = f.rdb$field_source
left join rdb$field_dimensions d on d.rdb$field_name = fs.rdb$field_name
left join rdb$character_sets cr on fs.rdb$character_set_id = cr.rdb$character_set_id
left join rdb$collations co on ((f.rdb$collation_id = co.rdb$collation_id) and
(fs.rdb$character_set_id = co.rdb$character_set_id))
where f.rdb$relation_name = 'DOC'
order by f.rdb$fie...

2012-02-21T19:47:03.9170 (19382:0x7f711824b448) EXECUTE_STATEMENT_FINISH
kmain4trace (ATT_103803, SYSDBA:NONE, WIN1251, TCPv4:192.168.43.42)
C:\Mix\IBE\IBExpert.exe:2252
(TRA_243884715, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)

Statement 9026573:
-------------------------------------------------------------------------------
select f.rdb$field_name,
f.rdb$field_source,
f.rdb$null_flag,
f.rdb$default_source,
fs.rdb$null_flag,
fs.rdb$field_name,
fs.rdb$field_type,
fs.rdb$field_length,
fs.rdb$field_scale,
fs.rdb$field_sub_type,
fs.rdb$segment_length,
fs.rdb$dimensions,
d.rdb$dimension,
d.rdb$lower_bound,
d.rdb$upper_bound,
fs.rdb$character_set_id,
f.rdb$collation_id,
cr.rdb$character_set_name,
co.rdb$collation_name,
f.rdb$field_position,
fs.rdb$computed_source,
fs.rdb$character_length,
fs.rdb$default_source,
f.rdb$description,
fs.rdb$collation_id
,fs.rdb$field_precision
from rdb$relation_fields f
left join rdb$fields fs on fs.rdb$field_name = f.rdb$field_source
left join rdb$field_dimensions d on d.rdb$field_name = fs.rdb$field_name
left join rdb$character_sets cr on fs.rdb$character_set_id = cr.rdb$character_set_id
left join rdb$collations co on ((f.rdb$collation_id = co.rdb$collation_id) and
(fs.rdb$character_set_id = co.rdb$character_set_id))
where f.rdb$relation_name = 'DOC'
order by f.rdb$fie...
55 records fetched
0 ms, 15 read(s), 915 fetch(es)

Table Natural Index Update Insert Delete Backout Purge Expunge
***************************************************************************************************************
RDB$FIELDS 55
RDB$RELATION_FIELDS 55
RDB$CHARACTER_SETS 8
RDB$COLLATIONS 5

2012-02-21T19:47:03.9570 (19382:0x7f711824b448) COMMIT_TRANSACTION
kmain4trace (ATT_103803, SYSDBA:NONE, WIN1251, TCPv4:192.168.43.42)
C:\Mix\IBE\IBExpert.exe:2252
(TRA_243884715, READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE)
0 ms, 1 read(s), 1 write(s), 1 fetch(es), 1 mark(s)
- это сейчас неважно.
Непонятно, почему после этого при прерывании трейса по Ctrl-C на консоли получил:
^CUnknown tag (4) in isc_svc_query() results

Что означает это сообщение ?
21 фев 12, 19:54    [12132939]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
PS. в логе ФБ в этот момент появилось:
firebird        Tue Feb 21 19:48:29 2012
Shutting down the server with 0 active connection(s) to 0 database(s), 1 active service(s)
21 фев 12, 19:55    [12132944]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 6668
Таблоид
Что означает это сообщение ?

недоработка в утилите. Можно занести в трекер, Алекс поправит.
21 фев 12, 22:15    [12133561]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
dimitr
Можно занести в трекер, Алекс поправит.
Done. CORE-3769
22 фев 12, 00:10    [12134113]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Таблоид
Можно ли сделать точность выводимого времени настраиваемой (скажем, до микросекунд) ?
up!
Сейчас любое время показывается до 10 мс. И есть подозрение, что оно НЕ округляется по правилам математики, а просто увеличивается до ближайшего большего "круглого" значения, т.е. 11 мс обратятся в 20 мс.
На это утверждение подталкивают неоднократные замеры по секундомеру и проверочное суммирование выведенного времени в логе трейса.
Секундомер показал, к примеру, 5.94 сек, сумма же значений времени вып-я в трейсе равна 8300 мс.
Суммировал так:
grep "[:blank:]*ms" trace_144122.txt | awk '{SUM +=$1} END {print SUM}'
- а также просто вытащил текст в эксель и проверил там для верности.
6 мар 12, 15:06    [12203869]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
WildSery
Member

Откуда: да, оттуда.
Сообщений: 12826
Таблоид,

Чтобы было что округлять, исходное значение должно быть бОльшей точности. Чего не наличиствует.
6 мар 12, 15:27    [12204102]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
WildSery
исходное значение должно быть бОльшей точности. Чего не наличиствует.
в линухе, в виндузе - везде можно получить системное время с точностью до 1 микросекунды (если не до наносек).
Почему трейс выдаёт (или получает) время в виде двух лаптей по карте ?
6 мар 12, 15:29    [12204126]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
WildSery
Member

Откуда: да, оттуда.
Сообщений: 12826
Таблоид,

Может быть, и можно. Но Firebird не получает.
Почему же трейс должен?
6 мар 12, 15:47    [12204317]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
WildSery
Но Firebird не получает.
ну, я как бы и намекаю: хотелка сильная выросла на получение Firebird'ом точного времени и отражение его в трейсе :-)
6 мар 12, 16:00    [12204467]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 6668
трейс работает с точностью до 1 миллисекунды. Если где-то точность меньше и/или есть округление, то это делает ОС. Слова насчет микро- и нано-секунд весьма наивны, в реальной жизни все совсем не так. Делать точность выше IMHO не имеет смысла, т.к. накладные расходы на замеры времени будут сильно искажать картину.
6 мар 12, 16:00    [12204468]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
dimitr
трейс работает с точностью до 1 миллисекунды. Если где-то точность меньше и/или есть округление, то это делает ОС
ну хорошо, если ОС "поглощает" точность, то почему бы не выводит в каких-нибудь тиках ЦПУ или еще в чём-то, лишь бы картина была более приближенная к реальности ?
dimitr
накладные расходы на замеры времени будут сильно искажать картину.
А вот как-то не очень бросилось в глаза! Делал вчера тестовый рестор 46-гиговой базы с отражением текущего времени:
supertee -tn prod_restored.log gbak -rep production.fbk dummy.fdb -v
- и не было сильного увеличения, всё те же полтора часа (просто ночью всё кажется более долгим :)):

[firebird@firebird firebird]$ head -3 prod_restored.log; tail -3 prod_restored.log
Tue Mar 6 00:37:16 2012: gbak:opened file production.fbk
Tue Mar 6 00:37:16 2012: gbak:transportable backup -- data in XDR format
Tue Mar 6 00:37:16 2012: gbak: backup file is compressed
Tue Mar 6 02:13:13 2012: gbak: activating and creating deferred index DOC_FK2
Tue Mar 6 02:13:14 2012: gbak: committing metadata
Tue Mar 6 02:14:00 2012: gbak:finishing, closing, and going home
6 мар 12, 16:04    [12204526]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 6668
Таблоид
ну хорошо, если ОС "поглощает" точность, то почему бы не выводит в каких-нибудь тиках ЦПУ или еще в чём-то, лишь бы картина была более приближенная к реальности ?

чем тебе это поможет, если ось генерит тики раз в 30 мс, например? Ну таймер у нее так работает.

Таблоид
А вот как-то не очень бросилось в глаза!

я о другом говорю. Нафига выводить микросекунды, если стоимость их получения равна, например, 500 мкс? Что полезного тебе это даст? А пример с рестором вообще дурной, там ЦПУ почти не нагружен.
6 мар 12, 16:12    [12204600]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
dimitr
чем тебе это поможет, если ось генерит тики раз в 30 мс, например? Ну таймер у нее так работает.
это какая ось так грубо со временем обращается ? например, в винде-2000 еще на java 5 делал я какой-то штатный пример из J2SE, в котором выводилось время до наносекунд (System.nanoTime()).
Откуда оно берётся ? неужто после третьего знака рандомами нас потчуют ?
В линухе ls --full-time выдаёт таймштампы тоже с 9 знаками после запятой - значит, и линух тоже "умеет, когда захочет".
6 мар 12, 16:26    [12204740]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
dimitr
А пример с рестором вообще дурной, там ЦПУ почти не нагружен.
Одно из 8 ядер было постоянно загружено, все полтора часа. Примерно на 50-70%.
6 мар 12, 16:36    [12204856]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 6668
есть куча разных способов получения времени от системы. Дефолтный гап между соседними значениями последовательных "тиков" на винде - 10-15 мс, так настроен обработчик прерывания. Для трейса мы используем более точный таймер, у меня на машине его точность составляет ~0.4 мкс. На какой машине ты меряешь и почему оно у тебя округляется до 10 мс, мне отсюда не видно.
6 мар 12, 16:40    [12204909]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
dimitr
На какой машине ты меряешь и почему оно у тебя округляется до 10 мс, мне отсюда не видно.
uname -a
Linux firebird 2.6.33.3-85.fc13.x86_64 #1 SMP Thu May 6 18:09:49 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
И вот что мне в своё время выдал наш линуксоид:
  *-core
description: Motherboard
product: X7DB8
vendor: Supermicro
physical id: 0
version: PCB Version

*-firmware
description: BIOS
vendor: Phoenix Technologies LTD
physical id: 0
version: 6.00
date: 12/03/2007
size: 107KiB
capacity: 960KiB
capabilities: pci pnp upgrade shadowing escd cdboot bootselect edd
int13floppy2880 acpi usb ls120boot zipboot biosbootspecification

*-cpu:0
description: CPU
product: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz
vendor: Intel Corp.
physical id: 4
bus info: cpu@0
slot: LGA771/CPU1
size: 2500MHz
width: 64 bits
capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic
mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx x86-64 constant_tsc arch_perfmon pebs bts rep_good aperfmperf
pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1
lahf_lm tpr_shadow vnmi flexpriority
*-cache
description: L1 cache
physical id: 6
slot: L1 Cache
size: 16KiB
capacity: 16KiB
capabilities: asynchronous internal write-back

etc
6 мар 12, 16:49    [12205028]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
WildSery
Member

Откуда: да, оттуда.
Сообщений: 12826
dimitr
На какой машине ты меряешь и почему оно у тебя округляется до 10 мс, мне отсюда не видно.
А мне показалось, он хочет четвёртую цифру. Это несколько меньше десятков миллисекунд. Раз в сто.
6 мар 12, 17:45    [12205678]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
WildSery
показалось, он хочет четвёртую цифру.
Нет, мне достаточно третьей цифры. Если же её никак не получить, то пусть до 0.01 сек, но главное - избавиться от странного ceil'a значений до ближайшей сотой доли секунды. То есть, 0.01 сек должна отразиться как 10, но никак не 20 мс.
6 мар 12, 17:59    [12205804]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 7293
Таблоид
Откуда оно берётся ? неужто после третьего знака рандомами нас потчуют ?
Ну есть у проца спецрегистры, ну можно их откалибровать ... И что?
6 мар 12, 18:08    [12205867]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Basil A. Sidorov
ну можно их откалибровать ... И что?
просвети, плз, что они содержат ? если на самом деле там точное время, то мне от них надо его с точностью до 0.001 сек. Всё.
6 мар 12, 18:14    [12205893]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 7293
Таблоид
просвети, плз, что они содержат ?
64-разрядные монотонные счётчики.
если на самом деле там точное время, то мне от них надо его с точностью до 0.001 сек. Всё.
Нет там "точного времени". Есть возможность сравнить два очень коротких интервала в задачах типа: "А какой из вариантов развёртывания цикла быстрее?".

P.S. Не надо тебе миллисекундной точности.
6 мар 12, 18:26    [12205954]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Таблоид
Секундомер показал, к примеру, 5.94 сек, сумма же значений времени вып-я в трейсе равна 8300 мс.
пардон муа, глупость я сморозил :-[.
Один из... (страшно даже сказать кто) показал в личке элементарный пример, объясняющий то, что суммарное время по трейсу больше, чем "по часам":
1. start select from sp
2. start select from sp2
3. finish select from sp2, t = 10
4.finish from sp, t = 20

sp вызывает sp2; общее время вып-я будет 20, а не бездумно просуммированное 30.

В общем, вопрос про расхождение в суммах снят.
6 мар 12, 18:36    [12206002]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Что ж, продолжим разговор :-)

session #1: мониторное окно, в нём - старт трейса с параметрами:
  enabled true
log_context true
log_connections true
log_transactions true

log_statement_prepare true
log_statement_free true

log_statement_start true
log_statement_finish true

log_trigger_finish true

log_blr_requests true

print_perf true
print_blr true

time_threshold 0
max_sql_length 4000
max_blr_length 1000
max_dyn_length 1000
max_log_size 0

session #2: isql-окно с неким тяжелым запросом, которое либо срубается "крестиком", либо обламывается командой delete from mon$attachments (из третьего окна), либо прерывается банальным Ctrl-Break:
C:\1INSTALL\FIREBIRD\Data>isql localhost/3050:C:\1INSTALL\FIREBIRD\Data\T1.fdb -n
Database: localhost/3050:C:\1INSTALL\FIREBIRD\Data\T1.fdb
SQL> select count(*) from rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields;
-- гарантированно уйдёт в нирвану, ждем для приличия 20-30 сек, затем прерываем

Trace-1:
+
Trace session ID 7 started
2012-05-10T23:44:27.4530 (580:0202B970) TRACE_INIT

SESSION_7

2012-05-10T23:44:27.4530 (580:0202B970) ATTACH_DATABASE

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_7, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1672



2012-05-10T23:44:27.4680 (580:0202B970) START_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_7, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1672

(TRA_16, CONCURRENCY | WAIT | READ_WRITE)



2012-05-10T23:44:38.1870 (580:0202B970) PREPARE_STATEMENT

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_7, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1672

(TRA_16, CONCURRENCY | WAIT | READ_WRITE)



Statement 257:

-------------------------------------------------------------------------------

select count(*) from rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields

5 ms



2012-05-10T23:44:38.1870 (580:0202B970) EXECUTE_STATEMENT_START

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_7, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1672

(TRA_16, CONCURRENCY | WAIT | READ_WRITE)



Statement 257:

-------------------------------------------------------------------------------

select count(*) from rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields



2012-05-10T23:45:04.1250 (580:0202B970) ROLLBACK_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_7, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1672

(TRA_16, CONCURRENCY | WAIT | READ_WRITE)

0 ms, 1 read(s), 1 write(s), 1 fetch(es), 1 mark(s)



2012-05-10T23:45:04.1250 (580:0202B970) EXECUTE_STATEMENT_FINISH

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_7, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1672

(TRA_16, CONCURRENCY | WAIT | READ_WRITE)



Statement 257:

-------------------------------------------------------------------------------

select count(*) from rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields

0 records fetched

0 ms, 1 read(s), 37969951 fetch(es)



Table Natural Index Update Insert Delete Backout Purge Expunge

***************************************************************************************************************

RDB$FIELDS 18446943



2012-05-10T23:45:04.1250 (580:0202B970) CLOSE_CURSOR

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_7, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1672



Statement 257:

-------------------------------------------------------------------------------

select count(*) from rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields



2012-05-10T23:45:04.1250 (580:0202B970) DETACH_DATABASE

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_7, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1672



2012-05-10T23:45:04.1250 (580:0202B970) FREE_STATEMENT

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_7, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1672



Statement 257:

-------------------------------------------------------------------------------

select count(*) from rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields



2012-05-10T23:45:04.1250 (580:0202B970) TRACE_FINI

SESSION_7
Вопрос-1: почему время выполнения прерванного запроса = 0 мс ?

И второй эксперимент: в том же окне-молотилке вместо select count(*) выполняем:
SQL> out nul;
SQL> select * from rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields;
- и также ждём не менее 30 секунд.
Затем прерываем его работу через delete from mon$attachments where mon$attachment_id<>current_connection; commit;
В трейсе будет видно уже НЕнулевое время, около 7 сек.
Но оно намного меньше, чем то, что фактически прошло! В нижеприведенном логе видно, что:
EXECUTE_STATEMENT_START случился в 2012-05-10T23:59:02.3280
EXECUTE_STATEMENT_FINISH произошёл в 2012-05-10T23:59:48.0310
-- таким обр, прошло 45 сек.
А в трейсе говорится, что молотьба шла якобы 6.9 сек.

Trace-2:
+
Trace session ID 9 started
2012-05-10T23:58:07.6400 (580:0202B970) TRACE_INIT

SESSION_9

2012-05-10T23:58:07.6400 (580:0202B970) ATTACH_DATABASE

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_9, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1668



2012-05-10T23:58:07.6560 (580:0202B970) START_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_9, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1668

(TRA_18, CONCURRENCY | WAIT | READ_WRITE)



2012-05-10T23:59:02.3280 (580:0202B970) PREPARE_STATEMENT

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_9, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1668

(TRA_18, CONCURRENCY | WAIT | READ_WRITE)



Statement 337:

-------------------------------------------------------------------------------

select * from rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields

6 ms



2012-05-10T23:59:02.3280 (580:0202B970) EXECUTE_STATEMENT_START

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_9, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1668

(TRA_18, CONCURRENCY | WAIT | READ_WRITE)



Statement 337:

-------------------------------------------------------------------------------

select * from rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields



2012-05-10T23:59:48.0150 (580:0202D67C) TRACE_INIT

SESSION_9





2012-05-10T23:59:48.0150 (580:0202D67C) START_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_3, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1188

(TRA_19, CONCURRENCY | WAIT | READ_WRITE)



2012-05-10T23:59:48.0150 (580:0202D67C) START_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_3, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1188

(TRA_20, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



2012-05-10T23:59:48.0150 (580:0202D67C) PREPARE_STATEMENT

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_3, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1188

(TRA_20, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



Statement 84:

-------------------------------------------------------------------------------

delete from mon$attachments where mon$attachment_id<>current_connection

0 ms



2012-05-10T23:59:48.0150 (580:0202D67C) EXECUTE_STATEMENT_START

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_3, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1188

(TRA_19, CONCURRENCY | WAIT | READ_WRITE)



Statement 84:

-------------------------------------------------------------------------------

delete from mon$attachments where mon$attachment_id<>current_connection



2012-05-10T23:59:48.0150 (580:0202D67C) EXECUTE_STATEMENT_FINISH

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_3, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1188

(TRA_19, CONCURRENCY | WAIT | READ_WRITE)



Statement 84:

-------------------------------------------------------------------------------

delete from mon$attachments where mon$attachment_id<>current_connection

0 records fetched

2 ms, 1 read(s), 1 fetch(es)



2012-05-10T23:59:48.0150 (580:0202D67C) FREE_STATEMENT

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_3, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1188



Statement 84:

-------------------------------------------------------------------------------

delete from mon$attachments where mon$attachment_id<>current_connection



2012-05-10T23:59:48.0150 (580:0202D67C) COMMIT_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_3, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1188

(TRA_19, CONCURRENCY | WAIT | READ_WRITE)

1 ms, 1 read(s), 1 write(s), 1 fetch(es), 1 mark(s)



2012-05-10T23:59:48.0150 (580:0202D67C) COMMIT_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_3, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1188

(TRA_20, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)

0 ms, 1 read(s), 1 write(s), 1 fetch(es), 1 mark(s)



2012-05-10T23:59:48.0310 (580:0202B970) EXECUTE_STATEMENT_FINISH

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_9, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1668

(TRA_18, CONCURRENCY | WAIT | READ_WRITE)



Statement 337:

-------------------------------------------------------------------------------

select * from rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields

83600 records fetched

6936 ms, 1 read(s), 173531 fetch(es)



Table Natural Index Update Insert Delete Backout Purge Expunge

***************************************************************************************************************

RDB$FIELDS 84306

RDB$CHARACTER_SETS 1

RDB$COLLATIONS 1



2012-05-10T23:59:48.0310 (580:0202B970) CLOSE_CURSOR

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_9, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1668



Statement 337:

-------------------------------------------------------------------------------

select * from rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields



2012-05-10T23:59:48.0310 (580:0202B970) DETACH_DATABASE

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_9, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1668



2012-05-10T23:59:48.0310 (580:0202B970) FREE_STATEMENT

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_9, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1668



Statement 337:

-------------------------------------------------------------------------------

select * from rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields,rdb$fields



2012-05-10T23:59:48.0310 (580:0202B970) TRACE_FINI

SESSION_9
Вопрос-2: почему время в статистике запроса, хоть и ненулевое, но совершенно нереальное ?
11 май 12, 00:11    [12533464]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
Вопрос-1: почему время выполнения прерванного запроса = 0 мс ?
Потому что бага

Таблоид
Вопрос-2: почему время в статистике запроса, хоть и ненулевое, но совершенно нереальное ?
Потому что трейс считает только время, проведенное в движке.
А isql учитывает :
- время на трансфер данных между сетевым сервером и движком
- время на трансфер данных между приложениями
- время на обработку данных самим isql
11 май 12, 01:58    [12533713]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
Таблоид
Вопрос-2: почему время в статистике запроса, хоть и ненулевое, но совершенно нереальное ?
Потому что трейс считает только время, проведенное в движке.
А isql учитывает :
- время на трансфер данных между сетевым сервером и движком
- время на трансфер данных между приложениями
- время на обработку данных самим isql
Да, но данных в этой таблице (rdb$fields) - кот накакал: not_null значений во всех блоб-полях только 4, и все - по несколько байт; два (var)char-поля из трёх (query_name, edit_string) - все null. Остальные поля - smallint, причем только 4 столбца заполнены целиком (field_len, field_scale, field_type & system_flag). Остальные - опять-таки по большей части null'ы.

Повторил эксперимент, но для таблицы с единственным smallint-полем и 120 строками.
DDL:
recreate table t(id smallint);
commit;
insert into t select rdb$system_flag from rdb$fields;
select count(*) from t;
commit;
quit;

Test:
C:\1INSTALL\FIREBIRD\Data>isql localhost/3050:C:\1INSTALL\FIREBIRD\Data\T1.fdb -n
Database: localhost/3050:C:\1INSTALL\FIREBIRD\Data\T1.fdb
SQL> out nul;
SQL> select a.id from t a,t b,t c,t d,t e,t f; -- передаём "на клиента" только одно smallint-поле

Теперь ждём три минуты, затем прерываем из другого окна по delete from mon$attachments.
Смотрим после этого в трейс: он показывает, что время "в движке" составило всего 48 сек! И это при том, что данные таблицы никуда на самом деле не выводились (всё перенаправлялось в nul). Передача значений smallint-поля (это же два байта всего) заняла в два с лишним раза больше, чем их извлечение движком...
+
Trace session ID 2 started
2012-05-11T08:48:00.4060 (584:0202C0C0) TRACE_INIT

SESSION_2





2012-05-11T08:48:00.4060 (584:0202C0C0) PREPARE_STATEMENT

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_24, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1632

(TRA_122, CONCURRENCY | WAIT | READ_WRITE)



Statement 707:

-------------------------------------------------------------------------------

select a.id from t a,t b,t c,t d,t e,t f

5 ms



2012-05-11T08:48:00.4060 (584:0202C0C0) EXECUTE_STATEMENT_START

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_24, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1632

(TRA_122, CONCURRENCY | WAIT | READ_WRITE)



Statement 707:

-------------------------------------------------------------------------------

select a.id from t a,t b,t c,t d,t e,t f



2012-05-11T08:51:00.5930 (584:0202ADCC) TRACE_INIT

SESSION_2





2012-05-11T08:51:00.6090 (584:0202ADCC) PREPARE_STATEMENT

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_25, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1688

(TRA_124, CONCURRENCY | WAIT | READ_WRITE)



Statement 721:

-------------------------------------------------------------------------------

delete from mon$attachments where mon$attachment_id<>current_connection

5 ms



2012-05-11T08:51:00.6090 (584:0202ADCC) EXECUTE_STATEMENT_START

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_25, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1688

(TRA_124, CONCURRENCY | WAIT | READ_WRITE)



Statement 721:

-------------------------------------------------------------------------------

delete from mon$attachments where mon$attachment_id<>current_connection



2012-05-11T08:51:00.6250 (584:0202ADCC) EXECUTE_STATEMENT_FINISH

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_25, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1688

(TRA_124, CONCURRENCY | WAIT | READ_WRITE)



Statement 721:

-------------------------------------------------------------------------------

delete from mon$attachments where mon$attachment_id<>current_connection

0 records fetched

12 ms, 1 read(s), 73 fetch(es)



Table Natural Index Update Insert Delete Backout Purge Expunge

***************************************************************************************************************

RDB$RELATIONS 16

RDB$CHARACTER_SETS 1

RDB$COLLATIONS 1



2012-05-11T08:51:00.6250 (584:0202ADCC) FREE_STATEMENT

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_25, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1688



Statement 721:

-------------------------------------------------------------------------------

delete from mon$attachments where mon$attachment_id<>current_connection



2012-05-11T08:51:00.6250 (584:0202ADCC) COMMIT_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_25, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1688

(TRA_124, CONCURRENCY | WAIT | READ_WRITE)

0 ms, 1 read(s), 1 write(s), 1 fetch(es), 1 mark(s)



2012-05-11T08:51:00.6870 (584:0202C0C0) EXECUTE_STATEMENT_FINISH

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_24, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1632

(TRA_122, CONCURRENCY | WAIT | READ_WRITE)



Statement 707:

-------------------------------------------------------------------------------

select a.id from t a,t b,t c,t d,t e,t f

4979394 records fetched

47900 ms, 1 read(s), 10249266 fetch(es)



Table Natural Index Update Insert Delete Backout Purge Expunge

***************************************************************************************************************

RDB$CHARACTER_SETS 1

RDB$COLLATIONS 1

T 5020893



2012-05-11T08:51:00.6870 (584:0202C0C0) CLOSE_CURSOR

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_24, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1632



Statement 707:

-------------------------------------------------------------------------------

select a.id from t a,t b,t c,t d,t e,t f



2012-05-11T08:51:00.6870 (584:0202C0C0) DETACH_DATABASE

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_24, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1632



2012-05-11T08:51:00.6870 (584:0202C0C0) FREE_STATEMENT

C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_24, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1632



Statement 707:

-------------------------------------------------------------------------------

select a.id from t a,t b,t c,t d,t e,t f



2012-05-11T08:51:00.6870 (584:0202C0C0) TRACE_FINI

SESSION_2

PS. ПОЛУОФФ. gstat -r -t для rdb$-таблиц не работает, что ли ?
+
C:\1INSTALL\FIREBIRD\Data>gstat -r -t RDB$FIELDS T1.FDB > ttt
table "RDB$FIELDS" not found

C:\1INSTALL\FIREBIRD\Data>gstat -r -t "RDB$FIELDS" T1.FDB > ttt
table "RDB$FIELDS" not found

C:\1INSTALL\FIREBIRD\Data>gstat -r -t rdb$fields T1.FDB > ttt
table "rdb$fields" not found

C:\1INSTALL\FIREBIRD\Data>gstat -r -t "rdb$fields" T1.FDB > ttt
table "rdb$fields" not found

C:\1INSTALL\FIREBIRD\Data>gstat -r -t "RDB\$FIELDS" T1.FDB > ttt
table "RDB\$FIELDS" not found

C:\1INSTALL\FIREBIRD\Data>gstat -r -t RDB\$FIELDS T1.FDB > ttt
table "RDB\$FIELDS" not found
11 май 12, 08:56    [12533981]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
Теперь ждём три минуты, затем прерываем из другого окна по delete from mon$attachments.
Смотрим после этого в трейс: он показывает, что время "в движке" составило всего 48 сек! И это при том, что данные таблицы никуда на самом деле не выводились (всё перенаправлялось в nul)
Ага, не выводились. Из движка в y-valve, из y-valve в сетевой редиректор, потом через сеть потом в клиентский сетевой редиректор, потом в клиентский y-valve, потом в isql, потом в строку, потом в nul - мало ?
Кроме того, я же сказал, что при прерывании запроса время не считается правильно.

Таблоид
Передача значений smallint-поля (это же два байта всего) заняла в два с лишним раза больше, чем их извлечение движком...
Ну так движок рулит, что плохого ? :)
11 май 12, 11:17    [12534795]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
gstat -r -t для rdb$-таблиц не работает, что ли ?
Борманов спрашивай, они это делали...
11 май 12, 11:18    [12534802]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
Из движка в y-valve, из y-valve в сетевой редиректор, потом через сеть потом в клиентский сетевой редиректор, потом в клиентский y-valve, потом в isql, потом в строку, потом в nul - мало ?
Судя по перечисленному (5 посредников) - не мало, конечно. Но всё равно неожиданно сильная "помеха" от них.
Надо будет проверить еще и DML, а не только селект.
11 май 12, 12:16    [12535326]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
Кроме того, я же сказал, что при прерывании запроса время не считается правильно.
Оно странно выглядит также и в следующем случае:
C:\MIX\firebird\fb25>isql localhost/3050:C:\MIX\firebird\fb25\T1.FDB
Database: localhost/3050:C:\MIX\firebird\fb25\T1.FDB
SQL> out nul;
SQL> select a.id from t a,t b,t c; -- около 1.7 млн записей, дождаться окончания вполне реально. Ждём-c.
SQL> out;

Трейс:
+
Trace session ID 4 started
2012-05-11T16:48:50.9060 (592:022FDDF8) TRACE_INIT

SESSION_4





2012-05-11T16:48:50.9060 (592:022FDDF8) ATTACH_DATABASE

C:\MIX\FIREBIRD\FB25\T1.FDB (ATT_10, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\MIX\firebird\fb25\bin\isql.exe:1632



2012-05-11T16:48:50.9060 (592:022FDDF8) START_TRANSACTION

C:\MIX\FIREBIRD\FB25\T1.FDB (ATT_10, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\MIX\firebird\fb25\bin\isql.exe:1632

(TRA_23, CONCURRENCY | WAIT | READ_WRITE)



2012-05-11T16:48:50.9060 (592:022FDDF8) START_TRANSACTION

C:\MIX\FIREBIRD\FB25\T1.FDB (ATT_10, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\MIX\firebird\fb25\bin\isql.exe:1632

(TRA_24, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



2012-05-11T16:48:56.9210 (592:022FDDF8) PREPARE_STATEMENT

C:\MIX\FIREBIRD\FB25\T1.FDB (ATT_10, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\MIX\firebird\fb25\bin\isql.exe:1632

(TRA_24, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)



Statement 419:

-------------------------------------------------------------------------------

select a.id from t a,t b,t c

5 ms



2012-05-11T16:48:56.9210 (592:022FDDF8) EXECUTE_STATEMENT_START

C:\MIX\FIREBIRD\FB25\T1.FDB (ATT_10, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\MIX\firebird\fb25\bin\isql.exe:1632

(TRA_23, CONCURRENCY | WAIT | READ_WRITE)



Statement 419:

-------------------------------------------------------------------------------

select a.id from t a,t b,t c



2012-05-11T16:50:00.2960 (592:022FDDF8) EXECUTE_STATEMENT_FINISH

C:\MIX\FIREBIRD\FB25\T1.FDB (ATT_10, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\MIX\firebird\fb25\bin\isql.exe:1632

(TRA_23, CONCURRENCY | WAIT | READ_WRITE)



Statement 419:

-------------------------------------------------------------------------------

select a.id from t a,t b,t c

1771561 records fetched

29173 ms, 1 read(s), 3646469 fetch(es)



Table Natural Index Update Insert Delete Backout Purge Expunge

***************************************************************************************************************

RDB$CHARACTER_SETS 1

RDB$COLLATIONS 1

T 1786323



2012-05-11T16:50:00.3750 (592:022FDDF8) CLOSE_CURSOR

C:\MIX\FIREBIRD\FB25\T1.FDB (ATT_10, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

C:\MIX\firebird\fb25\bin\isql.exe:1632



Statement 419:

-------------------------------------------------------------------------------

select a.id from t a,t b,t c
- то есть, "в движке" всё делалось якобы за 29173 мс.
А теперь смотрим на значения моментов времени начала и окончания вып-я запроса, те что я выделил синим цветом:
SQL> select datediff(millisecond from timestamp '11.05.2012 16.48.56.921' to timestamp '11.05.2012 16:50:00.296') 
CON> from rdb$database;

DATEDIFF
=====================
63375
11 май 12, 17:01    [12538031]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Dzirt
Member

Откуда:
Сообщений: 526
Таблоид,

почему бы тебе вместо
select a.id from t a,t b,t c;

не сделать
select count(*) from t a,t b,t c;

? Уберешь время передачи данных клиенту, при таком раскладе практически все время должно быть временем отработки запроса в движке.
11 май 12, 17:19    [12538144]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Dzirt
при таком раскладе практически все время должно быть временем отработки запроса в движке.
Оно понятно, только "одиночный count" (одна строка с результатом) гораздо реже возвращается, чем сами данные.
А при передаче данных даже без сети, как выясняется, эти данным приходится через тучу посредников проходить.
И даже при отключке TCP-стека, т.е. работе по XNET, ощутимо влияние этих посредников: трейс говорит, что без tcp-стека "в движке" всё выполнялось 28.3 сек, а на самом деле это длилось 58,3 сек:
+
2012-05-11T17:27:37.3900 (592:022FDDF8) EXECUTE_STATEMENT_START

C:\MIX\FIREBIRD\FB25\T1.FDB (ATT_11, SYSDBA:NONE, NONE, XNET:CSPROG)

C:\MIX\firebird\fb25\bin\isql.exe:1672

(TRA_25, CONCURRENCY | WAIT | READ_WRITE)



Statement 467:

-------------------------------------------------------------------------------

select a.id from t a,t b,t c



2012-05-11T17:28:35.7810 (592:022FDDF8) EXECUTE_STATEMENT_FINISH

C:\MIX\FIREBIRD\FB25\T1.FDB (ATT_11, SYSDBA:NONE, NONE, XNET:CSPROG)

C:\MIX\firebird\fb25\bin\isql.exe:1672

(TRA_25, CONCURRENCY | WAIT | READ_WRITE)



Statement 467:

-------------------------------------------------------------------------------

select a.id from t a,t b,t c

1771561 records fetched

28368 ms, 1 read(s), 3646469 fetch(es)



Table Natural Index Update Insert Delete Backout Purge Expunge

***************************************************************************************************************

RDB$CHARACTER_SETS 1

RDB$COLLATIONS 1

T 1786323

SQL> select datediff(millisecond from timestamp '11.05.2012 17:27:37.390' to timestamp '11.05.2012 17:28:35.781') f
rom rdb$database;

DATEDIFF
=====================
58391
Из этого и предыдущего примера, кстати, видно, что затраты проход через TCP-стек - минимальные.
Настоящая тёмная материя - это y_valve и редиректор.
11 май 12, 17:42    [12538249]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Dzirt
Таблоид,

почему бы тебе вместо
select a.id from t a,t b,t c;

не сделать
select count(*) from t a,t b,t c;
Сделал и это (только добавил еще одну таблицу в кросс-джойн, а то с тремя очень быстро получилось).
Итог: данные статистики трейса практически совпали с разницей моментов execute_statement_start & _finish:
+
2012-05-11T17:30:18.5780 (592:022FC6FC) EXECUTE_STATEMENT_START

C:\MIX\FIREBIRD\FB25\T1.FDB (ATT_11, SYSDBA:NONE, NONE, XNET:CSPROG)

C:\MIX\firebird\fb25\bin\isql.exe:1672

(TRA_25, CONCURRENCY | WAIT | READ_WRITE)



Statement 470:

-------------------------------------------------------------------------------

select count(a.id) from t a,t b,t c,t d



2012-05-11T17:36:58.4370 (592:022FC6FC) EXECUTE_STATEMENT_FINISH

C:\MIX\FIREBIRD\FB25\T1.FDB (ATT_11, SYSDBA:NONE, NONE, XNET:CSPROG)

C:\MIX\firebird\fb25\bin\isql.exe:1672

(TRA_25, CONCURRENCY | WAIT | READ_WRITE)



Statement 470:

-------------------------------------------------------------------------------

select count(a.id) from t a,t b,t c,t d

1 records fetched

399864 ms, 441222028 fetch(es)



Table Natural Index Update Insert Delete Backout Purge Expunge

***************************************************************************************************************

T 216145204

Check:
SQL> select datediff(millisecond from timestamp '11.05.2012 17:30:18.578' to timestamp '11.05.2012 17:36:58.437') 
CON> from rdb$database;

DATEDIFF
=====================
399859
11 май 12, 17:48    [12538273]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 43636

Таблоид
даже при отключке TCP-стека, т.е. работе по XNET, ощутимо влияние этих посредников

Потому что в XNET задействована точно та же самая цепочка, что и в TCP.

Posted via ActualForum NNTP Server 1.5

11 май 12, 18:09    [12538409]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Давно мечтал спросить, да всё как-то стеснялся.
Вот фрагмент трейса:
2012-05-25T18:15:57.8270 (1264:01F3BE6C) ATTACH_DATABASE
C:\MIX\FIREBIRD\FB25\T1.FDB (ATT_25, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
C:\MIX\firebird\fb25.2\bin\isql.exe:1584

2012-05-25T18:15:57.8270 (1264:01F3BE6C) START_TRANSACTION
C:\MIX\FIREBIRD\FB25\T1.FDB (ATT_25, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
C:\MIX\firebird\fb25.2\bin\isql.exe:1584
(TRA_266, CONCURRENCY | WAIT | READ_WRITE)

2012-05-25T18:16:02.4200 (1264:01F3BE6C) START_TRANSACTION
C:\MIX\FIREBIRD\FB25\T1.FDB (ATT_25, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
C:\MIX\firebird\fb25.2\bin\isql.exe:1584
(TRA_267, CONCURRENCY | WAIT | READ_WRITE)

1) Что указывается в скобках ? Почему это число всё время одинаковое во всех блоках ?
2) Можно ли снабжать неким уникальным маркером каждый блок инфы, например:
2012-05-25T18:15:57.8270 (1264:01F3BE6C) ATTACH_DATABASE (00000161)
....
2012-05-25T18:15:57.8270 (1264:01F3BE6C) START_TRANSACTION (00000162)
...
etc
25 май 12, 18:22    [12617610]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
1) Что указывается в скобках ? Почему это число всё время одинаковое во всех блоках ?
Идентификатор данной трейс-сессии в данном аттаче (или сервисе). Все сообщения с данным ид относятся к одному и тому же аттачу\сессии.
Теоритически, может использоваться повторно

Таблоид
2) Можно ли снабжать неким уникальным маркером каждый блок инфы
Можно, но это будет стоить немножко скорости в рантайме. Оно того не стоит, имхо.
25 май 12, 21:35    [12618318]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
это будет стоить немножко скорости в рантайме. Оно того не стоит, имхо.
но ведь так легче ссылаться на блоки, ибо они будут однозначно идентифицированы.
Скорость в рантайме теряется и сейчас на "наладные расходы" вида отчеркивающих линий (80 знаков у "---...----" и 111 знаков у "***...***").
25 май 12, 23:36    [12618631]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
но ведь так легче ссылаться на блоки, ибо они будут однозначно идентифицированы.
Ничего не понял

Таблоид
Скорость в рантайме теряется и сейчас на "наладные расходы" вида отчеркивающих линий (80 знаков у "---...----" и 111 знаков у "***...***").
Лишь бы поспорить ?
Ты мерял расходы на эти линии и на конкурентный межпроцессный счётчик ?
25 май 12, 23:57    [12618680]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
Ничего не понял
есть блоки, у которых проставлены совершенно одинаковые моменты времени в виду точности до 10 мс. Например, могут быть два одинаковых exe_trigger_finish'a с одинаковым временем (для db_level-триггера). Как их различить, когда идёт разбор полётов с коллегами (а я их устраиваю периодически :)) ? пальцем тыркать или копипастить в word и цветом выделять ?

hvlad
Ты мерял расходы на эти линии и на конкурентный межпроцессный счётчик ?
Поясни, о какой конкуренции идёт речь ? лог трейса заполняется развене одним процессом, имя которому = fbtracemgr ?
26 май 12, 00:17    [12618737]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
есть блоки, у которых проставлены совершенно одинаковые моменты времени в виду точности до 10 мс. Например, могут быть два одинаковых exe_trigger_finish'a с одинаковым временем (для db_level-триггера). Как их различить
Они, вообще-то, друг за другом в файле лога идут.
Можешь отличать по смещению или номеру строки, разрешаю

Да и имена у двух db-level триггеров не могут совпадать...

Таблоид
лог трейса заполняется развене одним процессом, имя которому = fbtracemgr ?
OMG

fbtracemgr
только
читает
лог
используя
сервисы

А пишут его все процессы с движком внутри - как сервер, так и embedded
26 май 12, 00:39    [12618783]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
Можешь отличать по смещению или номеру строки, разрешаю
гы... а какое "смещение или номер строки" можно указать при публикации фрагмента трейса тут, на форуме ?
Или, допустим, я выслал своему коллеге часть трейса, начинающуюся НЕ с начала. Он тогда видит строки с совсем другими номерами, чем я.
В общем - надо таки нумеровать блоки... :-)
26 май 12, 00:45    [12618795]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 43636

Таблоид
допустим, я выслал своему коллеге часть трейса, начинающуюся НЕ с начала

Никогда не высылай обрывки логов. Чаще всего они бесполезны.

Posted via ActualForum NNTP Server 1.5

26 май 12, 00:53    [12618814]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
В общем - надо таки нумеровать блоки... :-)
Нумеруй, я тут при чём ?

Я не понимаю, к чему ты прицепился на этот раз ???
26 май 12, 01:04    [12618833]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
Нумеруй, я тут при чём ?
чем нумеровать, шариковой ручкой что ли ? и что значит "я тут причем" ?! как будто кто-то еще в природе туда полезет.
hvlad
Я не понимаю, к чему ты прицепился на этот раз ???
Очень прошу: введи опцию в fbtrace.conf, что-то типа: numerate_blocks, по дефолту = false. Кому надо, включат.
26 май 12, 01:08    [12618843]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Должен ли fbtracemgr, к которому я стучусь вот так:
%fb_25_instance_3051_home%\bin\fbtracemgr -sta -c zaudit.conf -se localhost/3051:service_mgr | mtee trc.txt
- выводить активность в базе, которая открыта в соседнем инстансе (3050):
C:\MIX\firebird\fb25>C:\MIX\firebird\fb25\bin\isql -n localhost/3050:C:\MIX\firebird\fb25\T1.FDB
Database: localhost/3050:C:\MIX\firebird\fb25\T1.FDB
SQL>
-----------
Трейс по порту 3051:
Trace session ID 13 started
2012-05-29T20:12:21.9110 (1936:020EBEB0) TRACE_INIT
SESSION_13


2012-05-29T20:12:21.9110 (1936:020EBEB0) ATTACH_DATABASE
C:\MIX\FIREBIRD\FB25\T1.FDB (ATT_52, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
C:\MIX\firebird\fb25\bin\isql.exe:1528

2012-05-29T20:12:21.9110 (1936:020EBEB0) START_TRANSACTION
C:\MIX\FIREBIRD\FB25\T1.FDB (ATT_52, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
C:\MIX\firebird\fb25\bin\isql.exe:1528
(TRA_368, CONCURRENCY | WAIT | READ_WRITE)
--------
29 май 12, 20:17    [12634070]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид,

должен
29 май 12, 20:28    [12634096]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad,

а как сделать, чтобы "временно не мог" ? неудобно же...
29 май 12, 20:29    [12634100]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид,

трассировать не всё подряд, а напрячься и создать нужный фильтр.
По имени БД, например.
29 май 12, 21:02    [12634176]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad, это очевидное решение.

Не понятно другое: почему игнорируется номер порта (-se localhost/3051:service_mgr).
29 май 12, 21:12    [12634202]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
А с чего бы он не должен игнорироваться ?
29 май 12, 22:39    [12634435]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
А с чего бы он не должен игнорироваться ?
кхм... ну, вроде как два инстанса не должны вообще знать что-либо друг о друге, разве не так ?
Как минимум настраивать хотелось бы этот "уровень любознательности", а не видеть в одном логе кашу из работы двух и более инстансов.

ЗЫ. А если у мну будет на одной тачке ФБ 2.5 и ФБ 3.х - то что, "младшенький" будет так же спокойно видеть всю деятельность "старшенького" ? А если последний (3.х) делает нечто, неведомое 2.5 - тогда что будет c "младшеньким", не поплохеет ему ?
29 май 12, 22:54    [12634474]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
кхм... ну, вроде как два инстанса не должны вообще знать что-либо друг о друге, разве не так ?
А где ты нашёл два инстанса ?

Таблоид
Как минимум настраивать хотелось бы этот "уровень любознательности"
Настраивай, кто тебе не даёт ?

Таблоид
а не видеть в одном логе кашу из работы двух и более инстансов.
Ну давай тогда сразу всех embedded выкинем - ибо как их трассировать, если ты не разрешаешь ?
29 май 12, 22:59    [12634485]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
Таблоид
кхм... ну, вроде как два инстанса не должны вообще знать что-либо друг о друге, разве не так ?
А где ты нашёл два инстанса ?
А у себя на машинке и нашёл. Вот:
-- список служб
C:\>REG.EXE query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services | findstr /i /c:"firebird" /
[FirebirdServerFB_25]
[FirebirdServerfb_25_3051]
-- исполняемый образ для первой:
C:\>REG.EXE query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FirebirdServerFB_25 | findstr /i /c:"ImagePath"
EXPAND_SZ ImagePath C:\MIX\firebird\fb25\bin\fb_inet_server.exe -s FB_25 -m
-- исполняемый образ для второй:
C:\>REG.EXE query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FirebirdServerfb_25_3051 | findstr /i /c:"ImagePath"
EXPAND_SZ ImagePath C:\MIX\firebird\fb25.2\bin\fb_inet_server.exe -s fb_25_3051 -m
-- порт прослушивания для первой:
C:\>type C:\MIX\firebird\fb25\firebird.conf | findstr "RemoteServicePort"
# found in the 'services.' file) then the 'RemoteServicePort'.
#RemoteServicePort = 3050
-- порт прослушивания для второй:
C:\>type C:\MIX\firebird\fb25.2\firebird.conf | findstr "RemoteServicePort"
# found in the 'services.' file) then the 'RemoteServicePort'.
RemoteServicePort = 3051
hvlad
Таблоид
Как минимум настраивать хотелось бы этот "уровень любознательности"
Настраивай, кто тебе не даёт ?
В ГДЕ ?? ткни носом в параметр fbtrace.conf'a, запрещающий видеть активность на порту номер NNNN (или разрешающий на порту номер MMMM).
Если тута:
	# Services filters.
#
# Only services whose names fall under given regular expression are
# reported in the log.
#include_filter
- то как надо написать, пример можешь показать ?

hvlad
Таблоид
а не видеть в одном логе кашу из работы двух и более инстансов.
Ну давай тогда сразу всех embedded выкинем - ибо как их трассировать, если ты не разрешаешь ?
Эти пусть все валятся в одно ведро, с ними по-другому не получится. Но TCP-коннекты - их ведь можно разрулить ?
29 май 12, 23:27    [12634550]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид,

я тебе выше показал как достичь желаемого.
Не нравится - ничем не могу помочь.
30 май 12, 00:33    [12634750]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 26550
hvlad, что-то я юмора последних двух страниц этого топика не улавливаю. Трейсменеджер ведь не может подключиться ко всем неизвестным портам на компе (или к нескольким сразу). Значит, указание порта 3051 игнорируется, и используется 3050. Но это значит, что Таблоид не может видеть в трейсе обращение к "инстансу" 3051. А?
30 май 12, 00:52    [12634820]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Трейс глобален, точка.

Он может в некоторых случаях не "подключиться" только к тем экземплярам движка, которые работают в другой windows session.
30 май 12, 01:00    [12634837]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 26550
hvlad
Трейс глобален, точка.

я подозревал что оно так (и как), но в релизнотах не нашел, потому что в той ссылке не написано слово fbtracemgr :-)
30 май 12, 01:05    [12634844]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
kdv
в той ссылке не написано слово fbtracemgr
Ну при чём тут fbtracemgr ?
Ты же не делаешь выводы о том, как работает движок, глядя на isql ?
30 май 12, 01:09    [12634851]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 26550
hvlad
Ты же не делаешь выводы о том, как работает движок, глядя на isql ?

о том, как работает fbtracemgr - делаю.
30 май 12, 10:26    [12635649]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Подниму-ка этот топик.

Был тут тест один сделан. И в итоге выяснилось, что при огромных зазорах Next-OIT свип может завязнуть в своём благородном деле на несколько (если не сказать: много) часов. Да так завязнуть, что нельзя остановить ФБ-службу и даже обратиться к системным или мониторным таблицам. Более того, нельзя вообще создать второе и последующие подключения - ждал несколько минут, не получилось.

В трейсе при этом показывается, что он выполнил анализ таблицы rdb$roles (последней из системных таблиц - других в той базе не было), а дальше - многочасовая тишина.

2 hvlad: нельзя ли в лог трейса (или в firebird.log) хоть что-то выводить раз в NN минут, когда идёт такая молотьба ?
27 авг 12, 14:42    [13069932]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 6668
Таблоид,

Влад в отпуске :-) А по сути предлагаю трейс не трогать, а молотьбу оптимизировать.
27 авг 12, 14:44    [13069954]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
dimitr
трейс не трогать, а молотьбу оптимизировать.
я не против, если при этом можно будет еще создавать к такой базе второй и последующие коннекты! совершенно неожиданно, что она пускает к себе только "по одному".
27 авг 12, 14:47    [13069984]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Таблоид
dimitr
трейс не трогать, а молотьбу оптимизировать.
я не против, если при этом можно будет еще создавать к такой базе второй и последующие коннекты! совершенно неожиданно, что она пускает к себе только "по одному".
PS. тут вылез очередной кошмар: пока этот свип молотит на базе 't0.fdb', я не могу подключиться не только к ней, но и вообще ни к какой другой базе этой машины! Ужос...
27 авг 12, 15:17    [13070289]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
pastor
Member

Откуда: Калуга
Сообщений: 884
Таблоид
Таблоид
пропущено...
я не против, если при этом можно будет еще создавать к такой базе второй и последующие коннекты! совершенно неожиданно, что она пускает к себе только "по одному".
PS. тут вылез очередной кошмар: пока этот свип молотит на базе 't0.fdb', я не могу подключиться не только к ней, но и вообще ни к какой другой базе этой машины! Ужос...


Это не Ужос- это Super/SuperClassic.

Я из-за этого перешел на классик на больших объектах.
27 авг 12, 15:32    [13070427]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
pastor
Я из-за этого перешел на классик на больших объектах.
но можно ведь второй инстанс поставить и коннектиться через него :-)
27 авг 12, 15:44    [13070568]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
2 hvlad: наконец-то я понял, отчего мне так грустно!
Надо обязательно выводить в первых строках лога трейса те параметры конфига, которые сейчас активны.
То есть, для такого вот файла конфига:
<database (%[\\/](k`main_offline|kmain_snapshot|rep`lcfg|t_|k`main4ora|t`est%).fdb)|(k`repl|kuntsevomain|k`main4trace)>
enabled true
log_filename /var/db/firebird/trace/prodtrace.log

#################### A C H T U N G ##############
connection_id=6951624
time_threshold 50
####################################################

log_connections true
log_transactions true

# log_statement_prepare true
# log_statement_start true
# log_statement_free true
# log_trigger_start true
# log_procedure_start true

log_statement_finish true
log_procedure_finish true
log_trigger_finish true

# print_plan true
print_perf true
max_sql_length 8192
max_log_size 500000

# 20.06.2012, temply:
# log_blr_requests true
# print_blr true
# log_dyn_requests true
# print_dyn true

</database>
- надо вывести
1) фильтр в секции <database>
2) фильтр include/exclude (если он есть)
3) все остальные незакомментаренные параметры.
Ибо сижу, жду когда там инфа появится, и забыл вот про это совсем:
  connection_id=6951624
- а этот фильтр был сделан утром, когда был соотв-щий коннект.

Ы ?
2 окт 12, 23:17    [13258857]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
2 hvlad: наконец-то я понял, отчего мне так грустно!
Поздравляю, наконец-то ты понял.
4 окт 12, 01:26    [13265016]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad,

"вы не ответили на мой вопрос относительно магнитофона" (С) :-)
4 окт 12, 08:45    [13265321]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид,

от жеж, незадача, - я-то думал, что ты понял...
4 окт 12, 12:44    [13266876]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
от жеж, незадача, - я-то думал, что ты понял...
Ты мне прямо, по-пролетарски скажи: вывод параметров конфига в первых строках трейса - это религиозный вопрос или нет ? Если нет, то почему нельзя это сделать ?
4 окт 12, 12:51    [13266959]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид,

а давай после 3-х этажного селекта его текст выводить тоже будем ?
Но сначала тут передерёмся, считая этажи...
4 окт 12, 23:01    [13270814]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
а давай после 3-х этажного селекта его текст выводить тоже будем ?
Но сначала тут передерёмся, считая этажи...
я попросил вывести всего лишь активные (незакомментаренные) параметры секции <database>.
Если даже это так сложно, то ладно, не надо. Буду надеяться, что Олег свой плагин допилит под *nix-64 и там сей функционал таки появится.
4 окт 12, 23:08    [13270834]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 57224

Таблоид> Если даже это так сложно

Неужели ты до сих пор не можешь понять разницу между "сложно" и "не нужно" ?

Posted via ActualForum NNTP Server 1.5

4 окт 12, 23:30    [13270886]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 31621
Разница "сейчас нужно" и "нафиг не упало в 99,999%".
5 окт 12, 01:40    [13271095]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
oleg_m
Member

Откуда:
Сообщений: 1101
Гаджимурадов Рустам
Таблоид> Если даже это так сложно
Неужели ты до сих пор не можешь понять разницу между "сложно" и "не нужно" ?


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

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

Аргументация в виде собственной забывчивости/невнимательности при составлении конфига - слабовато.
Ты же его только что написал, и указал при старте трассировки.


Таблоид
Буду надеяться, что Олег свой плагин допилит под *nix-64 и там сей функционал таки появится.

ага, твой список хотелок у меня лежит тут. Видимо все, что Влад забраковал
5 окт 12, 01:42    [13271096]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
oleg_m
Ты же его только что написал, и указал при старте трассировки.
Нет, конфиг меняется редко. Но если приходится отловить действия только одного коннекта, то я не могу добавить в командную строку кляузу типа -connection_id 123456, надо обязательно лезть в этот конфиг и прописывать его там. А затем, разумеется, не забыть убрать его оттуда.
oleg_m
ага, твой список хотелок у меня лежит тут. Видимо все, что Влад забраковал
Ты недалёк от истины. К сожалению.

ЗЫ. 2 ГР и Диля: я не комментирую реплики про устрицы и их (не-)нужность, если они выданы теми, кто не использует их в каждодневной еде. Вы сначала попробуйте в день по 5-7 раз поработать с трейсом на продакшене, в течение года-полутора, а потом обсудим, чего там нужно и не нужно.
5 окт 12, 12:58    [13273412]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 31621
//Типо пятницо жеж...
Таблоид
Вы сначала попробуйте в день по 5-7 раз поработать с трейсом на продакшене, в течение года-полутора, а потом обсудим, чего там нужно и не нужно.

За ковыряние в продакшене - айцы щемятся на месте преступления. (с чувством, толком, расстановкой)
Но с другой сторны: - не одна тестостенда не дает реальной картины.
Вот это дилема, а все остальное - производные от нее...
Вывод (и ввод): - Нужна "галка" определяющая "писать-нипИсать".
А где она быть должна - другой вопрос.
5 окт 12, 13:19    [13273621]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Di_LIne
За ковыряние в продакшене <...> (с чувством, толком, расстановкой)
Когда тебе начнут звонить хелпдесники и вопить, что там 150 мышинорыл сейчас всё разнесут - начнёшь ковыряться и позабудешь о своих причиндалах, будь спок.
5 окт 12, 13:54    [13273917]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 31621
Таблоид, мышиноморды - это следствие.
И ты сам не хужее меня знаешь, чем кончаются рукопашные схватки под лозунгом и перфоратором в руках "Ща я вам всем тут направлю!.."
5 окт 12, 14:52    [13274366]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Di_LIne
мышиноморды - это следствие.
Какое еще "следствие", я не понимаю тебя! Они зарабатывают для предприятия деньги и им надо, чтобы программа не зависала и показывала правильные данные. Второе требование невыполнимо без соблюдения первого.
А первое (чтобы прога не висла) можно обеспечить, если знаешь чем и куда смотреть.
Штатный инструмент в ФБ для "смотрения" есть, но его практическое использование показывает, что нужно допиливание.
Ты сам юзал трейс или аудит в своём продакшене ?
5 окт 12, 15:16    [13274539]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 31621
Вопли мышиномордов и хрюкдесков - это следствия.
А вот причина воплей - точно, не в FB зарыта. ;-)
Так понятнее?

Без имхи:
- Должны быть "кнопачки" включит-выключить.

Апача у мну логируется "от сих, до сих, и посисих".
Ессно, макисмально подробный лог - не в продакшен режиме.
Уровни подробности - переключаю по необходимости.
Продакшем режим - минимум лога.
5 окт 12, 16:11    [13275043]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Di_LIne
Вопли мышиномордов и хрюкдесков - это следствия.
А вот причина воплей - точно, не в FB зарыта. ;-)
Так понятнее?
Понятно. Не согласен. Откуда такая уверенность, что "точно не в FB" ?
Если бы дело было только в кривых запросах, то тормоза были бы постоянно, в "фоновом режиме". А они у нас с неких пор какие-то "очень быстрые" (по времени наступления и исчезновения), но очень уж дикие по своей степени.
5 окт 12, 16:17    [13275103]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 31621
Таблоид
но очень уж дикие по своей степени.

Мы не о том спорим...
Спору с моей стороны "нужно-ненужно" писать конфиг в лог - НЕТУ.
Нужно... Но с "переключателем", как и указал сразу, "писать-непИсать".
только и всего...
А сколько, когда, за чем и по чему эта джапмпачка в положении "пишем в лог" - каждый решает сам в своей, текущей ситуации.
5 окт 12, 16:26    [13275203]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Di_LIne
Апача у мну логируется "от сих, до сих, и посисих".
А причём тут твоя апача, кстат-те ?..
Мну интересует, чем ты ищешь причины затыков именно в своём ФБ.
Или у тебя по жизни там всё "летает в лёгкую" ?
5 окт 12, 16:53    [13275460]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 31621
Таблоид
А причём тут твоя апача, кстат-те ?..

Дрык при том, что в нем формат и детализацию логов определяешь сам.
А раз так, то нарисовано несколько строк с разным уровнем детализации в конфиге Апача.
И не нужные на текущий момент - заремлены...
И мое дело теперь - ток "джампачку" жмакать... :-)


Таблоид
Мну интересует, чем ты ищешь причины затыков именно в своём ФБ.

Ты не поверишь, но надобности в ентом - не возникало.
На этой неделе:
- FB вдрух начинал тормозить жутко, в произвольные моменты, в многопользовательском режиме короткими "провалами".
Чесание репы, тырканье запросов в Експерт, стучание (молотком) по РАИДу - не помогали.
Случайно отловили, что FB в определенной ситуации, нафигачивает темп больше 6 гигов.
А FB_TEMP на продакшине - на рамдиске в 2 гига.


Таблоид
Или у тебя по жизни там всё "летает в лёгкую" ?

Ну не все и не сразу, но пока не взлетит - в продакшен не попадает.

PS: грят в 2013 введут новую категорию в водительские права: - Управление FB экскаватором.
5 окт 12, 17:10    [13275588]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 57224
Таблоид
Нет, конфиг меняется редко. Но если приходится отловить действия только одного коннекта, то я не могу добавить в командную строку кляузу типа -connection_id 123456, надо обязательно лезть в этот конфиг и прописывать его там. А затем, разумеется, не забыть убрать его оттуда.
Так стало быть есть разница между всем конфигом и одной кляузой? Не говоря уже о собственной забывчивости.

Таблоид
я не комментирую реплики про устрицы и их (не-)нужность, если они выданы теми, кто не использует их в каждодневной еде. Вы сначала попробуйте в день по 5-7 раз поработать с трейсом на продакшене, в течение года-полутора, а потом обсудим, чего там нужно и не нужно.
Ну, поедая устрицы "в день по 5-7 раз в течение года-полутора" и не знать как и с чем их есть...
Что же тут обсуждать, проще обсудить их вкус с кем-нибудь, кто их не пробовал, чем с тобой... :)

Заметь, ты опять дуешь губки на пустом месте, не желая заметить, что
1. никто с тобой не спорил (хотя твоя реакция была ожидаема)
2. тебе просто объяснили, как это (накосячил, забыл, прибежал
с глупой хотелкой и вообще поведение в целом) выглядит со стороны

3. то же самое сказанное (при чём с конкретной аргументацией и
даже учётом твоего стиля работы) посторонним человеком (к тому же
производителем устриц местного разлива) ты тоже не воспринимаешь,
не соглашаешься и продолжаешь упорствовать.
5 окт 12, 18:37    [13276031]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 57224
Di_LIne
И мое дело теперь - ток "джампачку" жмакать... :-)
С FB так не прокатит. Аудит пишет с одним конфигом (не текущим, а прочитанным на момент старта), а трассировка - всегда с заданным, т.е. от жмакания джампачки ничего не зависит/изменится ни там, ни там. И вариант с джампачками не факт, что более правильный, ибо потом проблем и полтергейста не оберёшься.
5 окт 12, 18:40    [13276045]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Гаджимурадов Рустам
Таблоид
я не могу добавить в командную строку кляузу типа -connection_id 123456, надо обязательно лезть в этот конфиг и прописывать его там. А затем, разумеется, не забыть убрать его оттуда.
Так стало быть есть разница между всем конфигом и одной кляузой? Не говоря уже о собственной забывчивости.
Конечно есть! Если бы была возможность задавать кляузу, НЕ меняя конфиг, то настали бы совсем светлые времена. Но её нет, возможности этой!
А забывчивость - она у всех есть. Особенно когда все вокруг орут "ну когда там тормоза пройдут-таааа!..". Это не отменяемый чел. фактор.

Гаджимурадов Рустам
Заметь, ты опять дуешь губки на пустом месте, не желая заметить, что
1. никто с тобой не спорил (хотя твоя реакция была ожидаема)
2. тебе просто объяснили, как это (накосячил, забыл, прибежал
с глупой хотелкой и вообще поведение в целом) выглядит со стороны
"Простите, был взволнован!"
я вот этот твой "аргумент" воспринял именно как спор. И поскольку ты как-то недавно сказал, что запускал у себя только системный аудит и только один раз, то мну твоё возражение показалось совершенно неубедительным.

Гаджимурадов Рустам
3. то же самое сказанное (при чём с конкретной аргументацией и
даже учётом твоего стиля работы) посторонним человеком (к тому же
производителем устриц местного разлива) ты тоже не воспринимаешь,
не соглашаешься и продолжаешь упорствовать.
Олег совершенно верно сказал: вывод параметров пригодится для разбора полётов. Но он так думает только про системный аудит, который включить/выключить нельзя без отруба всех юзеров.
Я же утверждаю, что вывод параметров ВООБЩЕ всегда есть правильно, т.е. и при user-трейсе тоже.
Ибо позвонили мне в 12:10 с вопросом_1, запустил я юзер-трейс с некими параметрами, соответствующими этому вопросу_1, он отлогировался в файл_1. Начинаю разбираться в логе. Но в 12:40 позвонили со срочным вопросом_2, я подправил конфиг под этот вопрос_2, опять запустил трейс, он опять отлогировался в файл_2. А в 12:50 пришли из хелпдеска с вытаращенными глазами и вопросом_3 и я опять всё бросил и запустил юзер-трейс с конфигом, подправленным под вопрос_3 и он отлогировался в файл_3.
Дальше, вечером или ночером, начинаю смотреть в файл_1 и мучительно чешу репу: "а чё это арифметика по статистике (времени вып-я) какая-то странная ?... ах, да! я же там ставил time_threshold = 200". Смотрю затем в файл_2: "а чё это триггер на коммит нигде не видно ? а, тьфу! я же сам отменял логирование этого события... вроде бы..."
Теперь понятно, надеюсь, почему хотелка отросла про вывод параметров ?
Я не говорю, что такое творится каждый день. Но такое - бывает!

ЗЫ. На самом деле, всё ясно как пень: нужна возможность указания ключиков командной строки, перекрывающих своим действием значения параметров, указанных в конфиге трейса. Вот и всё.
5 окт 12, 19:03    [13276114]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 57224
Таблоид
Гаджимурадов Рустам
пропущено...
Так стало быть есть разница между всем конфигом и одной кляузой? Не говоря уже о собственной забывчивости.
Конечно есть! Если бы была возможность задавать кляузу, НЕ меняя конфиг, то настали бы совсем светлые времена. Но её нет, возможности этой!
...
ЗЫ. На самом деле, всё ясно как пень: нужна возможность указания ключиков командной строки, перекрывающих своим действием значения параметров, указанных в конфиге трейса. Вот и всё.
Стало быть именно это и нужно просить, а не простыню конфига в лог.
В огороде бузина, а в Днепропетровске дядька. Хотел одно, по ходу разговора
выяснилось другое, хоть и не шибко более адекватное. Но да, IP / ConnectionId
через командную строку принимать не мешало бы, наверное. Может и User/Role
туда же, буде им появиться в плагине из коробки.

Таблоид
я вот этот твой "аргумент" воспринял именно как спор. И поскольку ты как-то недавно сказал, что запускал у себя только системный аудит и только один раз, то мну твоё возражение показалось совершенно неубедительным.
Не, запускал я всё, когда оно ещё только-только появилось. Просто я, в отличие от тебя, экспериментов на реальных БД не ставлю, только на копиях. И да - идея с выводом конфига в лог неправильная. По многим причинам. В конце концов, ты и сам "это" можешь сделать, в своём скрипте.

Таблоид
Я не говорю, что такое творится каждый день. Но такое - бывает!
Дык бардак свой исправляй, а не сервер под него пытайся нагнуть.
Хотя понятно, что теперь под руки Олег попался - соблазн велик.
5 окт 12, 19:15    [13276149]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Гаджимурадов Рустам
Дык бардак свой исправляй, а не сервер под него пытайся нагнуть.
Бардак был заложен в это не мной. Приложение само по себе достаточно здоровое, одному не потянуть его переделку. Да и приоритеты тут у нас "сдвинулись" в другую сторону, как ты знаешь.
Гаджимурадов Рустам
Хотя понятно, что теперь под руки Олег попался - соблазн велик.
Дык!!
5 окт 12, 19:44    [13276234]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Гаджимурадов Рустам
В огороде бузина, а в Днепропетровске дядька
а почему ты выбрал именно этот город ?.. я бы в сторону Сыктывкара тоже посмотрел...
5 окт 12, 19:46    [13276242]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
Таблоид
На самом деле, всё ясно как пень
нужно научиться копировать файлы с конфигом трейса, а не подправлять один и тот же.
5 окт 12, 19:49    [13276254]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 57224
Таблоид
Гаджимурадов Рустам
В огороде бузина, а в Днепропетровске дядька
а почему ты выбрал именно этот город ?.. я бы в сторону Сыктывкара тоже посмотрел...
В данном случае первый меня интересует больше, чем второй. :)
5 окт 12, 19:53    [13276261]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 57224
hvlad
Таблоид
На самом деле, всё ясно как пень
нужно научиться копировать файлы с конфигом трейса, а не подправлять один и тот же.
При чём не вручную копировать, а засунуть сие в скрипт.
5 окт 12, 19:53    [13276262]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
нужно научиться копировать файлы с конфигом трейса, а не подправлять один и тот же.
Угу. И развести там файловую помойку на каждый чих. Ибо разбираться в каждом из них просто не будет времени - проще скопировать с эталона и заткнуть ненужные для данной ситуации параметры.
5 окт 12, 19:56    [13276273]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 57224
Зачем файловую помойку? Создаёшь папочку (по дате/времени, например), в нее копируешь конфиг и логи трейса.
5 окт 12, 20:05    [13276293]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: fbtracemgr: разные мелкие вопросы  [new]
DSKalugin
Member

Откуда: Мать городов русских
Сообщений: 285
Вопрос

Есть ли возможность в конфигурационном файле пользовательской трассировки для Firebird 3 задать фильтрацию запросов по имени пользователя (в идеале - регулярное выражение по юзерам). Интенсивность запросов довольно высокая, чтобы нагружать ими сервис логированием с последующим парсингом полезной информации.

Вижу только include_filter по тексту запросов и include_gds_codes по кодам ошибок

П.С. Хочу отследить все объекты БД, к которым обращается конкретный неолицетворенный юзер "Вася Продакшен", для ручной раздачи этим объектам прав доступа с последующим лишением "Васи Продакшен" роли RDB$ADMIN.
П.С. 2 Новые объекты создаются разработчиками с персонализированными учетками, которые забывают давать права на их использование неприкасаемому "Васе Продакшен" :-(
21 сен 17, 19:30    [20813526]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9233
DSKalugin,

фильтра по имени пользователя нет.

Можно найти в мониторинге его сессии и трассировать их по номеру коннекта.
21 сен 17, 19:43    [20813545]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4 5 6 7 8 9      [все]
Все форумы / Firebird, InterBase Ответить