ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
25 сообщений из 161, страница 3 из 7
  3  все
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354221
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrДля свежесозданной базы без данных у тебя такое же безобразие выдается?Да, всё то же самое:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
C:\1Install\FIREBIRD_2_5>bin\isql
Use CONNECT or CREATE DATABASE to specify a database
SQL> create database 'empty.fdb' user 'sysdba' password 'masterke'; commit;
SQL> quit;

C:\1Install\FIREBIRD_2_5>bin\isql localhost/3252:C:\1Install\FIREBIRD_2_5\EMPTY.FDB -user sysdba -pas mas
Database:  localhost/3252:C:\1Install\FIREBIRD_2_5\EMPTY.FDB, User: sysdba
SQL> out mem25_empty.txt; select * from mon$memory_usage; out; quit;

C:\1Install\FIREBIRD_2_5>type mem25_empty.txt;

 MON$STAT_ID MON$STAT_GROUP       MON$MEMORY_USED  MON$MEMORY_ALLOCATED   MON$MAX_MEMORY_USED MON$MAX_MEMORY_ALLOCATED 
============ ============== ===================== ===================== ===================== ======================== 
           1              0             277733376             279064576             277736424                279064576 
           2              1                 16284                     0                 16356                        0 
           3              2                  5472                     0                  5536                        0 
           4              3                  4896                     0                  6472                        0
...
Рейтинг: 0 / 0
04.08.2013, 11:54:38
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354222
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
PS. Еще раз напомню, что вижу это на:
Код: plaintext
1.
2.
3.
4.
5.
6.
SQL> show version;
ISQL Version: WI-V2.5.3.26682 Firebird 2.5
Server version:
Firebird/x86/Windows NT (access method), version "WI-V2.5.3.26682 Firebird 2.5"
Firebird/x86/Windows NT (remote server), version "WI-V2.5.3.26682 Firebird 2.5/tcp (CSMIRROR)/P12"
Firebird/x86/Windows NT (remote interface), version "WI-V2.5.3.26682 Firebird 2.5/tcp (CSMIRROR)/P12"
on disk structure version 11.2
...
Рейтинг: 0 / 0
04.08.2013, 11:55:47
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354228
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидPS. Еще раз напомню, что вижу это на
иди спать лучше, а потом тестируй. У тебя 4 гига на 3.0 вылазило, а ты мне 2.5 пихаешь.
...
Рейтинг: 0 / 0
04.08.2013, 12:01:52
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354231
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Не, я уже проснулся, теперь "маховик не остановить" :-)
Вот для пустышки в WI-T3.0.0.30567:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
C:\1Install\fb30>isql
Use CONNECT or CREATE DATABASE to specify a database
SQL> create database 'empty.fdb' user 'sysdba' password 'masterke';
SQL> commit;
SQL> quit;

C:\1Install\fb30>isql localhost/3330:C:\1Install\fb30\EMPTY.FDB -user sysdba -pas masterke
Database:  localhost/3330:C:\1Install\fb30\EMPTY.FDB, User: sysdba
SQL> out mem30_empty.txt; select * from mon$memory_usage; out;
SQL> quit;
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
 MON$STAT_ID MON$STAT_GROUP       MON$MEMORY_USED  MON$MEMORY_ALLOCATED   MON$MAX_MEMORY_USED MON$MAX_MEMORY_ALLOCATED 
============ ============== ===================== ===================== ===================== ======================== 
           1              0                622736                589824                634856                   655360 
           2              1                387112                262144                399552               4294901760 
           3              2                   736                     0                   736                        0 
           4              2                  6688                     0                  6768                        0 
           5              3                 10304                 65536                 12160                    65536 
           6              1                124656                     0                124656                        0 
           7              1                  7344                     0                  7344                        0
...
Рейтинг: 0 / 0
04.08.2013, 12:08:12
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354236
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
У меня тоже для тройки в таблице mon$memory_usage

Код: plaintext
1.
2.
3.
4.
5.
MON$STAT_ID  MON$STAT_GROUP  MON$MEMORY_USED  MON$MEMORY_ALLOCATED  MON$MAX_MEMORY_USED  MON$MAX_MEMORY_ALLOCATED
          1               0                0                     0                    0                         0  
          2               1           625640                     0              1133200                    835184  
          3               2             6664                     0                 6744                         0  
          4               3             8272            4294901760                 9080                4294901760  
          5               3            10304            4294901760                12160                4294901760

Правда там база не пустая. Но кроме собственно запроса select * from mon$memory_usage я ничего не выполнял.
БД была наполнена так

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
create table t(id integer not null);

execute block
as
DECLARE VARIABLE i integer;
begin
  i = 0;
  while (i<10000000) do
  begin
    insert into t(id) values(:i);
    i = i+1;
  end
end

commit;

