RAT perfomance overhead

И White Papers, и наша wiki считают, что performance overhead при использовании RAT, цитата - "обычно менее 5%". Давайте посмотрим, что это за магическое число и что имеется в виду под perfomance overhead.

Для того, чтобы разобраться как работает захват (Capture) рекомендую прочитать патент на RAT DATABASE WORKLOAD CAPTURE AND REPLAY ARCHITECTURE. Оказалось, что его читать интереснее, чем документацию.

Несомненно, рекомендуют прочитать в оригинале, вот несколько цитат из него:

"
Capture processes <..> may be implemented as separate concurrently executing processes or as concurrently executing threads of the same process, for example. <..> Capture processes <..> capture all workload that production database server receives from external entities
"
"
Data stored in these in-memory buffers is compressed and written out in batches to persistent storage
"
"
When executed, SQL SELECT statements may cause production database server to return <..> values that satisfy the criteria specified in the statements. <..> the captured workload includes selected values that are returned as a result of the execution of SQL SELECT statements.
"

OS - Linux dbsrv 2.6.18-53.1.13.9.1.el5xen
Hardware - HP Compaq 8510w
Oracle 11g (11.1.0.7)


Для начала несколько тестов. чтобы набрать фактов для дальнейших размышлений.

drop table t1;
create table t1 (
id number(10),
small_vc varchar2(10),
padding varchar2(1000)
)
;

create unique index t1_pk on t1(id);


Тест N1
1 сессия, commit вне цикла, один курсор

set timi on set time on begin for i in 1..100000 loop insert into t1 values(i, lpad(i,10), rpad('x',1000)); end loop; commit; end; /

160K данных в директории Capture. Разницу в производительности с включенным capture & выключенным я измерить не смог. Таким образом этот случай укладывается в выше приведённые 5 %.


Тест N2
commit в цикле, sql выражения генерим случайным образом (execute immediate). Объем директории с данными Capture вырос до 6 Mb (для сравнения, объем файла trc после включения event 10046 составляет 90 Mb). Вы видете, что объем захваченной информации вырос в 30 раз. На одной сессии я опять таки не смог измерить разницу в производительности. конкретной сессии.

declare random_str varchar2(500); sql_stmt varchar(1000); begin for i in 1..200000 loop select dbms_random.string('U', 10) into random_str from dual; sql_stmt := 'insert into t1 (id, small_vc, padding) values(' || to_char (i)|| ', lpad(' || to_char(i)|| ',10),'|| chr(39)|| random_str ||chr(39) ||' )'; execute immediate sql_stmt; commit; end loop; end; /

OK, теперь самое время понять, как это работает. Для начала, как работает захват нагрузки. < href="http://download.oracle.com/docs/cd/B28359_01/server.111/e12253/toc.htm">Oracle® Database Real Application Testing User's Guide прочитан, но ничего про процесс(ы) захвата нет. В init.ora ничего подобного нет. А сколько их нужно, чтобы сохранить нагрузку от 100 сессий ? А от 1000 ?

Решение приходит внезапно просто:

Я запускаю нагрузку, в top нахожу процесс пользователя oracle который генерит у меня > 90% загрузки процессора, далее запускаю команду lsof (list of open files)

/usr/sbin/lsof -p 7814

oracle 7814 oracle 10u REG 253,0 3801088 2251233 /tmp/wc/inst1/aa/wcr_4k57tan0027n6.rec

Среди вывода я вижу явно файл с записанной нагрузкой ! Конечно же, самой сессии проще всего записать свою нагрузку ! Дополнительным фактом может быть сообщение "not all sessions could flush their capture buffers" в alert.log

Итак, каждая сессия сама накапливает данные в буфере и сбрасывает его на диск. Размер буфера в памяти - согласно источнику внизу - 64K, по моим тестам, это - 128K. Именно на столько больше требовалось сессиям с включенным режимом захвата нагрузки.

Хочу отметит, что Механиз Capture не мешает работать трассировке. Т.е. Вы легко можете одновременно влючить в сессии трассировку и производить захват. Трассировка также будет производиться. Конечно, в реальной жизни так делать не стоит.

Теперь выводы:

0. Объем захватываемой информации прямо пропорционален тому, насколько правильно написано приложение.

1. Если у Вас правильно написанная OLTP система (использует bind переменные), не делает commit слишком часто, нет проблем с вводом выводом, вы правильно расположите директорию для захваченных данных на отдельном диске, у вас достаточно свободного CPU, вы будете захватывать не все подряд, а тщательно настроите фильтры - вы вполне можете получить потери производительности для приложения < 5%.

2. Все изменения в БД должны будут попасть теперь кроме redo logs еще и в захваченную нагрузку. Например, я 1024 раза вставил в таблицу случайную строку длиной 1024 байта и получил в файлах захваченной нагрузки 1 Mb информации. Если у Вас система DW , загружающая информацию 10-ками гигабайт - вся эта информация будет еще раз записана на диск. Возможно, хорошая идея до захвата информации оценить ее объем, произведя mining redo, отобрав скажем нужные записи по пользователю. Ни о каких 5% тут конечно речь идти не будет. Удвоение ввода вывода окажется для вас гораздо дороже.

5. Несмотря на то, что в патенте прямо говориться об этом, мне не удалось увидеть, что capture собирает все полученные значения результата select'а. Скорее всего собирается лишь контрольная сумма, чтобы сказать совпадает результат запроса или нет. Т.е. для систем отчетности, которые делают большие сложные запросы и возможно возвращают на клиента большой result set Capture не будет представлять серьёзной опасности - объем собираемой информации относительно мал по сравнению с result set.

Как всегда, самая честная информация оказалась в самых первых материалах по данной теме.




PS Вся информация получена из открытых источников. Хочу поблагодарить Марка Ривкина, за то, что он обратил мое внимание на цифру 5%.