ALTER TABLE T ADD CONSTRAINT PK_T PRIMARY KEY (ID);
...
Рейтинг: 0 / 0
04.08.2013, 12:20:53
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354242
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
На самом деле я немного ошибся. Если только подключиться и сделать запрос к таблице мониторинга то всё норм. а вот если сделать второй коннект, то статистика омается.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
SQL> connect 'localhost/3051:horses' user 'sysdba' password 'masterkey';
Database:  'localhost/3051:horses', User: sysdba
SQL> select * from mon$memory_usage;

 MON$STAT_ID MON$STAT_GROUP       MON$MEMORY_USED  MON$MEMORY_ALLOCATED   MON$MAX_MEMORY_USED MON$MAX_MEMORY_ALLOCATED
============ ============== ===================== ===================== ===================== ========================
           1              0                     0                     0                     0                        0
           2              1                731440                327680                746576                   655360
           3              2                  1408                     0                  1408                        0
           4              2                  6688                     0                  6768                        0
           5              3                 10304                     0                 12160                        0

Теперь подключимся вторым isql

Код: plaintext
1.
2.
3.
Use CONNECT or CREATE DATABASE to specify a database
SQL> connect 'localhost/3051:horses' user 'sysdba' password 'masterkey';
Database:  'localhost/3051:horses', User: sysdba
SQL>

Снова переходим в первый и вот

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
SQL> commit;
SQL> select * from mon$memory_usage;

 MON$STAT_ID MON$STAT_GROUP       MON$MEMORY_USED  MON$MEMORY_ALLOCATED   MON$MAX_MEMORY_USED MON$MAX_MEMORY_ALLOCATED
============ ============== ===================== ===================== ===================== ========================
           1              0                     0                     0                     0                        0
           2              1                730672                262144                755168                   655360
           3              2                   736                     0                   736                        0
           4              2                  6688                     0                  6768                        0
           5              3                 10112            4294901760                 12160               4294901760
...
Рейтинг: 0 / 0
04.08.2013, 12:38:17
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354257
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
теперь вижу, спасибо
...
Рейтинг: 0 / 0
04.08.2013, 13:05:55
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354270
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
исправлено
...
Рейтинг: 0 / 0
04.08.2013, 13:40:55
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354366
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Таблоид Кажется , есть хорошая новость. А может, и нет её вовсе, если это снова апельсины vs огурцы :-)Нет, уже почти не кажется. Почти точно - она есть, эта хорошая новость :-)
Ибо сейчас два ФБ в одной арх-ре (SS), на одной windows-машине, с одинаковым кешем баз - и вижу, что ФБ-3 явно выигрывает у 2.5 в выборках из вот этого теста трёхлетней давности: " INDEX scan vs NATURAL в случае плохой селект-сти: INDEX всегда лучше ?! ".

DDL тот же, что в в первом посте этого теста.
Подключение делал по ТСР.

Запустил isql в 2.5, запустил трейс к нему. Выполнил 5 раз вот этот скрипт:
Код: sql
1.
2.
select count(*) from tmpmeasure where name||''='36681AD7-F44E-4E07-6AB1-96CF144A2082';
select count(*) from tmpmeasure where name='36681AD7-F44E-4E07-6AB1-96CF144A2082';

// 36681AD7-F44E-4E07-6AB1-96CF144A2082 = значение, записанное в 98% всех 10 млн записей таблицы
Повторил затем то же самое для 3.0.

Данные трейсов по 5 запускам в ФБ 2.5 vs 3.0:Firebird releaseQuery plan (NB: в таблице 98% строк - с одинаковым значением)timereadsfetches Firebird 2.5PLAN (TMPMEASURE NATURAL)486162129192042575548525212987479644823548376 Firebird 2.5PLAN (TMPMEASURE INDEX (IDX_TMPMSR_NAME))441532253851961239943870453284437143872timereadsfetches Firebird 3.0PLAN (TMPMEASURE NATURAL)197622129292027806218707182101840918248 Firebird 3.0PLAN (TMPMEASURE INDEX (IDX_TMPMSR_NAME))162192253411938705816193163791601116103
Повторил затем всё по-новой, опять делал по 5 запусков на двух ФБ - статистика подтвержилась.
18 сек против 45 - слишком серьёзное расхождение, чтобы его игнорировать.

Это что-то новое в алгоритмах доступа к данным "сработало" ?
...
Рейтинг: 0 / 0
04.08.2013, 17:01:41
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354390
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
навскидку, методы доступа тут не причем. Надо будет отпрофилировать на досуге :-)
...
Рейтинг: 0 / 0
04.08.2013, 17:22:01
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354428
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrнавскидку, методы доступа тут не причем. Надо будет отпрофилировать на досуге :-)есть ощущение, что часть данных застревала в файловом кеше, а вытеснялась оттудова в 2.5 быстрее, чем в 3.0.
Звучит маразматично, но вот что получилось в результате выполнения скрипта:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
set stat on;
set echo on;
set list on;
select count(*) from tmpmeasure where name||''='36681AD7-F44E-4E07-6AB1-96CF144A2082';
select count(*) from tmpmeasure where name||''='36681AD7-F44E-4E07-6AB1-96CF144A2082';
select count(*) from tmpmeasure where name||''='36681AD7-F44E-4E07-6AB1-96CF144A2082';
select count(*) from tmpmeasure where name||''='36681AD7-F44E-4E07-6AB1-96CF144A2082';
select count(*) from tmpmeasure where name||''='36681AD7-F44E-4E07-6AB1-96CF144A2082';
select count(*) from tmpmeasure where name||''='36681AD7-F44E-4E07-6AB1-96CF144A2082';
select count(*) from tmpmeasure where name||''='36681AD7-F44E-4E07-6AB1-96CF144A2082';
select count(*) from tmpmeasure where name||''='36681AD7-F44E-4E07-6AB1-96CF144A2082';
select count(*) from tmpmeasure where name||''='36681AD7-F44E-4E07-6AB1-96CF144A2082';
select count(*) from tmpmeasure where name||''='36681AD7-F44E-4E07-6AB1-96CF144A2082';

select count(*) from tmpmeasure where name='36681AD7-F44E-4E07-6AB1-96CF144A2082';
select count(*) from tmpmeasure where name='36681AD7-F44E-4E07-6AB1-96CF144A2082';
select count(*) from tmpmeasure where name='36681AD7-F44E-4E07-6AB1-96CF144A2082';
select count(*) from tmpmeasure where name='36681AD7-F44E-4E07-6AB1-96CF144A2082';
select count(*) from tmpmeasure where name='36681AD7-F44E-4E07-6AB1-96CF144A2082';
select count(*) from tmpmeasure where name='36681AD7-F44E-4E07-6AB1-96CF144A2082';
select count(*) from tmpmeasure where name='36681AD7-F44E-4E07-6AB1-96CF144A2082';
select count(*) from tmpmeasure where name='36681AD7-F44E-4E07-6AB1-96CF144A2082';
select count(*) from tmpmeasure where name='36681AD7-F44E-4E07-6AB1-96CF144A2082';
select count(*) from tmpmeasure where name='36681AD7-F44E-4E07-6AB1-96CF144A2082';
- в 2.5 и затем в 3.0:FB versionQuery plantimeWI-V2.5.3.26682PLAN (TMPMEASURE NATURAL)15561160113927548386484914853248519480994806348284WI-V2.5.3.26682PLAN (TMPMEASURE INDEX (IDX_TMPMSR_NAME))44029439674377943977440034370343986439544416943803timeWI-T3.0.0.30567PLAN (TMPMEASURE NATURAL)18698201021834018730184731879818370186891847218623WI-T3.0.0.30567PLAN (TMPMEASURE INDEX (IDX_TMPMSR_NAME))15730162021576116020198684947849730498544983049813
...
Рейтинг: 0 / 0
04.08.2013, 18:22:06
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354454
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоид,

статистику reads и fetches добавь, плс
...
Рейтинг: 0 / 0
04.08.2013, 19:05:07
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354493
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТаблоид,

статистику reads и fetches добавь, плсВот (пустые ячейки означают повтор последнего значения, расположенного в этом столбце выше данной строки):FB versionQuery plantimereadsfetchesWI-V2.5.3.26682PLAN (TMPMEASURE NATURAL)1556121291920425755160112129873927548386484914853248519480994806348284WI-V2.5.3.26682PLAN (TMPMEASURE INDEX (IDX_TMPMSR_NAME))4402922538519612399439674377943977440034370343986439544416943803timeWI-T3.0.0.30567PLAN (TMPMEASURE NATURAL)186982129292027806220102202128391834018730184731879818370186891847218623WI-T3.0.0.30567PLAN (TMPMEASURE INDEX (IDX_TMPMSR_NAME))1573022534119387058162021576116020198684947849730498544983049813
...
Рейтинг: 0 / 0
04.08.2013, 20:27:16
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354551
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Что-то странность вижу: хрестоматийный подсчет числа счастливых билетов (вариант с обращениями к rdb$database) на 2.5 идёт быстрее, чем на 3.0 :(
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
-- script: `lucky.sql`
set stat on;
set list on;
with c as(
  select 0 i from rdb$database union all
  select 1 from rdb$database union all
  select 2 from rdb$database union all
  select 3 from rdb$database union all
  select 4 from rdb$database union all
  select 5 from rdb$database union all
  select 6 from rdb$database union all
  select 7 from rdb$database union all
  select 8 from rdb$database union all
  select 9 from rdb$database 
)
select count(*) from c c1, c c2, c c3, c c4, c c5, c c6 -- c c1, c c1, c c1,
where c1.i+c2.i+c3.i = c4.i+c5.i+c6.i;
set list off;
set stat off;
 
FB 2.5: 3.8"
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
SQL> in c:\1install\fbtest\lucky.sql;

COUNT                           55252


Current memory = 277861940
Delta memory = 204100
Max memory = 277990428
Elapsed time= 3.81 sec
Buffers = 65535
Reads = 18
Writes 0
Fetches = 5555988
SQL> in c:\1install\fbtest\lucky.sql;

COUNT                           55252


Current memory = 277861948
Delta memory = 8
Max memory = 278125616
Elapsed time= 3.78 sec
Buffers = 65535
Reads = 0
Writes 0
Fetches = 5555730
SQL> in c:\1install\fbtest\lucky.sql;

COUNT                           55252


Current memory = 277861932
Delta memory = -16
Max memory = 278125616
Elapsed time= 3.72 sec
Buffers = 65535
Reads = 0
Writes 0
Fetches = 5555730
 
FB 3.0: ~4.4"
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
SQL> in c:\1install\fbtest\lucky.sql;

COUNT                           55252


Current memory = 1312528
Delta memory = 638560
Max memory = 1344368
Elapsed time= 4.43 sec
Buffers = 65535
Reads = 1
Writes 0
Fetches = 5555794
SQL> in c:\1install\fbtest\lucky.sql;

COUNT                           55252


Current memory = 1312528
Delta memory = 0
Max memory = 1344800
Elapsed time= 4.39 sec
Buffers = 65535
Reads = 0
Writes 0
Fetches = 5555790
SQL> in c:\1install\fbtest\lucky.sql;

COUNT                           55252


Current memory = 1312528
Delta memory = 0
Max memory = 1344800
Elapsed time= 4.41 sec
Buffers = 65535
Reads = 0
Writes 0
Fetches = 5555790
...
Рейтинг: 0 / 0
04.08.2013, 22:17:44
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354556
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоид,

я же говорил уже, что работа с кешем в 3-ке чуть медленнее
...
Рейтинг: 0 / 0
04.08.2013, 22:24:12
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354561
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladя же говорил уже, что работа с кешем в 3-ке чуть медленнееДа, я помню.
Повторил тест, но уже по условию равенства сумм четырех цифр, а не трёх (т.е. джойн 8 таблиц вместо 6). Отличие примерно 16% - многовато, КМК.

Вот результат для ФБ 3.0 :
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
SQL> in c:\1install\fbtest\lucky4.sql;

COUNT                           4816030


Current memory = 1460312
Delta memory = 147784
Max memory = 1484632
Elapsed time=  472.87 sec 
Buffers = 65535
Reads = 0
Writes 0
Fetches = 555555870

А вот для 2.5 :
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
SQL> in c:\1install\fbtest\lucky4.sql;

COUNT                           4816030


Current memory = 277904348
Delta memory = 246520
Max memory = 278031384
Elapsed time=  404.56 sec 
Buffers = 65535
Reads = 18
Writes 0
Fetches = 555556048
...
Рейтинг: 0 / 0
04.08.2013, 22:35:46
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354569
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladработа с кешем в 3-ке чуть медленнееВлад, а только ли с кешем ?
Вот, смотри: я намеренно добавил в запрос lucky.sql "ошибку чайника": заменил 'union all' на "просто union":
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
set stat on;
set list on;
with c as(
  select 0 i from rdb$database union -- да! намеренно убрано `all`, т.е. возникнет сортировка
  select 1 from rdb$database union
  select 2 from rdb$database union
  select 3 from rdb$database union
  select 4 from rdb$database union
  select 5 from rdb$database union
  select 6 from rdb$database union
  select 7 from rdb$database union
  select 8 from rdb$database union
  select 9 from rdb$database 
)
select count(*) from c c1, c c2, c c3, c c4, c c5, c c6 -- c c1, c c1, c c1,
where c1.i+c2.i+c3.i = c4.i+c5.i+c6.i;

set list off;
set stat off;

И теперь получаю разницу в 2 раза, и не пользу ФБ-3

FB 3.0:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
Current memory = 1374464
Delta memory = 15184
Max memory = 2294536
Elapsed time=  18.40 sec 
Buffers = 65535
Reads = 0
Writes 0
Fetches = 5555790

FB 2.5:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
Current memory = 278693520
Delta memory = 1035692
Max memory = 278695296
Elapsed time=  9.35 sec 
Buffers = 65535
Reads = 18
Writes 0
Fetches = 5555988
...
Рейтинг: 0 / 0
04.08.2013, 22:48:49
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354607
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
ТаблоидИ теперь получаю разницу в 2 разаЗависимость для этого варианта (с union distinct), похоже, константная: старый 2.5 в два раза быстрее, чем новый 3.0 :(
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
set stat on;
set list on;
with c as(
  select 0 i from rdb$database union
  select 1 from rdb$database union
  select 2 from rdb$database union
  select 3 from rdb$database union
  select 4 from rdb$database union
  select 5 from rdb$database union
  select 6 from rdb$database union
  select 7 from rdb$database union
  select 8 from rdb$database union
  select 9 from rdb$database 
)
select count(*) from c c1, c c2, c c3, c c4, c c5, c c6, c c7, c c8
where c1.i+c2.i+c3.i+c4.i = c5.i+c6.i+c7.i+c8.i;
 

set list off;
set stat off;

/*
 3.0: 
COUNT                           4816030


Current memory = 1296568
Delta memory = 868984
Max memory = 2479488
Elapsed time= 1859.62 sec
Buffers = 65535
Reads = 1
Writes 0
Fetches = 555555874
1 records fetched
 1859581  ms, 555555550 fetch(es)

Table                             Natural
******************************************
RDB$DATABASE                    111111110
*/

/*
 2.5: 
SQL> in c:\1install\fbtest\lucky4u.sql;

COUNT                           4816030


Current memory = 278881936
Delta memory = 1224108
Max memory = 279015488
Elapsed time= 962.25 sec
Buffers = 65535
Reads = 18
Writes 0
Fetches = 555556048

1 records fetched
  962247 ms , 555555550 fetch(es)

Table                             Natural
*********************************************
RDB$DATABASE                    111111110

*/
...
Рейтинг: 0 / 0
04.08.2013, 23:52:13
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355366
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Решил проверить для Oracle 11 XE вот это:ТаблоидПовторил тест, но уже по условию равенства сумм четырех цифр ... - но с отягощением:Таблоиднамеренно добавил в запрос lucky.sql "ошибку чайника": заменил 'union all' на "просто union"В общем, нам есть куда стремиться: этот гад всё утоптал за 2 минуты, выполнив 20 млн согласованных чтений (вместо 55 млн в ФБ, и то для случая union all ) и всего 2 (два) физических чтения :-)
 

Ora 11 xe, на той же машине, в конфигурации его ничего не менял:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
  COUNT(*)
----------
   4816030

Elapsed: 00:02:00.07

Execution Plan
----------------------------------------------------------
Plan hash value: 2643395602

---------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name                     | Rows  | Bytes | Cost (%CPU)| Time  |
---------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |                          |     1 |    24 |    22M  (1)| 74:05:20 |
|   1 |  TEMP TABLE TRANSFORMATION   |                          |       |       |            |       |
|   2 |   LOAD AS SELECT             | SYS_TEMP_0FD9D6605_572D2 |       |       |            |       |
|   3 |    SORT UNIQUE               |                          |    10 |       |    30  (94)| 00:00:01 |
|   4 |     UNION-ALL                |                          |       |       |            |       |
|   5 |      FAST DUAL               |                          |     1 |       |     2   (0)| 00:00:01 |
|   6 |      FAST DUAL               |                          |     1 |       |     2   (0)| 00:00:01 |
|   7 |      FAST DUAL               |                          |     1 |       |     2   (0)| 00:00:01 |
|   8 |      FAST DUAL               |                          |     1 |       |     2   (0)| 00:00:01 |
|   9 |      FAST DUAL               |                          |     1 |       |     2   (0)| 00:00:01 |
|  10 |      FAST DUAL               |                          |     1 |       |     2   (0)| 00:00:01 |
|  11 |      FAST DUAL               |                          |     1 |       |     2   (0)| 00:00:01 |
|  12 |      FAST DUAL               |                          |     1 |       |     2   (0)| 00:00:01 |
|  13 |      FAST DUAL               |                          |     1 |       |     2   (0)| 00:00:01 |
|  14 |      FAST DUAL               |                          |     1 |       |     2   (0)| 00:00:01 |
|  15 |   SORT AGGREGATE             |                          |     1 |    24 |            |       |
|  16 |    NESTED LOOPS              |                          |  1000K|    22M|    22M  (1)| 74:05:20 |
|  17 |     MERGE JOIN CARTESIAN     |                          |    10M|   200M|  2222K  (1)| 07:24:32 |
|  18 |      MERGE JOIN CARTESIAN    |                          |  1000K|    17M|   222K  (1)| 00:44:28 |
|  19 |       MERGE JOIN CARTESIAN   |                          |   100K|  1464K| 22226   (1)| 00:04:27 |
|  20 |        MERGE JOIN CARTESIAN  |                          | 10000 |   117K|  2222   (0)| 00:00:27 |
|  21 |         MERGE JOIN CARTESIAN |                          |  1000 |  9000 |   222   (0)| 00:00:03 |
|  22 |          MERGE JOIN CARTESIAN|                          |   100 |   600 |    22   (0)| 00:00:01 |
|  23 |           VIEW               |                          |    10 |    30 |     2   (0)| 00:00:01 |
|  24 |            TABLE ACCESS FULL | SYS_TEMP_0FD9D6605_572D2 |    10 |   130 |     2   (0)| 00:00:01 |
|  25 |           BUFFER SORT        |                          |    10 |    30 |    22   (0)| 00:00:01 |
|  26 |            VIEW              |                          |    10 |    30 |     2   (0)| 00:00:01 |
|  27 |             TABLE ACCESS FULL| SYS_TEMP_0FD9D6605_572D2 |    10 |   130 |     2   (0)| 00:00:01 |
|  28 |          BUFFER SORT         |                          |    10 |    30 |   220   (0)| 00:00:03 |
|  29 |           VIEW               |                          |    10 |    30 |     2   (0)| 00:00:01 |
|  30 |            TABLE ACCESS FULL | SYS_TEMP_0FD9D6605_572D2 |    10 |   130 |     2   (0)| 00:00:01 |
|  31 |         BUFFER SORT          |                          |    10 |    30 |  2220   (0)| 00:00:27 |
|  32 |          VIEW                |                          |    10 |    30 |     2   (0)| 00:00:01 |
|  33 |           TABLE ACCESS FULL  | SYS_TEMP_0FD9D6605_572D2 |    10 |   130 |     2   (0)| 00:00:01 |
|  34 |        BUFFER SORT           |                          |    10 |    30 | 22224   (1)| 00:04:27 |
|  35 |         VIEW                 |                          |    10 |    30 |     2   (0)| 00:00:01 |
|  36 |          TABLE ACCESS FULL   | SYS_TEMP_0FD9D6605_572D2 |    10 |   130 |     2   (0)| 00:00:01 |
|  37 |       BUFFER SORT            |                          |    10 |    30 |   222K  (1)| 00:44:28 |
|  38 |        VIEW                  |                          |    10 |    30 |     2   (0)| 00:00:01 |
|  39 |         TABLE ACCESS FULL    | SYS_TEMP_0FD9D6605_572D2 |    10 |   130 |     2   (0)| 00:00:01 |
|  40 |      BUFFER SORT             |                          |    10 |    30 |  2222K  (1)| 07:24:32 |
|  41 |       VIEW                   |                          |    10 |    30 |     2   (0)| 00:00:01 |
|  42 |        TABLE ACCESS FULL     | SYS_TEMP_0FD9D6605_572D2 |    10 |   130 |     2   (0)| 00:00:01 |
|* 43 |     VIEW                     |                          |     1 |     3 |     2   (0)| 00:00:01 |
|  44 |      TABLE ACCESS FULL       | SYS_TEMP_0FD9D6605_572D2 |    10 |   130 |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

  43 - filter("C1"."I"+"C2"."I"+"C3"."I"+"C4"."I"="C5"."I"+"C6"."I"+"C7"."I"+"C8"."I")


Statistics
----------------------------------------------------------
        100  recursive calls
         11  db block gets
   20000112  consistent gets
          2  physical reads
        576  redo size
        425  bytes sent via SQL*Net to client
        419  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
         15  sorts (memory)
          0  sorts (disk)
          1  rows processed
...
Рейтинг: 0 / 0
05.08.2013, 15:58:21
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355660
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Добрался до старого вопроса про кеш и вытеснение из него страниц: " Вытеснение страниц из кеша по принципу LRU"
Дано:

0) ФБ-3, SS, и база с кешем = 65535 (размер страницы = 4К);

1) таблица TBIG, 10 млн записей:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
SQL> show table tbig;
ID                              INTEGER Not Null
N01                             INTEGER Not Null
C01                             VARCHAR(20) Nullable
C02                             VARCHAR(20) Nullable
SQL> show index;
TBIG_C01 INDEX ON TBIG(C01)
TBIG_C02 INDEX ON TBIG(C02)
TBIG_N01 INDEX ON TBIG(N01)

2) Запрос, "ходящий" по двум индексам и выполняющий примерно 3-4 тыс фетчей.
Код: plaintext
1.
2.
3.
SQL> set stat on; set plan on; select count(*) from (select * from tbig where n01 =  :p01  rows 10) t1 join tb
ig t2 on t2.c02 starting with t1.c01; -- ":p01" = число от 0 до 999

PLAN JOIN (T1 TBIG INDEX (TBIG_N01), T2 INDEX (TBIG_C02))

Вот пример для трёх запусков запроса, когда соотв-щих записей *НЕТ* в кеше:
 
reads ~1500...1700
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
SQL> set stat on; set plan on; select count(*) from (select * from tbig where n01=511 rows 10) t1 join tb
ig t2 on t2.c02 starting with t1.c01;

PLAN JOIN (T1 TBIG INDEX (TBIG_N01), T2 INDEX (TBIG_C02))

                COUNT
=====================
                 1514

Current memory = 1315160
Delta memory = 430520
Max memory = 1333136
Elapsed time= 8.08 sec
Buffers = 65535
Reads = 1794
Writes 0
Fetches = 3770
SQL> set stat on; set plan on; select count(*) from (select * from tbig where n01=357 rows 10) t1 join tb
ig t2 on t2.c02 starting with t1.c01;

PLAN JOIN (T1 TBIG INDEX (TBIG_N01), T2 INDEX (TBIG_C02))

                COUNT
=====================
                 1589

Current memory = 1310360
Delta memory = -4800
Max memory = 1333136
Elapsed time= 7.82 sec
Buffers = 65535
Reads = 1622
Writes 0
Fetches = 3697


SQL> set stat on; set plan on; select count(*) from (select * from tbig where n01=789 rows 10) t1 join tb
ig t2 on t2.c02 starting with t1.c01;

PLAN JOIN (T1 TBIG INDEX (TBIG_N01), T2 INDEX (TBIG_C02))

                COUNT
=====================
                 1515

Current memory = 1312560
Delta memory = 2200
Max memory = 1333136
Elapsed time= 7.82 sec
Buffers = 65535
Reads = 1527
Writes 0
Fetches = 3550
Если повторить эти три варианта, то получим Reads=0 и нулевое время, т.е. он вытащит записи из кеша.

Идём дальше: открываем второе isql-окошко.
Запускаем в нём: SQL> select * from tbig where id>=10000000; -- или просто select count(*) from tbig;
Получаем план: PLAN (TBIG NATURAL)
И результат:
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
          ID          N01 C01                  C02
============ ============ ==================== ========
    10000000          254 6E59                 CE2F2ACF

Current memory = 1809656
Delta memory = 0
Max memory = 1889488
Elapsed time= 45.45 sec
Buffers = 65535
Reads = 181380
Writes 0
Fetches = 20182867
Возвращаемся в первое isql-окно.
Повторяем любой из вышеприведенных трех запросов и... получаем однозначное свидетельство, что огроменный NATURAL -скан второго окна вытолнул наши драгоценные записи из кеша. НЕ ВСЕ, но большую их часть: число reads равно 1000...1200 (в самом начале, до "закеширования", было 1500...1700)
 
reads ~1000...1200
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
SQL> set stat on; set plan on; select count(*) from (select * from tbig where n01=357 rows 10) t1 join tb
ig t2 on t2.c02 starting with t1.c01;

PLAN JOIN (T1 TBIG INDEX (TBIG_N01), T2 INDEX (TBIG_C02))

                COUNT
=====================
                 1589

Current memory = 1826120
Delta memory = -4400
Max memory = 1967336
Elapsed time= 5.92 sec
Buffers = 65535
Reads = 1214
Writes 0
Fetches = 2483

SQL> set stat on; set plan on; select count(*) from (select * from tbig where n01=789 rows 10) t1 join tb
ig t2 on t2.c02 starting with t1.c01;

PLAN JOIN (T1 TBIG INDEX (TBIG_N01), T2 INDEX (TBIG_C02))

                COUNT
=====================
                 1515

Current memory = 1828320
Delta memory = 2200
Max memory = 1967336
Elapsed time= 5.03 sec
Buffers = 65535
Reads = 1023
Writes 0
Fetches = 2527
SQL> set stat on; set plan on; select count(*) from (select * from tbig where n01=511 rows 10) t1 join tb
ig t2 on t2.c02 starting with t1.c01;

PLAN JOIN (T1 TBIG INDEX (TBIG_N01), T2 INDEX (TBIG_C02))

                COUNT
=====================
                 1514

Current memory = 1830520
Delta memory = 2200
Max memory = 1967336
Elapsed time= 5.19 sec
Buffers = 65535
Reads = 1007
Writes 0
Fetches = 2537
Это так и должно быть ?
...
Рейтинг: 0 / 0
05.08.2013, 18:41:04
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355702
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Таблоидогроменный NATURAL -скан второго окна вытолнул наши драгоценные записи из кешаBTW, на WI-V2.5.3.26682 этого нету! Записи остаются в кеше, время повторных выборок по индексам остается равным нулю. (База - аналогичная, арх-ра - такой же SS, кеш коннекта - такой же, 65535).
Any comments ?
...
Рейтинг: 0 / 0
05.08.2013, 18:58:23
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355721
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоид,

в 3-ке (пока ещё) сломана защита от большого натурального скана.
...
Рейтинг: 0 / 0
05.08.2013, 19:08:18
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355725
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladв 3-ке (пока ещё) сломана защита от большого натурального скана.в трекер заносить надо или это было сознательно сделано и не забудется ?
...
Рейтинг: 0 / 0
05.08.2013, 19:10:56
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355735
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоид,

пока не надо, я это помню
...
Рейтинг: 0 / 0
05.08.2013, 19:20:54
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355850
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Тут еще один вопрос полыхнул.
По мотивам пьесы почти годовалой давности: "Через сколько времени выполняемый DML должен среагировать на delete from mon$attachments ?", только теперь вместо mon$attachments'a в главной роли mon$statements.

Эмпирически выяснилось, что
ЕСЛИ:

1) запустить в сеансе_1 какой-то "жуткий bulk insert" типа такого:
Код: plaintext
1.
2.
3.
SQL> recreate table twid(s varchar(32765)); commit;
SQL> set stat on; 
SQL> insert into twid select rpad('',32765, 'qwertyuiopasdfghjklzxcvbnm0987654321') 
SQL> from rdb$types,rdb$types,rdb$types rows 1000000;
(подставить вместо 1000000 число побольше, чтобы гарантированно ушёл в себя минут на 20)

2) затем минут так через 10-15 в сеансе_2 ввести:
Код: plaintext
1.
2.
SQL> commit; delete from mon$statements; commit; -- (1)
SQL> set list on; select * from mon$statements; -- (2)

ТО:

1) сообщение вида:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
Statement failed, SQLSTATE = HY008
operation was cancelled
Current memory = 1535568
Delta memory = 738456
Max memory = 1941200
Elapsed time= 788.49 sec
Buffers = 65535
Reads = 881809
Writes 1704808
Fetches = 4440309
- появляется в сеансе_1 только после завершения отката инсертов.
Хотя в трейсе сообщение о завершении оператора delete from mon$statements появляется практически сразу же за его стартом:
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
2013-08-05T21:41:53.7960 (1476:00F04150) EXECUTE_STATEMENT_START
	perf30 (ATT_80, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
	C:\1Install\fb30\isql.exe:4044
		(TRA_226, CONCURRENCY | WAIT | READ_WRITE)

Statement 55:
-------------------------------------------------------------------------------
delete from mon$statements
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (MON$STATEMENTS NATURAL)

2013-08-05T21:41:54.9210 (1476:00F04150) EXECUTE_STATEMENT_FINISH
	perf30 (ATT_80, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
	C:\1Install\fb30\isql.exe:4044
		(TRA_226, CONCURRENCY | WAIT | READ_WRITE)

Statement 55:
-------------------------------------------------------------------------------
delete from mon$statements
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (MON$STATEMENTS NATURAL)
0 records fetched
   1130 ms, 33 fetch(es)

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

2013-08-05T21:41:54.9370 (1476:00F04150) FREE_STATEMENT
	perf30 (ATT_80, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
	C:\1Install\fb30\isql.exe:4044

Statement 55:
-------------------------------------------------------------------------------
delete from mon$statements
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (MON$STATEMENTS NATURAL)

2013-08-05T21:41:54.9370 (1476:00F04150) COMMIT_TRANSACTION
	perf30 (ATT_80, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
	C:\1Install\fb30\isql.exe:4044
		(TRA_226, CONCURRENCY | WAIT | READ_WRITE)
      0 ms, 1 write(s), 1 fetch(es), 1 mark(s)

2) ввод в сеансе_2 сразу после команды (1) команды (2) ни к чему не приводит - т.е. она просто висит без ответа. Опять таки до тех пор, пока ФБ не выполнит откат инсертов.
И вот этого я уже не понимаю: что ему (мониторингу) мешает сразу вернуть
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
MON$STATEMENT_ID                37
MON$ATTACHMENT_ID               78
MON$TRANSACTION_ID              <null>
MON$STATE                       0
MON$TIMESTAMP                   <null>
MON$SQL_TEXT                    0:2
insert into twid select rpad('',32765, 'qwertyuiopasdfghjklzxcvbnm0987654321') from rdb$types,rdb$types,r
db$types rows 1000000
MON$STAT_ID                     19
- ?

Вот фрагмент трейса по п. "2)":
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
-- тут я ввёл select * from mon$statements:
2013-08-05T 21:49 :16.5780 (1476:00F04150) EXECUTE_STATEMENT_START
	perf30 (ATT_80, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
	C:\1Install\fb30\isql.exe:4044
		(TRA_227, CONCURRENCY | WAIT | READ_WRITE)

Statement 56:
-------------------------------------------------------------------------------
select * from mon$statements
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (MON$STATEMENTS NATURAL)

-- это сообщение появилось только после завершения всех откатов.
-- И в это же время в сеансе_1 появились соотв-щие сообщения про 'operation was cancelled'
2013-08-05T21:51:31.7180 (1476:00F05CB0) FAILED EXECUTE_STATEMENT_FINISH
	perf30 (ATT_78, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
	C:\1Install\fb30\isql.exe:3696
		(TRA_223, CONCURRENCY | WAIT | READ_WRITE)

Statement 37:
-------------------------------------------------------------------------------
insert into twid select rpad('',32765, 'qwertyuiopasdfghjklzxcvbnm0987654321') from rdb$types,rdb$types,rdb$types rows 1000000
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN JOIN (RDB$TYPES NATURAL, RDB$TYPES NATURAL, RDB$TYPES NATURAL)
0 records fetched
 788435 ms, 881750 read(s), 272084 write(s), 4439400 fetch(es), 3979319 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$PAGES                                                            24                                        
RDB$TYPES                          107952                                                                      
TWID                                                             107520              107520                    

2013-08-05T21:51:31.7180 (1476:00F05CB0) ERROR AT JStatement::execute
	perf30 (ATT_78, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
	C:\1Install\fb30\isql.exe:3696
335544794 : operation was cancelled

-- и только после этого в сеансе_2 проснулся запрос к mon$statements:
2013-08-05T 21:51 :31.7180 (1476:00F04150) EXECUTE_STATEMENT_FINISH
	perf30 (ATT_80, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
	C:\1Install\fb30\isql.exe:4044
		(TRA_227, CONCURRENCY | WAIT | READ_WRITE)

Statement 56:
-------------------------------------------------------------------------------
select * from mon$statements
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (MON$STATEMENTS NATURAL)
14 records fetched
 135141 ms, 1 fetch(es)

ИТОГО получил: ожидание результата выборки из mon$statements, причина которого связана как-то с завершением откатов "сбитой" массовой вставки записей.
...
Рейтинг: 0 / 0
05.08.2013, 22:14:04
| Ответить | Цитировать | Написать  
25 сообщений из 161, страница 3 из 7
  3  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=38355660&tid=1564261]:
 0ms
get settings:
 8ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 209ms
get topic data:
 11ms
get forum data:
 2ms
get page messages:
 62ms
get tp. blocked users:
 1ms
others: 209ms
total:  523ms
созд. / загр.: 523ms
x
x
Закрыть


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