powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
161 сообщений из 161, показаны все 7 страниц
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352151
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hi all

В этом топеге буду складывать вопросы, появляющиеся по результатам сравнения - если увижу, что 3.0 в чем-то уступает 2.5.

Запускаю на одной и той же машине старые тесты, сначала на WI-V2.5.3.26682 (SuperClassic), а затем на WI-T3.0.0.30567 (SuperServer).

Данные по машине: Win-2003 Server SP2, CPU 2.4 GHz (2 core), RAM 1 Gb (увы, но только это).

Пока что нарыл некоторое ухудшение скорости вставок в GTT.
Исходный вопрос обсуждался тут: http://www.sql.ru/forum/860810-2/gtt-on-commit-delete-rows-nenulevye-writes-fetches-pri-commit-e-why

Дано:
1) две пустые базы, для 2.5 и 3.0, на обеих pagesize=4K, FW = OFF и кеш = 65535
2) DDL:
Код: sql
1.
2.
3.
recreate global temporary table gttdel(s varchar(36)) on commit DELETE ROWS; commit;
recreate global temporary table gttsav(s varchar(36)) on commit PRESERVE ROWS; commit;
recreate table fixtab(s varchar(36)); commit;

3) выполняю на каждой базе по очереди следующие три серии запросов:
Код: sql
1.
2.
3.
4.
5.
set stat on; insert into gttdel select 'abcdefghijklmnopqrstuvwxyz0123456789' from rdb$fields,rdb$fields,rdb$fields rows 1000000; commit;

set stat on; insert into gttsav select 'abcdefghijklmnopqrstuvwxyz0123456789' from rdb$fields,rdb$fields,rdb$fields rows 1000000; commit; quit;

insert into fixtab select 'abcdefghijklmnopqrstuvwxyz0123456789' from rdb$fields,rdb$fields,rdb$fields rows 1000000;

(NB: для GTT, которая on commit PRESERVE rows, сразу после её заполнения и коммита делаю quit, дабы 2-й и последующий замеры снова начинались с нулевого состояния этой таблицы).

Результаты:
1) время вставок в GTT'шки увеличилось в 3.0 по сравнению с 2.5, от 15% (для preserve rows) до 40% (для commit rows).
2) время вставок в fixed-таблицу увеличилось в 3.0 примерно на 10-15%

Вот статистика по reads/writes/fetches (БЕЗ времени выполнения):
Server versionВид таблицыСтатистикаЗатраты на insert 1'000'000 строкЗатраты на commit2.5.3.26682GTT on commit DELETE rowsReads11Writes2620445Fetches5237537204562.5.3.26682GTT on commit DELETE rowsReads381Writes2620444Fetches523783512.5.3.26682GTT on commit DELETE rowsReads11Writes4220446Fetches52375911xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx3.0.0.30567GTT on commit DELETE rowsReads420Writes2820435Fetches5242686204583.0.0.30567GTT on commit DELETE rowsReads10Writes2220435Fetches524252313.0.0.30567GTT on commit DELETE rowsReads1840Writes8820439Fetches52914041
- из которой видно, что эти параметры (reads/writes/fetches ) НЕ изменились.

А вот статистика по времени выполнения:
1. для GTT on commit DELETE rows: среднее увеличение времени вставок ~40%
Server versionОперацияизм_1изм_2изм_3изм_4изм_5изм_6изм_7изм_8изм_9изм_102.5.3.26682insert 1'000'000 rows3.193.193.183.193.213.193.213.193.193.213.0.0.30567""4.564.564.574.564.564.554.564.574.564.562.5.3.26682commit0.281.881.800.280.271.710.280.282.670.263.0.0.30567""1.750.290.300.300.320.301.860.310.300.29
2. для GTT on commit PRESERVE rows: среднее увеличение времени вставок ~15%
Server versionОперацияизм_1изм_2изм_3изм_4изм_5изм_6изм_7изм_8изм_9изм_102.5.3.26682insert 1'000'000 rows5.025.115.135.275.215.275.705.065.315.173.0.0.30567""6.306.426.376.176.326.426.286.236.366.432.5.3.26682commit0.250.270.270.270.250.270.250.260.250.173.0.0.30567""0.260.280.270.280.280.280.280.260.280.26
3. для FIXED-таблицы: среднее увеличение времени вставок ~10-12%
Server versionОперацияизм_1изм_2изм_3изм_4изм_5изм_6изм_7изм_8изм_9изм_102.5.3.26682insert 1'000'000 rows4.534.503.093.374.824.203.354.743.803.033.0.0.30567""5.474.494.434.474.414.414.394.544.414.412.5.3.26682commit2.231.971.661.771.751.981.832.011.762.033.0.0.30567""1.911.902.041.922.232.021.941.912.111.97
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352153
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А сравни-ка всё то же самое, но с pagesize=16K, FW = ON

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352157
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамА сравни-ка всё то же самое, но с pagesize=16K, FW = ONпоясни, плз, что это даст ?
FW = ON никак не должен повлиять на результаты GTT'шек. А увеличение pagesize должно обязательно привести к увеличению времени вставок/коммитов, но разве должны нарушиться их соотношения ?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352159
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,
Ты лучше свой тест с конкурентными вставками или апдейтами проверь.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352164
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидПока что нарыл некоторое ухудшение скорости вставок в GTTВот как в двух операциях (select + insert) ты однозначно увидел замедление именно вставок ?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352165
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидА увеличение pagesize должно обязательно привести к увеличению времени вставок/коммитовС чего бы это ?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352167
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЗапускаю на одной и той же машине старые тесты, сначала на WI-V2.5.3.26682 (SuperClassic), а затем на WI-T3.0.0.30567 (SuperServer).Ты сравниваешь апельсины с огурцами.
Сделай им хотя бы кеши одинаковые.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352168
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисТы лучше свой тест с конкурентными вставками или апдейтами проверь.Это тоже будет, попозжее только. Сейчас надо простые штуки сравнить.
Кстати: и в 2.5 и в 3.0 при commit'e в gtt on commit DELETE rows движок развивает бурную деятельность, смысл которой мне непонятен:
Код: plaintext
1.
2.
3.
4.
5.
6.
2013-08-01T20:58:46.7030 (3240:00F12A08) COMMIT_TRANSACTION
        perf30 (ATT_62, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1668
                (TRA_61, CONCURRENCY | WAIT | READ_WRITE)
    285 ms, 20435 write(s),   20458 fetch(es), 20434 mark(s)  
-- от чего тут так много фетчей и "марок" ? 
-- и зачем их делать вообще, когда таблица тут же "коцается" ?

Тогда как в остальных двух случаях (gtt on commit PRESERVE и fixed-table) всё вполне пристойно:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
2013-08-01T21:00:18.3120 (3240:00F12A08) COMMIT_TRANSACTION
        perf30 (ATT_62, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1668
                (TRA_62, CONCURRENCY | WAIT | READ_WRITE)
    291 ms, 20435 write(s),  1 fetch(es), 1 mark(s) 

2013-08-01T21:02:06.5780 (3240:00F12A08) COMMIT_TRANSACTION
        perf30 (ATT_62, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1668
                (TRA_63, CONCURRENCY | WAIT | READ_WRITE)
   2009 ms, 20438 write(s),  1 fetch(es), 1 mark(s) 

(вроде бы я спрашивал уже про это, но найти не могу в ворохе своих же изысков )
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352170
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТаблоидА увеличение pagesize должно обязательно привести к увеличению времени вставок/коммитовС чего бы это ?дык напарывался уже, в 2.1 еще...
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352171
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТаблоидЗапускаю на одной и той же машине старые тесты, сначала на WI-V2.5.3.26682 (SuperClassic), а затем на WI-T3.0.0.30567 (SuperServer).Ты сравниваешь апельсины с огурцами.
Сделай им хотя бы кеши одинаковые.Я с SS не работал, по 65000 выставил.
Какой поставить-то в 3.0 ?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352172
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид3) выполняю на каждой базе по очереди следующие три серии запросов:
Код: sql
1.
2.
3.
set stat on; insert into gttdel select 'abcdefghijklmnopqrstuvwxyz0123456789' from rdb$fields,rdb$fields,rdb$fields rows 1000000; commit;

set stat on; insert into gttsav select 'abcdefghijklmnopqrstuvwxyz0123456789' from rdb$fields,rdb$fields,rdb$fields rows 1000000; commit; quit;

Твои старые любимые грабли - первый запрос тратит время на расширение файла, второй запрос пользуется уже расширенным файлом.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352174
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТаблоидПока что нарыл некоторое ухудшение скорости вставок в GTTВот как в двух операциях (select + insert) ты однозначно увидел замедление именно вставок ?гм... но селект-то идёт из одной и той же "бочки"! а вставки - по разным "флаконам" :-)
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352176
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидКстати: и в 2.5 и в 3.0 при commit'e в gtt on commit DELETE rows движок развивает бурную деятельность, смысл которой мне непонятен:
Код: plaintext
1.
2.
3.
4.
5.
6.
2013-08-01T20:58:46.7030 (3240:00F12A08) COMMIT_TRANSACTION
        perf30 (ATT_62, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1668
                (TRA_61, CONCURRENCY | WAIT | READ_WRITE)
    285 ms, 20435 write(s),   20458 fetch(es), 20434 mark(s)  
-- от чего тут так много фетчей и "марок" ? 
-- и зачем их делать вообще, когда таблица тут же "коцается" ?
При освобождении страниц данных GTT помечает место в PIP, как свободное
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352178
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТвои старые любимые грабли - первый запрос тратит время на расширение файла, второй запрос пользуется уже расширенным файлом.йок. ибо:
Код: sql
1.
2.
3.
4.
set stat on; insert into gttdel select 'abcdefghijklmnopqrstuvwxyz0123456789' from rdb$fields,rdb$fields,rdb$fields rows 1000000; commit;

set stat on; insert into gttsav select 'abcdefghijklmnopqrstuvwxyz0123456789' from rdb$fields,rdb$fields,rdb$fields rows 1000000; commit; 
quit; -- ############### NB ######################

ну, и в первом посте:
автор(NB: для GTT, которая on commit PRESERVE rows, сразу после её заполнения и коммита делаю quit, дабы 2-й и последующий замеры снова начинались с нулевого состояния этой таб
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352179
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидйокТа ты шо :)
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352183
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladПри освобождении страниц данных GTT помечает место в PIP, как свободноеДля чего это делать ? всё равно страницы GTT'шки с on commit delete rows никогда не будут видны даже транзакции "А", стартовавшей в одном коннекте с транзакцией "Б". Как только коммит будет - "ку-ку", вся таблица снова нулевая.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352185
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТаблоидйокТа ты шо :)"Как же это так, кормилец ?!" (С)
Если я сделал quit из единственного коннекта, а после - очередной коннект, то что... fb_temp_xxx разве НОВЫЙ не создастся ?!
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352223
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидhvladПри освобождении страниц данных GTT помечает место в PIP, как свободноеДля чего это делать ?А что такое PIP ?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352224
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЕсли я сделал quit из единственного коннекта...Ты сегодня в ударе :)
Перечитай ещё раз:
hvladпервый запрос тратит время на расширение файла, второй запрос пользуется уже расширенным файломи ещё разhvlad первый запрос тратит время на расширение файла, второй запрос пользуется уже расширенным файломи потом - ещё раз, контрольный
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352253
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladПеречитай ещё раз <...> и потом - ещё раз, контрольныйПеречитал. Дошло, спасибо :-)
Сделал заново для GTT'шек (без fixed-таблиц), добавил QUIT после каждого insert + commit.

Ну, так вот: всё равно в ФБ-3 время больше.
Вот "сырой" отчет, но надеюсь, в нём всё понятно:

1. для 2.5:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
#################
2.5; buff = 65535
#################

#############  gtt on commit DELETE rows  ##################
SQL> set stat on; insert into gttdel select 'abcdefghijklmnopqrstuvwxyz0123456789' from rdb$fields,rdb$fields,rdb$fields rows 1000000; commit;  quit ;
Current memory = 283260972
Delta memory = 106148
Max memory = 283878040
Elapsed time= 5.17 sec   5.16   5.14   5.01   5.17
Buffers = 65535
Reads = 35
Writes 26
Fetches = 5237790
Current memory = 283253164
Delta memory = -7808
Max memory = 283878040
Elapsed time= 0.27 sec   0.27   0.27   0.26   0.26
Buffers = 65535
Reads = 1
Writes 20434
Fetches = 20456

trace:
------
insert into gttdel select 'abcdefghijklmnopqrstuvwxyz0123456789' from r
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN JOIN (RDB$FIELDS NATURAL, RDB$FIELDS NATURAL, RDB$FIELDS NATURAL)
0 records fetched
   5204 ms, 1 read(s), 26 write(s), 5237112 fetch(es), 1122525 mark(s)

Table                             Natural     Index    Update    Insert
***********************************************************************
RDB$FIELDS                        1008198
GTTDEL                                                          1000000
<...>
2013-08-01T23:30:14.5780 (1264:01F1BEB8) COMMIT_TRANSACTION
        perf25 (ATT_38, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:2084
                (TRA_82, CONCURRENCY | WAIT | READ_WRITE)
   2186 ms, 1 read(s), 20434 write(s), 20456 fetch(es), 20433 mark(s)


#############  gtt on commit PRESERVE rows  ##################
SQL> set stat on; insert into gttsav select 'abcdefghijklmnopqrstuvwxyz0123456789' from rdb$fields,rdb$fields,rdb$fields rows 1000000; commit;  quit; 
Database:  192.168.0.201/3252:perf25, User: sysdba
SQL> set stat on; insert into gttsav select 'abcdefghijklmnopqrstuvwxyz0123456789' from rdb$fields,rdb$fields,rdb$fields rows
 1000000; commit; quit;
Current memory = 283260980
Delta memory = 106156
Max memory = 283878048
Elapsed time= 5.27 sec   5.06   5.17   5.53   5.30
Buffers = 65535
Reads = 35
Writes 26
Fetches = 5237795
Current memory = 283253324
Delta memory = -7656
Max memory = 283878048
Elapsed time= 0.27 sec   0.27   0.27   0.25   0.26
Buffers = 65535
Reads = 1
Writes 20434
Fetches = 1

trace:
------
insert into gttsav select 'abcdefghijklmnopqrstuvwxyz0123456789' from r
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN JOIN (RDB$FIELDS NATURAL, RDB$FIELDS NATURAL, RDB$FIELDS NATURAL)
0 records fetched
   5346 ms, 1 read(s), 26 write(s), 5237112 fetch(es), 1122525 mark(s)

Table                             Natural     Index    Update    Insert
***********************************************************************
RDB$FIELDS                        1008198
GTTSAV                                                          1000000
<...>
2013-08-01T23:30:28.4060 (1264:01F1BEB8) COMMIT_TRANSACTION
        perf25 (ATT_39, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:2016
                (TRA_83, CONCURRENCY | WAIT | READ_WRITE)
    259 ms, 1 read(s), 20434 write(s), 1 fetch(es), 1 mark(s)

2. Для 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.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
#################
3.0; buff = 65535
#################

#############  gtt on commit DELETE rows  ##################
SQL> set stat on; insert into gttdel select 'abcdefghijklmnopqrstuvwxyz0123456789' from rdb$fields,rdb$fields,rdb$fields rows 1000000; commit;  quit; 
Current memory = 810656
Delta memory = 380696
Max memory = 1448536
Elapsed time= 6.41 sec   6.47   6.16   6.31   6.36
Buffers = 65535
Reads = 42
Writes 28
Fetches = 5242686
Current memory = 789408
Delta memory = -21248
Max memory = 1448536
Elapsed time= 0.29 sec   0.30   0.30   0.28   0.30
Buffers = 65535
Reads = 0
Writes 20435
Fetches = 20458

trace:
------
insert into gttdel select 'abcdefghijklmnopqrstuvwxyz0123456789' from rd
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN JOIN (RDB$FIELDS NATURAL, RDB$FIELDS NATURAL, RDB$FIELDS NATURAL)
0 records fetched
   6301 ms, 4 read(s), 28 write(s), 5242479 fetch(es), 1122529 mark(s)

Table                             Natural     Index    Update    Insert
************************************************************************
RDB$FIELDS                        1007195
GTTDEL                                                          1000000

2013-08-01T23:16:53.5620 (3240:00F12A08) COMMIT_TRANSACTION
        perf30 (ATT_101, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1604
                (TRA_80, CONCURRENCY | WAIT | READ_WRITE)
    288 ms, 20435 write(s), 20458 fetch(es), 20434 mark(s)



#############  gtt on commit PRESERVE rows  ##################
set stat on; insert into gttsav select 'abcdefghijklmnopqrstuvwxyz0123456789' from rdb$fields,rdb$fields,rdb$fields rows 1000000; commit;  quit; 
Database:  192.168.0.201/3330:perf30, User: sysdba
SQL> set stat on; insert into gttsav select 'abcdefghijklmnopqrstuvwxyz0123456789' from rdb$fields,rdb$fields,rdb$fields rows
 1000000; commit; quit;
Current memory = 810664
Delta memory = 380704
Max memory = 1448544
Elapsed time= 6.36 sec    6.26   6.26   6.22  6.41
Buffers = 65535
Reads = 42
Writes 28
Fetches = 5242686
Current memory = 789592
Delta memory = -21072
Max memory = 1448544
Elapsed time= 0.29 sec    0.28   0.26   0.28  0.26
Buffers = 65535
Reads = 0
Writes 20435
Fetches = 1


trace:
------
insert into gttsav select 'abcdefghijklmnopqrstuvwxyz0123456789' from r
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN JOIN (RDB$FIELDS NATURAL, RDB$FIELDS NATURAL, RDB$FIELDS NATURAL)
0 records fetched
   6207 ms, 4 read(s), 28 write(s), 5242479 fetch(es), 1122529 mark(s)

Table                             Natural     Index    Update    Insert
***********************************************************************
RDB$FIELDS                        1007195
GTTSAV                                                          1000000
<...>
2013-08-01T23:17:08.6090 (3240:00F11900) COMMIT_TRANSACTION
        perf30 (ATT_104, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:608
                (TRA_81, CONCURRENCY | WAIT | READ_WRITE)
    279 ms, 20435 write(s), 1 fetch(es), 1 mark(s)
Время на insert'ы и commit'ы для GTT действительно НЕ зависит от её вида.
Но в ФБ 2.5 времени на это уходило меньше, отношение ~5/6.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352261
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТаблоидпропущено...
Для чего это делать ?А что такое PIP ? http://www.ibphoenix.com/resources/documents/design/doc_19 Page Inventory Page

Page Type 2 is a page inventory page (PIP). PIPs map allocated and free pages. The header of a PIP includes the offset on this page of the bit that indicates the first available page on the PIP.

The body of a PIP contains an array of single bits that reflect the state of pages in the database. If the bit is one, then the corresponding page is not in use. If the bit is zero, then the page is in use.

PIPs occur at regular intervals through the database, starting at page 1. The last page allocated on each PIP is the next PIP.
А это... как его...
Что в эту самую PIP для GTT'шек пишется ?
Раз их содержимое вообще вне базы хранится, то что будет содержать этот самый "array of single bits that reflect the state of pages in the database " для GTT'шек ?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352477
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladкак в двух операциях (select + insert) ты однозначно увидел замедление именно вставок ?Проверил уже только вставки, никаких селектов - т.е. через execute block:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
set stat on;
set term ^;
execute block as
declare n int=1000000;
begin
  while(n>0) do insert into gttdel values('abcdefghijklmnopqrstuvwxyz0123456789') returning :n-1 into n;
end^
set term ;^
commit;
quit;

- и аналогичный скрипт для таблицы gttsav.

Результат: замедляются именно ВСТАВКИ. Затраты на выборку из rdb$fields были микронные.
Замеры делал по 10 раз для каждого скрипта на каждой версии ФБ.
Отчет:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
#################
 2.5 ; buff = 65535
#################

#############  gtt on commit DELETE rows  ##################
isql 192.168.0.201/3252:perf25 -n -user sysdba -pas masterke -i insgtt del .sql

Current memory = 283254328
Delta memory = 99492
Max memory = 283871644
Elapsed time=  5.11 sec    5.11    4.63   5.08   4.88   4.76   5.03   4.92   5.16   5.06 
Buffers = 65535
Reads = 34
Writes 26
Fetches = 3163667
Current memory = 283245252
Delta memory = -9076
Max memory = 283871644
Elapsed time= 0.26 sec  
Buffers = 65535
Reads = 1
Writes 20434
Fetches = 20456


trace:
------
execute block as
declare n int=1000000;
begin
  while(n>0) do insert into gttdel values('abcdefghijklmnopqrstuvwxyz012
end
0 records fetched
   5103 ms, 1 read(s), 26 write(s), 3163342 fetch(es), 1122525 mark(s)

Table                             Natural     Index    Update    Insert
xpunge
************************************************************************
******
GTTDEL                                                          1000000


#############  gtt on commit PRESERVE rows  ##################
isql 192.168.0.201/3252:perf25 -n -user sysdba -pas masterke -i insgtt sav .sql

Current memory = 283254340
Delta memory = 99500
Max memory = 283871656
Elapsed time=  4.78 sec    4.91   4.81   4.97   4.85   4.83   4.91   5.07   4.96   5.14 
Buffers = 65535
Reads = 34
Writes 26
Fetches = 3163672
Current memory = 283245404
Delta memory = -8936
Max memory = 283871656
Elapsed time= 0.26 sec
Buffers = 65535
Reads = 1
Writes 20434
Fetches = 1

trace:
------
execute block as
declare n int=1000000;
begin
  while(n>0) do insert into gttsav values('abcdefghijklmnopqrstuvwxyz01
end
0 records fetched
   5127 ms, 1 read(s), 26 write(s), 3163342 fetch(es), 1122525 mark(s)

Table                             Natural     Index    Update    Insert
xpunge
***********************************************************************
******
GTTSAV                                                          1000000

///////////////////////////////////////////////////////////////////////////////////////////////
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

#################
 3.0 ; buff = 65535
#################

#############  gtt on commit DELETE rows  ##################
C:\MIX\firebird\fb25>isql 192.168.0.201/3330:test30 -user sysdba -pas masterke -n -i insgtt del .sql
Current memory = 812232
Delta memory = 383224
Max memory = 1450312
Elapsed time=  5.75 sec   5.73   5.67   5.82   5.64   5.74   5.66   5.75   6.14   5.76 
Buffers = 65535
Reads = 39
Writes 28
Fetches = 3163552
Current memory = 788232
Delta memory = -24000
Max memory = 1450312
Elapsed time= 0.28 sec
Buffers = 65535
Reads = 0
Writes 20435
Fetches = 20458
trace:
   5759 ms, 1 read(s), 28 write(s), 3163346 fetch(es), 1122529 mark(s)

Table                             Natural     Index    Update    Insert
***********************************************************************
GTTDEL                                                          1000000

#############  gtt on commit PRESERVE rows  ##################
C:\MIX\firebird\fb25>isql 192.168.0.201/3330:test30 -user sysdba -pas masterke -n -i insgtt sav .sql
Current memory = 812232
Delta memory = 383224
Max memory = 1450312
Elapsed time=  6.22 sec   5.72   5.87   6.00   5.80   5.67   5.59   5.69   5.91   5.82 
Buffers = 65535
Reads = 39
Writes 28
Fetches = 3163552
Current memory = 788416
Delta memory = -23816
Max memory = 1450312
Elapsed time= 0.27 sec
Buffers = 65535
Reads = 0
Writes 20435
Fetches = 1

trace:
   5824 ms, 1 read(s), 28 write(s), 3163346 fetch(es), 1122529 mark(s)

Table                             Natural     Index    Update    Insert
xpunge
*************************************************************************
GTTSAV                                                          1000000


Соотношение между временем вставок, КМК, осталось таким же: 5/6 в пользу ФБ 2.5
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352495
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,
Стабильность курсора требует определённых затрат + nbackup (который теперь работает быстрее).
Может быть ещё найдут способ ускорить.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352520
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЧто в эту самую PIP для GTT'шек пишется ?
Раз их содержимое вообще вне базы хранится, то что будет содержать этот самый "array of single bits that reflect the state of pages in the database " для GTT'шек ?Ты не поверишь, но временный файл с данными GTT имеет такую же структуру, как и обычная БД.
И я писал об этом, насколько я помню.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352525
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисСтабильность курсора требует определённых затрат + nbackup (который теперь работает быстрее).Хорошая попытка, но мимо, по крайней мере в данном тесте :)

Новый общий кеш в однопоточных тестах работает несколько медленнее, чем раньше.
Ибо синхронизация, которой раньше не было, требует жертв.

Симонов ДенисМожет быть ещё найдут способ ускорить.Правильно, и этим тоже занимаемся.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352605
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
я бы сказал, что в этой теме не стоит (пока что) кричать караул и вопрошать "а почему?", надо просто выкладывать тесты и цифры результатов. А потом сравнить с бетой или RC.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352719
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Наконец-то официальная альфа тройки вышла. Теперь можно релиз-ноты почитать.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38353071
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrя бы сказал, что в этой теме не стоит (пока что) кричать караул и вопрошать "а почему?", надо просто выкладывать тесты и цифры результатов. А потом сравнить с бетой или RC."караул" про GTT'шки я кричал больше двух лет взад, вот тут:

1. Лишние(?) телодвижения при заполнении GTT on commit DELETE rows и последующем ROLLBACK`e (started 28-feb-11)

2. GTT on commit DELETE rows: ненулевые writes & fetches при COMMIT'e. Why ? (started 22-jun-2011)

Влад там сказал, что для GTT таки можно выполнить оптимизацию (см ниже под спойлером). Но в то время все силы отцов-основателей были брошены на ФБ-3 и лезть с этой хотелкой было бесполезно.
Сейчас ФБ-3 уже высунул нос для тестирования, и он еще не забетонирован, насколько я понимаю.
Можно ли сделать ту самую оптимизацию GTT, "о которой так долго говорили большевики" ?
http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=860810&msg=10871916
hvlad, 24 июн 11, 18:15ТаблоидВОПРОС-2. Зачем при коммите для GTT-таблицы, созданной как on commit delete rows, выполнять какую-то запись ?
Сброс кеша по коммиту никто не отменял.
В принципе, тут есть что оптимизировать для GTT с DELETE ROWS, согласен.

http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=860810&msg=10873177
hvlad, 24 июн 11, 22:44ТаблоидЗачем вообще нужен сброс кеша для времянки любого рода
а) Для DELETE освобождённые страницы можно вообще не писать на диск, сняв пометку о том, что они грязные
б) Для всех GTT - прям по коммиту можно и не сбрасывать (кстати flush для GTT не делается, т.е. операция не тяжёлая), но грязные страницы всё равно когда-нить пойдут на диск - хотя бы при вытеснении их из кеша.

http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=831889&msg=11592233 hvlad, 14 ноя 11, 12:41И - да - для GTT ON COMMIT DELETE ROWS можно не откатывать изменения по роллбеку.
И это тоже здесь уже упоминалось.
Там ещё кое-что можно не делать.
Дойдут руки - сделаем (сделаю).
Но что-то никто не жалуется (кроме тебя :)) на эти моменты - значит не так уж оно и критично :)

http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=831889&msg=11593934
hvlad, 14 ноя 11, 15:35ТаблоидЗа каким лешим ФБ откатывает изменения в GTT после окончания сеанса, когда и так ясно, что данных никаких не будет и файл грохнется операционкой ?
За таким, что всё делается одинаково и для GTT, и для обычных таблиц. Сколько раз я это должен повторять ?

Далее. Роллбеку пофигу откуда он вызван - из детача, или по просьбе юзера.

Далее. Сколько раз ещё я должен повторить, что роллбек для GTT\DELETE можно оптимизировать ?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38353169
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Причём тут GTT. Вставка, обновление и удаление на тройке медленнее чем на 2.5 и для обычных таблицы
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38353197
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисПричём тут GTT. Вставка, обновление и удаление на тройке медленнее чем на 2.5 и для обычных таблицы1) то, что работу с GTT оптимизировать можно и, наверное , это будет сделано - об этом говорил Влад (см предыдущий мой пост). Про ускорение dml c fixed-таблицами он не говорил - ни прямо, ни намёками. По кр. мере, за последние 3 года я не видел этого :-)
2) я вчера тестил только вставки в fixed-таблицу, в моноконнекте. Сильного проседания не заметил. Давай свой тест "на погляд", плз.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38353302
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
чуть позже обязательно предоставлю.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38353613
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кажется , есть хорошая новость. А может, и нет её вовсе, если это снова апельсины vs огурцы :-)
Создал в WI-V2.5.3.26682 и WI-T3.0.0.30567 таблицу с 10 млн строк и тремя индексами, каждый - по одному полю:
DDL
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
 -- create sequence g; commit;

alter sequence g restart with 0;
commit;
recreate table tbig (
    id  integer not null,
    n01 integer not null,
    c01 varchar(20),
    c02 varchar(20)
);
commit;

insert into tbig
select
    gen_id(g,1),
    rand()*1000,
    rpad('', 4, uuid_to_char( gen_uuid() ) ),
    rpad('', 8, uuid_to_char( gen_uuid() ) )
from  rdb$types,rdb$types,rdb$types
rows 10000000;
commit;
---------
create index tbig_n01 on tbig(n01);
create index tbig_c01 on tbig(c01);
create index tbig_c02 on tbig(c02);
commit;

Таблица, ввиду случайности генерируемых данных и их большого объема, содержит примерно одинаковое число записей для каждого значения поля n01 = 0...999
Селективность индексов:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
SQL> select cast(rdb$index_name as varchar(12)) idx, cast(rdb$field_name as varchar(12)) idx_key, rdb$statistics from rdb$ind
ex_segments where rdb$index_name like 'TBIG%';

IDX          IDX_KEY               RDB$STATISTICS
============ ============ =======================
TBIG_N01     N01            0.0009990009712055326
TBIG_C01     C01            1.525878906250000e-05
TBIG_C02     C02            1.001180223170195e-07

Коннект к обоим серверам делаю via ISQL Version: WI-V2.5.3.26661.

Вижу устойчивое преимущество ФБ-3 по времени выполнения вот такого вида запросов, примерно на 30-40%.
Например, ввожу:
Код: plaintext
1.
2.
3.
4.
5.
SQL> set stat on; set plan on; select count(*) from (select * from tbig where n01= :p1  rows 10) t1 join tbig t2 on t2.c02 starting with t1.c01; 
// вместо :p1 подставляю разные числа от 0 до 999.

PLAN JOIN (T1 TBIG INDEX (TBIG_N01), T2 INDEX (TBIG_C02))
// план одинаковый и на 2.5 и на 3.0

Вот типичный пример того, что получаю в 2.5:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
Current memory = 283445928
Delta memory = 179608
Max memory = 283455816
Elapsed time=  8.41 sec 
Buffers = 65535
Reads = 1445
Writes 0
Fetches = 3596

И вот что для такого же значения :p1 будет в 3.0:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
Current memory = 1020968
Delta memory = 1320
Max memory = 1985560
Elapsed time=  5.55 sec 
Buffers = 65535
Reads = 990
Writes 0
Fetches = 2540
Но терзают мну смутные сомнения. Читаю на ibase.ru объяснения смысла memory-статистики isql:kdv, http://www.ibase.ru/dpopov/plan-intro.html Current memory
Размер данных серверного процесса в байтах. На самом деле зависит от многих факторов, далеко не только от последнего запроса.
Delta memory
Насколько изменился предыдущий параметр между началом и концом обрабокти запроса. Не удивляйтесь, если увидите отрицательное число -- так тоже бывает. Просто сервер вдруг решил, что часть памяти ему сейчас не нужна и решил её освободить.
Max memory
Максимальный размер памяти, до которого доходило дело на каком-либо этапе обработки запроса.
И как такое может быть, что ФБ 2.5, затащив в память аж 270 Мб данных, лопатил в полтора раза дольше, чем ФБ 3.0, которому понадобилось всего лишь Max memory = 1985560 = 1.9 Мб ?!

Кажется, конфигурации 2.5 & 3.0 нуждаются в дальнейшем допиливании, дабы они действительно находились в равных условиях.
Но что именно менять, дабы привести их в "равенство" ?

Изменённые параметры firebird.conf в 3.0:
Код: plaintext
1.
2.
DefaultDbCachePages = 65535
FileSystemCacheThreshold = 512K
AuthServer = Srp, Win_Sspi, Legacy_Auth

Изменённые параметры firebird.conf в 2.5:
Код: plaintext
1.
DefaultDbCachePages = 65535
NB >>>  # FileSystemCacheThreshold = 65536 -- не менял в 2.5!!
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38353810
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Смотрю на старую тему : "Может ли FB не соединять при "очевидно ложном" условии соединения (on 1=0 etc)".
Есть там фраза:dimitr 3.0 будет сам такие вещи понимать. - вопиющая о необходимости своей проверки :-)
DDL:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
recreate sequence g; commit;
recreate sequence g2; commit;
recreate table thead(id int); commit;
recreate table tdata(id int, hid int); commit;
-----------
insert into thead select gen_id(g,1) from rdb$types rows 10; commit;
insert into tdata select gen_id(g,1), rand()*100 from rdb$types rows 30; commit;
-----------

Далее ввожу два варианта запроса, в котором источник, присоединяемый по left join, задушен константным условием "очевидная ложь":
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
SQL> show sequ g2;
Generator G2, current value is 0
SQL> select h.id, count(*) q, gen_id(g2,0) g2
CON> from thead h
CON> -- join rdb$database on 1=1 -- NB: пока что закомментировано
CON> left join (select d.hid dh, count(*) dc, min(gen_id(g2,1)) gx from tdata d group by hid) d on  1=0 
CON> group by h.id; 
output [code=plaintext] ID Q G2 ============ ===================== ===================== 1 1 0 2 1 0 3 1 0 4 1 0 5 1 0 6 1 0 7 1 0 8 1 0 9 1 0 10 1 0
Трейс для этого запроса выглядит благостно: ни одного обращения к таблице tdata (хотя в плане она присутствует):
Код: plaintext
1.
2.
3.
4.
5.
6.
PLAN SORT (JOIN (H NATURAL, SORT (D D NATURAL)))
10 records fetched
      0 ms, 34 fetch(es)

Table                             Natural     Index
*****************************************************
THEAD                                  10
(что подтверждается также выводом show sequ g2 - там будет по-прежнему 0).

А теперь убираем комментарий с inner join'a таблиц thead & rdb$database:
Код: plaintext
1.
2.
3.
4.
select h.id, count(*) q, gen_id(g2,0) g2 
from thead h 
 join rdb$database on 1=1 
left join (select d.hid dh, count(*) dc, min(gen_id(g2,1)) gx from tdata d group by hid) d on  1=0  
group by h.id;
И видим, ужасный кошмар: ФБ начинает обращаться к таблице tdata и, кроме того, в плане появляется еще один join :(

Trace:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
PLAN JOIN (SORT (JOIN (H NATURAL, RDB$DATABASE NATURAL)), SORT (D D NATURAL))
10 records fetched
      1 ms, 1034 fetch(es), 300 mark(s)

Table                             Natural     Index
*****************************************************

RDB$DATABASE                           10

THEAD                                  10

TDATA                                 300
output
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
          ID                     Q                    G2
============ ===================== =====================
           1                     1                    60
           2                     1                    90
           3                     1                   120
           4                     1                   150
           5                     1                   180
           6                     1                   210
           7                     1                   240
           8                     1                   270
           9                     1                   300
          10                     1                   300


Вопрос-1. dimitrТаблоидсможет действительно распознавать "100% невыполнимые" условия ПРЕЖДЕ, чем начать делать выборку ? да, если они константны для запроса Почему ФБ-3 включил в план TDATA, если в запросе явно присутствует константное условие "ложь" ?

Вопрос-2. Почему так повлияло inner-соединение thead с rdb$database ?

PS. Делал на WI-T 3.0.0.30567 . На WI-V2.5.3.26682 ситуация с обоими вариантами точно такая же.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38353823
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидвопиющая о необходимости своей проверки
оптимизатор проверять еще рано, он в альфе практически не менялся. Всему свое время.

ТаблоидНа WI-V2.5.3.26682 ситуация с обоими вариантами точно такая же
ну и что тогда этот тест делает в этой ветке?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38353830
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидвопиющая о необходимости своей проверкиоптимизатор проверять еще рано, он в альфе практически не менялся. Всему свое время.А когда примерно проверять можно будет ?

dimitrТаблоидНа WI-V2.5.3.26682 ситуация с обоими вариантами точно такая жену и что тогда этот тест делает в этой ветке?ну я же не знал, что оптимизатор проверять еще рано. Вот и сравнил с 2.5

Кста! Скажи мну, плз, вот по этому посту : я что-то неправильно назначил в конфиге ФБ-3, раз он так мало памяти жрёт по сравнению с 2.5 ? (и запросы быстрее на 30% фигачит) ? Как изменить конфиги, чтобы их (2.5 и 3.0, сидят на одной тачанке) поставить в равные условия ?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38353844
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидА когда примерно проверять можно будет ?
Beta 1

ТаблоидСкажи мну, плз, вот по этому посту : я что-то неправильно назначил в конфиге ФБ-3, раз он так мало памяти жрёт по сравнению с 2.5 ? (и запросы быстрее на 30% фигачит) ?
про память - мне отсюда не видно. Есть же MON$MEMORY_USAGE, посмотри в счетчики (а) базы, (б) твоего аттача, (в) твоей транзакции сразу после выполнения запроса. Может станет понятнее. Но вообще-то в 3.0 менялся менеджер памяти, так что сравнивать их напрямую бессмысленно.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354109
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

По поводу потребления памяти тройкой. Рано радуешься. Взгляни в диспетчер задач. Там он рисует значение в сотни раз больше чем показывает в статистике. Вероятно из этой статистики исключена память занятая кэшем.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354133
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrпро память - мне отсюда не видно. Есть же MON$MEMORY_USAGE, посмотри в счетчики (а) базы, (б) твоего аттача, (в) твоей транзакции сразу после выполнения запроса.Посмотрел, понятного мало :(
На обоих инстансах ФБ запустил "мониторные" isql, а с другой машины выполнял выполнял "основной запрос" вида:
Код: sql
1.
2.
3.
4.
5.
6.
set stat on; 
set plan on; 
select count(*) 
from (select * from tbig where n01=333 rows 10) t1 
      join tbig t2 
           on t2.c02 starting with t1.c01;


Перед и сразу после выполнения этого запроса в "мониторных" isql вводил:
Код: plaintext
1.
2.
3.
4.
out mon_memory_usage.txt; 
commit; select * from mon$memory_usage; -- это вводилось ПЕРЕД выполнением "основного запроса" (приведен выше)
commit; select * from mon$memory_usage; -- а это вводилось сразу же по окончании "основного запроса"
out;
quit;

1. Результат для 2.5:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
-- это результат снятия статистики непосредственно перед выполнением запроса  (первого и единственного):
 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             283236656             285421568             283239700                285421568 
           3              2                  5488                     0                  5552                        0 
           4              3                  4896                     0                  6472                        0 

-- это результат снятия статистики сразу по окончании запроса:
 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             283236652             285421568             283254492                285421568 
           3              2                  5116                     0                  5180                        0 
           4              3                  4752                     0                  6472                        0 
           5              1             283431216             285683712             283436888                285683712 
           6              2                  1660                     0                  1660                        0 
           7              3                184324                     0                185516                    69632 


2. Результат для 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.
-- это результат снятия статистики непосредственно перед выполнением запроса (первого и единственного):
MON$STAT_ID MON$STAT_GROUP       MON$MEMORY_USED  MON$MEMORY_ALLOCATED   MON$MAX_MEMORY_USED MON$MAX_MEMORY_ALLOCATED 
============ ============== ===================== ===================== ===================== ======================== 
           1              0                626432                393216                638552                   458752 
           2              1                389280                 65536                401720                4294901760 
            3              2                  6704                     0                  6784                        0 
           4              3                 10304                 65536                 12160                    65536 
           5              1                124656                     0                124656                        0 
           6              1                  7344                     0                  7344                        0 

-- это результат снятия статистики сразу по окончании запроса:
 MON$STAT_ID MON$STAT_GROUP       MON$MEMORY_USED  MON$MEMORY_ALLOCATED   MON$MAX_MEMORY_USED MON$MAX_MEMORY_ALLOCATED 
============ ============== ===================== ===================== ===================== ======================== 
           1              0               1517784                995208               1548440                  1126280 
           2              1                692256                401328                726168               4294901760 
           3              2                  2336                     0                  2336                        0 
           4              3                200008                 73648                200632               4294901760 
           5              1                389184            4294901760                407864               4294901760 
           6              2                  6704                     0                  6784                        0 
           7              3                 10112            4294901760                 12160               4294901760 
           8              1                135864                     0                155944                        0 
           9              2                   736                     0                   736                        0 
          10              1                  7344                     0                  7344                        0

Из чтения RN-2.5 делаю вывод, что ФБ-3 уже при первом коннекте и _до_ получения первого запроса от клиента пытается... цапнуть 99,9% всей физической и виртуальной память (1 Гб моего ОЗУ + 3 Гб файла подкачки = 1024*1024*1024 + 3072*1024*1024 = 4'294'967'296 байт) - см выделенное в результатах для ФБ-3 красным цветом значение. Потому что RN 2.5 MON$MEMORY_USAGE (current memory usage) http://www.firebirdsql.org/file/documentation/release_notes/html/rlsnotes251.html

MON$MAX_MEMORY_ALLOCATED (maximum number of bytes allocated from
the operating system by this object
)
Но лучше dimitr'a никто не объяснит, на что именно следует обратить внимание в этих двух фотоснимках mon$memory_usage.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354161
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
первое, что я вижу - что ты тестируешь 2.5 в архитектуре SC или CS. Вопрос - нафига, если тебе нужны равные условия? Во-вторых, статистика в 3.0 неисправна - в нее не попадает кеш и значения под 4GB явно левые, не соответствующие истине. Как поправим - отпишусь, надо будет повторить тест.

ЗЫ. твой второй "мониторный" коннект только мешает смотреть, делай селект из MON$ в том же коннекте что и тест.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354174
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrпервое, что я вижу - что ты тестируешь 2.5 в архитектуре SC или CS. Вопрос - нафига, если тебе нужны равные условия?Потому что привык на автопилоте тыркать в install_superclassic.bat :-[

Но! Размазывать задачи по нескольким ядрам SS научился только в 3.0
RN 3.0, page 9 True SMP support for SuperServer
In Superserver mode, the engine now makes use of multiple CPUs and cores when spawning connections.
Tracker: CORE-775
Implemented by V. KhorsunСоотв-но, как только будет сравнение работы нескольких коннектов, надо будет вернуть 2.5 в режим SuperClassic'a. Я прав ?

dimitrВо-вторых, статистика в 3.0 неисправна - в нее не попадает кеш и значения под 4GB явно левые, не соответствующие истине. Как поправим - отпишусь, надо будет повторить тест.OK, будем подождать.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354186
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидкак только будет сравнение работы нескольких коннектов, надо будет вернуть 2.5 в режим SuperClassic'a. Я прав ?
проверять надо будет на всех архитектурах, чтобы иметь отправную точку в виде "немасштабируемого" старого SS
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354188
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Переставил арх-ру в 2.5, кеш оставил прежним, 65535 страниц.
Повторил запрос, mon$-таблицу запрашивал из этого же isql-окна.
Результат для 2.5 SuperServer:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
 MON$STAT_ID MON$STAT_GROUP       MON$MEMORY_USED  MON$MEMORY_ALLOCATED   MON$MAX_MEMORY_USED MON$MAX_MEMORY_ALLOCATED 
============ ============== ===================== ===================== ===================== ======================== 
           1              0             277742208             279064576             277747780                279064576 
           2              1                 16248                     0                 16320                        0 
           3              2                  5488                     0                  5552                        0 
           4              3                  4896                     0                  6472                        0 

-----


 MON$STAT_ID MON$STAT_GROUP       MON$MEMORY_USED  MON$MEMORY_ALLOCATED   MON$MAX_MEMORY_USED MON$MAX_MEMORY_ALLOCATED 
============ ============== ===================== ===================== ===================== ======================== 
           1              0             277761268             279261184             277952620                279326720 
           2              1                 16776                     0                199160                    69632 
           3              2                  5100                     0                  5164                        0 
           4              3                  4744                     0                  6460                        0 

...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354197
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

пытаюсь воспроизвести большие числа в allocated-счетчиках и не могу, у меня там все нормально. Для свежесозданной базы без данных у тебя такое же безобразие выдается?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354200
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидПовторил запрос, mon$-таблицу запрашивал из этого же isql-окна
признавайся, коммитился перед вторым MON$-запросом? Надо так: mon$-commit-test-mon$.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354208
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидПовторил запрос, mon$-таблицу запрашивал из этого же isql-окна
признавайся, коммитился перед вторым MON$-запросом? Надо так: mon$-commit-test-mon$.я рестартовал ФБ_2.5 и выполнил вот это:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
C:\MIX\firebird\fb25>isql 192.168.0.201/3252:perf25 -n -user sysdba -pas masterke
Database:  192.168.0.201/3252:perf25, User: sysdba
SQL>  commit;  out mem25_before_test.txt; select * from mon$memory_usage; out;
SQL>  commit;  set stat on; set plan on; select count(*) from (select * from tbig where n01=874 rows 10) t1 join tbig t2 on t2.
c02 starting with t1.c01; set stat off; set plan off;

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

       COUNT
============
        1554

Current memory = 277936380
Delta memory = 205580
Max memory = 277938080
Elapsed time= 8.69 sec
Buffers = 65535
Reads = 1799
Writes 0
Fetches = 3501
SQL>  commit;  out mem25_after_test.txt; select * from mon$memory_usage; out;

В итоге:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
C:\MIX\firebird\fb25>type mem25_ before _test.txt

 MON$STAT_ID MON$STAT_GROUP       MON$MEMORY_USED  MON$MEMORY_ALLOCATED   MON$MAX_MEMORY_USED MON$MAX_MEMORY_ALLOCATED
============ ============== ===================== ===================== ===================== ========================
           1              0             277742020             279064576             277747592                279064576
           2              1                 16236                     0                 16308                        0
           3              2                  5488                     0                  5552                        0
           4              3                  4896                     0                  6472                        0


C:\MIX\firebird\fb25>type mem25_ after _test.txt

 MON$STAT_ID MON$STAT_GROUP       MON$MEMORY_USED  MON$MEMORY_ALLOCATED   MON$MAX_MEMORY_USED MON$MAX_MEMORY_ALLOCATED
============ ============== ===================== ===================== ===================== ========================
           1              0             277761084             279195648             277944572                279326720
           2              1                 16772                     0                190372                    69632
           3              2                  5100                     0                  5164                        0
           4              3                  4752                     0                  6472                        0
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354209
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrпытаюсь воспроизвести большие числа в allocated-счетчиках и не могу, у меня там все нормально. Для свежесозданной базы без данных у тебя такое же безобразие выдается?Сейчас попробую на отресторенной. Только не знаю, сколько этот b/r будет длиться, ибо .fdb весит под гиг.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354212
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидя рестартовал ФБ_2.5 и выполнил вот это
чем бы в тебя запустить отсюда? Я тебе говорю НЕ КОММИТИТЬ после выполнения тестового запроса, а ты опять за свое...
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354213
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид.fdb весит под гиг
какое слово во фразе "база БЕЗ ДАННЫХ " тебе непонятно? (с) DS
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354218
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидя рестартовал ФБ_2.5 и выполнил вот это
чем бы в тебя запустить отсюда? Я тебе говорю НЕ КОММИТИТЬ после выполнения тестового запроса, а ты опять за свое...ой... :-[ пардон муа...
dimitrНадо так: mon$-commit-test-mon$.
А впрочем, вот - ничего особо не поменялось (в 2.5):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
C:\MIX\firebird\fb25>isql 192.168.0.201/3252:perf25 -n -user sysdba -pas masterke
Database:  192.168.0.201/3252:perf25, User: sysdba
SQL> out mem25_before_test.txt; select * from mon$memory_usage; out;
SQL>  commit;  set stat on; set plan on; select count(*) from (select * from tbig where n01=521 rows 10) t1 join tbig t2 on t2.
c02 starting with t1.c01; set stat off; set plan off; 
outputPLAN JOIN (T1 TBIG INDEX (TBIG_N01), T2 INDEX (TBIG_C02)) COUNT ============ 1499 Current memory = 277938924 Delta memory = 208124 Max memory = 277939268 Elapsed time= 8.16 sec Buffers = 65535 Reads = 1739 Writes 0 Fetches = 3391
SQL> out mem25_after_test.txt; select * from mon$memory_usage; out;

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
C:\MIX\firebird\fb25>type mem25_before_test.txt

 MON$STAT_ID MON$STAT_GROUP       MON$MEMORY_USED  MON$MEMORY_ALLOCATED   MON$MAX_MEMORY_USED MON$MAX_MEMORY_ALLOCATED
============ ============== ===================== ===================== ===================== ========================
           1              0             277742020             279064576             277747592                279064576
           2              1                 16236                     0                 16308                        0
           3              2                  5488                     0                  5552                        0
           4              3                  4896                     0                  6472                        0


C:\MIX\firebird\fb25>type mem25_after_test.txt

 MON$STAT_ID MON$STAT_GROUP       MON$MEMORY_USED  MON$MEMORY_ALLOCATED   MON$MAX_MEMORY_USED MON$MAX_MEMORY_ALLOCATED
============ ============== ===================== ===================== ===================== ========================
           1              0             277762140             279261184             277950752                279392256
           2              1                 17832                     0                199392                    69632
           3              2                  6160                     0                  6224                        0
           4              3                  4752                     0                  6476                        0
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354219
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоид.fdb весит под гигкакое слово во фразе "база БЕЗ ДАННЫХ " тебе непонятно? (с) DSпфф... не проснулся я еще: вчерась почти 600 км отмотал по дорогам "нечерноземья" :-/
сейчас проверю.
...
Рейтинг: 0 / 0
Сравнение производительности 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
Сравнение производительности 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
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354228
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидPS. Еще раз напомню, что вижу это на
иди спать лучше, а потом тестируй. У тебя 4 гига на 3.0 вылазило, а ты мне 2.5 пихаешь.
...
Рейтинг: 0 / 0
Сравнение производительности 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
Сравнение производительности 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
Сравнение производительности 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
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354257
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
теперь вижу, спасибо
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354270
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
исправлено
...
Рейтинг: 0 / 0
Сравнение производительности 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
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354390
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
навскидку, методы доступа тут не причем. Надо будет отпрофилировать на досуге :-)
...
Рейтинг: 0 / 0
Сравнение производительности 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
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354454
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

статистику reads и fetches добавь, плс
...
Рейтинг: 0 / 0
Сравнение производительности 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
Сравнение производительности 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
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354556
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

я же говорил уже, что работа с кешем в 3-ке чуть медленнее
...
Рейтинг: 0 / 0
Сравнение производительности 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
Сравнение производительности 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
Сравнение производительности 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
Сравнение производительности 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
Сравнение производительности 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
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355702
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидогроменный NATURAL -скан второго окна вытолнул наши драгоценные записи из кешаBTW, на WI-V2.5.3.26682 этого нету! Записи остаются в кеше, время повторных выборок по индексам остается равным нулю. (База - аналогичная, арх-ра - такой же SS, кеш коннекта - такой же, 65535).
Any comments ?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355721
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

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

пока не надо, я это помню
...
Рейтинг: 0 / 0
Сравнение производительности 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
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355863
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид1) сообщение вида:
Код: plaintext
1.
2.
3.
Statement failed, SQLSTATE = HY008
operation was cancelled
...
- появляется в сеансе_1 только после завершения отката инсертов.
Хотя в трейсе сообщение о завершении оператора delete from mon$statements появляется практически сразу же за его стартом:И это совершенно правильно

Таблоид2) ввод в сеансе_2 сразу после команды (1) команды (2) ни к чему не приводит - т.е. она просто висит без ответа. Опять таки до тех пор, пока ФБ не выполнит откат инсертов.Откат - операция тонкая, она не отвлекается на мониторинг и прочий решедулинг.
Насколько создание снапшота мониторинга во время отката действительно критично, нужно крепко подумать...
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355869
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladОткат - операция тонкая, она не отвлекается на мониторинг и прочий решедулинг.
Насколько создание снапшота мониторинга во время отката действительно критично, нужно крепко подумать...Хм...
Снапшот мониторинга делает ДБА, и в основном - не ради любопытства, а когда видит, что база тупит.
Снапшот также может делать планировщик, если ДБА захочет понаблюдать за базой в течение NN дней.

А откат массового DML может произойти ввиду срубания приложения на любой усеровской тачке. В любой момент.
И что получается, ДБА (или задание крона :)) должен будет ждать 2-3-5-... минут результатов мониторинга, пока ФБ не выполнит откаты обрубленного bulk DML ?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355871
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидВ общем, нам есть куда стремиться: этот гад всё утоптал за 2 минуты, выполнив 20 млн согласованных чтений (вместо 55 млн в ФБ, и то для случая union all ) и всего 2 (два) физических чтения :-)
текущая версия из SVN "топчет" твой тест за 4 минуты с хвостиком против 17 минут на альфе 1 (при том же числе фетчей и чтений). А на своей сборке я сейчас вижу:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
                COUNT 
===================== 
              4816030 

Current memory = 10906744
Delta memory = 775280
Max memory = 11966576
Elapsed time= 47.61 sec
Cpu = 0.00 sec
Buffers = 2048
Reads = 1
Writes = 0
Fetches = 724

но оно еще требует тестирования :-)
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355872
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидпока ФБ не выполнит откаты обрубленного bulk DML ?
откаты обрубленного будут ускорены, ты же сам об этом просил в трекере
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355873
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидИ что получается, ДБА (или задание крона :)) должен будет ждать 2-3-5-... минутнет, пусть лучше БД развалится на части - но зато мгновенно
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355875
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидВ общем, нам есть куда стремиться: этот гад всё утоптал за 2 минуты, выполнив 20 млн согласованных чтений (вместо 55 млн в ФБ, и то для случая union all ) и всего 2 (два) физических чтения :-)
текущая версия из SVN "топчет" твой тест за 4 минуты с хвостиком против 17 минут на альфе 1 (при том же числе фетчей и чтений).Вах!.. а в чём там дело было ? Такое ускорение выглядит как-то... подозрительно

dimitrА на своей сборке я сейчас вижу:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
                COUNT 
===================== 
              4816030 

Current memory = 10906744
Delta memory = 775280
Max memory = 11966576
 Elapsed time= 47.61 sec 
Cpu = 0.00 sec
 Buffers = 2048  -- ?! 
Reads = 1
Writes = 0
 Fetches = 724  -- ?!?! это после 55 млн ???   

dimitrно оно еще требует тестирования :-)Наверное, ты прав... :-)
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355880
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrоткаты обрубленного будут ускорены, ты же сам об этом просил в трекереДа, я помню этот 3809
Но после слов Алекса:
Alexander PeshkovAlexander Peshkov added a comment - 09/Apr/12 05:24 AM
It's very interesting point. Probably be we should change rollback method when shutdown is active .
- и отсутствия на него твоей реакции почему-то подумалось, что "утопнет оно" :-)
BTW, а когда это ускорение откатов случится, наверное, в Beta только ?

hvladнет, пусть лучше БД развалится на части - но зато мгновенноА с какого это перепугу она "развалится мгновенно на части" ? Если bulk_DML-откат будет прерван шатдауном с -force 0 (что я делал не один десяток раз, да еще и на FW = OFF) - что, тоже развалится ?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355881
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидВах!.. а в чём там дело было ? Такое ускорение выглядит как-то... подозрительно
ничего сверхестественного, глянь в трекере . Оно давно напрашивалось, но руки дошли только сейчас. Правда, эффект несколько больше ожидаемого :-) но твои тесты вечно не от мира сего...

Вот только былое отставание от 2.5 надо будет отдельно разбирать, это что-то другое.

Таблоид
Код: plaintext
1.
 Buffers = 2048  -- ?! 

а нафига больше для чтения таблицы с одной записью? Это свежесозданная БД, настройки "из коробки".

Таблоид
Код: plaintext
1.
 Fetches = 724  -- ?!?! это после 55 млн ???   

это нормально. Оракл тоже усердно все закешировал, но он в consistent gets считает и чтения из временной таблицы тоже.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355884
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидА с какого это перепугу она "развалится мгновенно на части" ?Вот этот вопрос и надо изучить.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355890
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидВах!.. а в чём там дело было ? Такое ускорение выглядит как-то... подозрительноничего сверхестественного, глянь в трекере . Оно давно напрашивалось, но руки дошли только сейчас.Круто, что тут говорить.
Но! фраза: "However, even the former case could benefit from the "plain" execution, as it saves one union context thus avoiding redundant record copying" - не объясняет, почему не только юнион 8 строк, но и соединение 8 таблиц теперь будет выполняться быстрее прежнего на несколько порядков.

dimitrПравда, эффект несколько больше ожидаемого :-) но твои тесты вечно не от мира сего...Дык у нас всё приложение тут такое (пока его 1с'ом не убили - есть неисчерпаемый источник для маразма вдохновения и соотв-щих тестов :))

dimitrТаблоид
Код: plaintext
 Buffers = 2048  -- ?! 

а нафига больше для чтения таблицы с одной записью? Это свежесозданная БД, настройки "из коробки".Как это "с одной записью" ?? Там таблица в 10 строк создается и дальше идет self join 8 раз!

dimitrТаблоид
Код: plaintext
1.
 Fetches = 724  -- ?!?! это после 55 млн ???   
это нормально. Оракл тоже усердно все закешировал, но он в consistent gets считает и чтения из временной таблицы тоже.Это на сборке, где ты уже подправил статистику ? (я про недавние траблы с ней)
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355896
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидничего сверхестественного, глянь в трекере .Там написано, что Fix Version/s: 3.0 Alpha 2
Если скачивать снапшот с обычного адреса - эта фича уже будет в нём, или на сайте только Alpha- 1 ?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355973
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидне объясняет, почему не только юнион 8 строк, но и соединение 8 таблиц теперь будет выполняться быстрее прежнего на несколько порядков
потому что это соединение юнионов методом nested loop, т.е. юнионы перевыполняются туеву хучу раз

ТаблоидКак это "с одной записью" ?? Там таблица в 10 строк создается и дальше идет self join 8 раз!
все твои выкрутасы с WITH и self join это лишь повторные фетчи из одной таблицы размером в одну страницу. Включи мозг.

ТаблоидЭто на сборке, где ты уже подправил статистику ? (я про недавние траблы с ней)
статистика с памятью уже давно в SVN исправлена, прочая статистка работает правильно

ТаблоидЕсли скачивать снапшот с обычного адреса - эта фича уже будет в нём, или на сайте только Alpha-1 ?
в снапшоте будет
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355989
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Посмотрел исправленную статистику. Очень интересно.

Это на БД 716 Мб
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
SQL> set stat on;
SQL> select 1 as n from rdb$database;

           N
============
           1

Current memory = 137638544
Delta memory = 177616
Max memory = 137656112
Elapsed time= 0.01 sec
Buffers = 8192
Reads = 0
Writes 0
Fetches = 12
SQL>


Это на БД 1 Мб
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
SQL> set stat on;
SQL> select 1 as n from rdb$database;

           N
============
           1

Current memory = 36859128
Delta memory = 177616
Max memory = 36876696
Elapsed time= 0.00 sec
Buffers = 8192
Reads = 0
Writes 0
Fetches = 12
SQL>

Других запросов не выполнялось. Правильно ли я понимаю, что при подключении к БД Firebird пытается как можно больше засосать в кэш?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38356542
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидстарый 2.5 в два раза быстрее, чем новый 3.0
правильнее будет - новый 2.5 (то бишь 2.5.3) был быстрее как нового 3.0, так и старого 2.5.2. Причина найдена, справедливость восстановлена.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38356557
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисПосмотрел исправленную статистику. Очень интересно
небось размер страницы 16К в большой и 4К в маленькой? Я никаких странностей у себя не наблюдаю.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38356596
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitr,
Может быть. Посмотрю. Я просто думал, что пока кэш не заполнен и статистика должна быть небольшой. Выходит, что память сразу резервируется и независимо заполнен кэш или нет отображается таковой.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38356598
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисВыходит, что память сразу резервируется и независимо заполнен кэш или нет отображается таковой.
конечно
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38356649
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисПравильно ли я понимаю, что при подключении к БД Firebird пытается как можно больше засосать в кэш?а вот у мну на сегодняшнем снапшоте нет такой разницы. Проверяю на 1) пустой базе и затем на 2) базе 5 Гб.
Размер страниц в обеих базах одинаковый, 4К.
Параметры firebird.conf оставил дефолтными.
Код: 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.
C:\1Install\FBTEST>C:\1Install\fb30\isql
Use CONNECT or CREATE DATABASE to specify a database
SQL> shell dir /-c /o:s *.fdb | findstr /c:fdb;
05.08.2013  17:15          1064960 empty30.fdb 
04.08.2013  21:47        37076992 t0.fdb
05.08.2013  20:15       942977024 perf25.fdb
06.08.2013  14:23      5021986816 PERF30.fdb 

SQL> connect empty30.fdb;
Database:  empty30.fdb
SQL> show database;
Database: empty30.fdb
<...>
PAGE_SIZE 4096
Number of DB pages allocated = 260
<...>
ODS = 12.0

SQL> set stat on; select 1 n from rdb$database;

           N
============
           1

Current memory =  9747992 
Delta memory = 177640
Max memory = 9765584
Elapsed time= 0.00 sec
Buffers = 2048
Reads = 0
Writes 0
Fetches = 8
SQL> set stat off;
SQL> commit;
SQL> ----------------------------------
SQL> connect  perf30.fdb; 
Database:  perf30.fdb
SQL> show database;
Database: perf30.fdb
<...>
PAGE_SIZE 4096
Number of DB pages allocated = 1226071
Sweep interval = 20000
Forced Writes are ON
<...>
ODS = 12.0

SQL> set stat on; select 1 from rdb$database;

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

Current memory =  9753968 
Delta memory = 177200
Max memory = 9771560
Elapsed time= 0.00 sec
Buffers = 2048
Reads = 0
Writes 0
Fetches = 8
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38356658
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,
dimitr уже ответил. Скорее всего так и есть. Размер страниц разный. После работы перепроверю.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38356739
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидВ общем, нам есть куда стремиться: этот гад всё утоптал за 2 минуты, выполнив 20 млн согласованных чтений (вместо 55 млн в ФБ, и то для случая union all ) и всего 2 (два) физических чтения :-)текущая версия из SVN "топчет" твой тест за 4 минуты с хвостиком против 17 минут на альфе 1 (при том же числе фетчей и чтений). Проверил на WI-T3.0.0. 30578 Firebird 3.0 Alpha 1/tcp, вариант подсчета числа счастливых билетов в 8-значных номерах, с union DISTINCT (вместо "обычного" union ALL).
Улучшение по времени вып-я, конечно же, вижу:

БЫЛО (см. тут , под спойлером):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
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

СТАЛО:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
COUNT                           4816030

Current memory = 292217200
Delta memory = 88128
Max memory = 293268496
 Elapsed time= 579.80 sec 


Buffers = 65535
Reads = 0
Writes 0
Fetches = 555555870

Но фетчей то осталось столько же, 55 лямов!

Вот это волшебство:dimitrА на своей сборке я сейчас вижу:
Код: plaintext
1.
2.
3.
<...>
Reads = 1
Writes = 0
 Fetches = 724 
но оно еще требует тестирования :-)- оно уже включено в снапшот или еще нет ?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38356866
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидоно уже включено в снапшот или еще нет ?
если внимательно читать мои посты, то очевидно что нет
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38357181
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В двух базах, одна из которых была создана под 2.5.3, а вторая под 3.0.0, присутствует таблица TBIG(id int, ... другие_поля ...), 10 млн строк.
На таблицу был навешен ПК, а затем он был удален - таким обр., повторное его пересоздание по этой же таблице не вызовет увеличение диска.

Соединяюсь по ТСР с каждой базой по очереди и повторно ввожу команду создание индекса ПК с отображением статистики.
И вот что вижу.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
 Для 3.0.0.30578 :
C:\1Install\fb30>isql 192.168.0.201/3330:perf30 -user sysdba -pas masterke -n
Database:  192.168.0.201/3330:perf30, User: sysdba
SQL> alter table tbig add constraint tbig_pk primary key(id) using index tbig_pk;
SQL> set stat on; commit; set stat off;
Current memory = 293001208
Delta memory = 853040
Max memory = 348517376
 Elapsed time= 215.72 sec 
Buffers = 65535
Reads = 182058
Writes 15013
Fetches = 20262541

Trace:
2013-08-06T17:11:50.0930 (2320:009F1900) COMMIT_TRANSACTION
        perf30 (ATT_86, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
        C:\1Install\fb30\isql.exe:868
                (TRA_227, CONCURRENCY | WAIT | READ_WRITE)
 214822 ms, 182050 read(s), 15002 write(s), 20262364 fetch(es), 29999 mark(s)

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
 Для 2.5.3: 
C:\1Install\FIREBIRD_2_5> 192.168.0.201/3252:perf25 -user sysdba -pas masterke -n
Database:  192.168.0.201/3252:perf25, User: sysdba
SQL> alter table tbig add constraint tbig_pk primary key(id) using index tbig_pk;
SQL> set stat on; commit; set stat off;
Current memory = 278393736
Delta memory = 569576
Max memory = 333958924
 Elapsed time= 53.00 sec 
Buffers = 65535
Reads = 182047
Writes 15019
Fetches = 20394173

Trace:

2013-08-06T17:23:19.6250 (3752:0221DEB0) COMMIT_TRANSACTION
        perf25 (ATT_68, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
        C:\1Install\FIREBIRD_2_5\bin\isql.exe:1760
                (TRA_250, CONCURRENCY | WAIT | READ_WRITE)
  52996 ms, 182043 read(s), 15003 write(s), 20394055 fetch(es), 30012 mark(s)
show version + database, 3.0.0
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
SQL> show version; show database;
ISQL Version: WI-T3.0.0.30578 Firebird 3.0 Alpha 1
Server version:
Firebird/Windows/Intel/i386 (access method), version "WI-T3.0.0.30578 Firebird 3.0 Alpha 1"
Firebird/Windows/Intel/i386 (remote server), version "WI-T3.0.0.30578 Firebird 3.0 Alpha 1/tcp (CSMIRROR)
/P13:C"
Firebird/Windows/Intel/i386 (remote interface), version "WI-T3.0.0.30578 Firebird 3.0 Alpha 1/tcp (CSMIRR
OR)/P13:C"
on disk structure version 12.0
Database: 192.168.0.201/3330:perf30
        Owner: ZOTOV
PAGE_SIZE 4096
Number of DB pages allocated = 259894
Sweep interval = 20000
 Forced Writes are ON 
Transaction - oldest = 119
Transaction - oldest active = 229
Transaction - oldest snapshot = 229
Transaction - Next = 232
ODS = 12.0
Default Character set: NONE
show version + database, 2.5.3
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
SQL> show version; show database;
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
Database: 192.168.0.201/3252:perf25
        Owner: SYSDBA
PAGE_SIZE 4096
Number of DB pages allocated = 244607
Sweep interval = 20000
 Forced Writes are ON 
Transaction - oldest = 233
Transaction - oldest active = 253
Transaction - oldest snapshot = 253
Transaction - Next = 254
ODS = 11.2
Default Character set: NONE
Что-то "затупилось" в создании индексов, КМК...
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38357196
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

а файл сортировки в одном и том же месте создается?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38357209
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvфайл сортировки в одном и том же месте создается?я не менял в .conf'e значение для TempDirs.
Да и диск на этой машине всего один.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38357430
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrСимонов ДенисПосмотрел исправленную статистику. Очень интересно
небось размер страницы 16К в большой и 4К в маленькой? Я никаких странностей у себя не наблюдаю.

Так и было. Извиняюсь.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38357440
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И еще тут вопросик. На тему: что быстрее выполнится, новый hash join в Firebird 3.x или старина-merge в 2.5.

Вот есть таблица в 3 млн строк, два int-поля, одно из них проиндексировано.
DDL:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
recreate table tmp(f1 int, f2 int); commit;
set stat on;
set term ^;
execute block as
declare variable n int = 3000000;
begin
while (n>=0) do 
  insert into tmp values(rand()*1000,rand()*1000)
  returning :n-1 into :n;
end^
set term ;^
commit;
set stat off;
create index tmp_f1 on tmp(f1);
set stat on;
commit;
set stat off;

Задача:
1) сгруппировать по f1 записи и вычислить по каждому f1 агрегат count(*)'
2) вытащить далее только такие f1, по которым count(*) будет либо наибольшим из всех остальных (т.е. "золотой призёр" по частоте встречаемости), либо следующим за наибольшим ("серебрянный призёр").

Например, вот для такого варианта:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
SQL> recreate table tmp(f1 int, f2 int); commit;
SQL> insert into tmp values(765, 120);
SQL> insert into tmp values(122, 342);
 SQL> insert into tmp values(100, 123);
SQL> insert into tmp values(100, 122);
SQL> insert into tmp values(100, 141);
SQL> insert into tmp values(111, 222);
SQL> insert into tmp values(111, 232);
SQL> insert into tmp values(200, 333);
SQL> insert into tmp values(200, 444);
SQL> insert into tmp values(200, 555); 
SQL> insert into tmp values(333, 134);
SQL> insert into tmp values(444, 789);
SQL> insert into tmp values(543, 167);
SQL> commit;
- запрос должен вытряхнуть:
Код: plaintext
1.
2.
3.
4.
          F1               CNT_MAX
============ =====================
          100                     3
         200                     3
         111                     2 
(т.е. "золотое место" по числу встречаемости делят два значения `f1` - 100 и 200; а "серебряное место" - значение 111)

Установил на обоих ФБ (2.5.3 и 3.0.0) максимально возможный в 32-битном варианте кеш страниц - 128К.
Вводил по 5 раз запрос:
Код: plaintext
1.
2.
3.
4.
5.
6.
set plan on; set stat on;
select a.f1, a.cnt_max from (select a.f1, count(*) cnt_max from tmp a group by a.f1) a 
join (select distinct cnt 
        from (select count(*) cnt from tmp x group by x.f1) 
       order by cnt desc rows 2) x
on a.cnt_max = x.cnt;

Планы выполнения и статистика оказались следующими.

1. ФБ 3.0.0
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
PLAN HASH (SORT (X X ORDER TMP_F1), A A ORDER TMP_F1)

Current memory = 590120360
Delta memory = 4042040
Max memory = 641591496
Elapsed time= 17.49 sec   17.12   17.14   17.13   17.14
Buffers = 131072
Reads = 0
Writes 0
Fetches = 18007506

2. ФБ 2.5.3
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
PLAN MERGE (SORT (SORT (X X ORDER TMP_F1)), SORT (A A ORDER TMP_F1))

Current memory = 560854636
Delta memory = 4
Max memory = 612267964
Elapsed time= 14.45 sec   14.45   14.45   14.45   14.45 // да-да! пять раз получалось одинаковое время!
Buffers = 131072
Reads = 0
Writes 0
Fetches = 18007418

Затем повторил на кеше = 65535 - результаты практически не поменялись:
Код: plaintext
1.
2.
для 3.0.0:   17.27   17.25   17.21   17.24   17.24
для 2.5.3:   14.52   14.53   14.52   14.53   14.52

Итого: hash join проигрывает 20% (если в нём, конечно, дело).
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38357446
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PS. Да, и еще. Когда ФБ выполняет сортировки, то в task manager'e чётко виден рост потребляемой памяти. По окончании сортировки ФБ *не* отдает эту память системе уже до переконнекта (возможно, это только в SS так).
Например, вот такой запрос (таблицу см в DDL предыдущего поста):
Код: sql
1.
2.
3.
4.
select cnt 
from (select count(*) cnt from tmp x group by x.f1) 
order by cnt
rows 2;

- приводит к изъятию сразу ~150 мегов памяти, хотя сортировать ему тут надо всего 1 тыс строк int-значений. И после выдачи результата + коммита память эта так и остается "зарезервированной".
Системе она вернется только после переконнекта.
Заметив это, я делал замеры с непременным дисконнектом isql после окончания последнего запуска.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38357466
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Самое интересное, что заставить объединять два потока методом MERGE невозможно, даже если это явно указать в плане. То ли это временно сделано для отладки HASH JOIN, то ли его полностью решили заменить. Вроде бы с статье по методам доступа было сказано, что HASH JOIN не всегда быстрее MERGE
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38357472
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть и еще одна печалька: если заменить 3 ляма на 10:
DDL
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
recreate table tmp(f1 int, f2 int); commit;
set stat on;
set term ^;
execute block as
declare variable n int = 10000000;
begin
while (n>=0) do 
  insert into tmp values(rand()*1000,rand()*1000)
  returning :n-1 into :n;
end^
set term ;^
commit;
set stat off;
create index tmp_f1 on tmp(f1);
set stat on;
commit;
set stat off;
то дождаться результата вот этого:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
set plan on; set stat on;
select a.f1, a.cnt_max from (select a.f1, count(*) cnt_max from tmp a group by a.f1) a 
join (select distinct cnt 
        from (select count(*) cnt from tmp x group by x.f1) 
       order by cnt desc rows 2) x
on a.cnt_max = x.cnt;
set stat off;
commit;
- становится нереально Даже при кеше = 128К.

Наблюдение в ProcessExplorer'e за ФБ_3 (с момента старта запроса) показывает, что сначала он интенсивно читает диск, но затем диск ему становится нужным всё меньше и меньше, пока потребность эта не станет близкой к нулю.
Тут по законам жанра должно расти использование CPU ("ведь кто-то же должен работать!") - ан нет!
ЦПУ так и застрял в нуле!
Я срубил этот запрос по прошествии не менее 15 минут ожидания (трейс при этом не запускал).
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38357473
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот пример

Код: sql
1.
2.
3.
4.
5.
6.
WITH T
AS (SELECT *
    FROM TMP ROWS 100)
SELECT count(*)
FROM T
   JOIN TMP ON T.F2 = TMP.F2



В тройке даёт план

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
PLAN HASH (TMP NATURAL, T TMP NATURAL)

------ Performance info ------
Prepare time = 0ms
Execute time = 3s 448ms
Avg fetch time = 3 448,00 ms
Current memory = 37 042 728
Max memory = 37 283 224
Memory buffers = 8 192
Reads from disk to cache = 40 033
Writes from cache to disk = 0
Fetches from cache = 6 048 349

В 2.5
PLAN MERGE (SORT (TMP NATURAL), SORT (T TMP NATURAL))

Теперь пробуем подставить план от 2.5 в тройку

Код: sql
1.
2.
3.
4.
5.
6.
7.
WITH T
AS (SELECT *
    FROM TMP ROWS 100)
SELECT count(*)
FROM T
   JOIN TMP ON T.F2 = TMP.F2
PLAN MERGE (SORT (TMP NATURAL), SORT (T TMP NATURAL))



Снова получаем

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
План
PLAN HASH (TMP NATURAL, T TMP NATURAL)

------ Performance info ------
Prepare time = 0ms
Execute time = 3s 432ms
Avg fetch time = 3 432,00 ms
Current memory = 37 045 536
Max memory = 37 283 224
Memory buffers = 8 192
Reads from disk to cache = 40 035
Writes from cache to disk = 0
Fetches from cache = 6 040 305
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38357482
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисТо ли это временно сделано для отладки HASH JOIN
именно так
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38357485
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЕсть и еще одна печалька: если заменить 3 ляма на 10
это ожидаемый результат на текущий момент. Сейчас есть смысл тестировать hash join на относительно небольших таблицах.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38357491
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидпамять эта так и остается "зарезервированной"
в виртуалку же смотришь, а надо в используемую физическую память
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38357594
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидЕсть и еще одна печалька: если заменить 3 ляма на 10
это ожидаемый результат на текущий момент. Сейчас есть смысл тестировать hash join на относительно небольших таблицах.Кхм... у мну и на 2.5.3 этот запрос потух, тихо само собою.
Запустил его 2.5 часа взад, получил PLAN MERGE (SORT (SORT (X X ORDER TMP_F1)), SORT (A A ORDER TMP_F1)) - и всё, больше ничего. В PE вижу кардиограмму мертвеца - см аттач.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38357607
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Что-то ночер перестаёт быть томным... :-/
Провалилась скорость вложенных циклов. На мизерных таблицах в 1'000 и 10'000 строк.
Пока проверил БЕЗ индексов:

DDL.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
SQL> recreate table t1(x int); commit;
SQL> recreate table t2(x int); commit;
SQL> insert into t1 select rand()*100 from rdb$types,rdb$types rows 1000;
SQL> insert into t2 select rand()*100 from rdb$types,rdb$types rows 10000;
SQL> commit;
SQL> out nul; set stat on; set plan on;
-- искуственно запрещаем ему делать hash: отрубаем условие равенства, 
-- заменяя его between'ом с границами, аналогичными строгому равенству:
SQL> select a.x,count(*) from t1 a join t2 b on a.x  between b.x and b.x  group by a.x;

FB 3.0: ~14.2 sec
Код: 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.
PLAN SORT (JOIN (A NATURAL, B NATURAL))
Current memory = 584392576
Delta memory = 13904
Max memory = 590817784
Elapsed time= 14.33 sec   14.24   14.22   14.24   14.22
Buffers = 131072
Reads = 0
Writes 0
Fetches = 20251031

 Trace: 
Statement 118:
-------------------------------------------------------------------------------
select a.x,count(*) from t1 a join t2 b on a.x between b.x and b.x group by a.x
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN SORT (JOIN (A NATURAL, B NATURAL))
101 records fetched
  14215 ms, 20251027 fetch(es)

Table                             Natural     Index    Update    Insert    Delet
xpunge
********************************************************************************
******
T1                                   1000

T2                               10000000

FB 2.5.3: ~10.2 sec
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
PLAN SORT (JOIN (A NATURAL, B NATURAL))
Current memory = 555114304
Delta memory = 4560
Max memory = 561407896
Elapsed time= 10.39 sec   10.28   10.22   10.17   10.22
Buffers = 131072
Reads = 0
Writes 0
Fetches = 20251045

 Trace: 
select a.x,count(*) from t1 a join t2 b on a.x between b.x and b.x group by a.x
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN SORT (JOIN (A NATURAL, B NATURAL))
101 records fetched
  10204 ms, 20251027 fetch(es)

Table                             Natural     Index    Update    Insert    Delet
********************************************************************************
T1                                   1000

T2                               10000000
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38357678
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидКхм... у мну и на 2.5.3 этот запрос потух, тихо само собою. Запустил его 2.5 часа взад, получил PLAN MERGE (SORT (SORT (X X ORDER TMP_F1)), SORT (A A ORDER TMP_F1)) - и всё, больше ничего.
ты индекс специально создал, чтобы похерить скорость этого запроса? Ибо никакой пользы от него я не вижу.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38357891
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrты индекс специально создал, чтобы похерить скорость этого запроса? Ибо никакой пользы от него я не вижу.Ну, подумалось что-то, что с ним будет лучше... :-[
Оказалось "как всегда" - надо было меньше думать.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
recreate table tmp(f1 int, f2 int); commit;
set term ^;
execute block as
declare variable n int = 10000000;
begin
while (n>=0) do 
  insert into tmp values(rand()*1000,rand()*1000)
  returning :n-1 into :n;
end^
set term ;^
commit;
----------------------
out nul;
set plan on;
set stat on;
select a.f1, a.cnt_max from (select a.f1, count(*) cnt_max from tmp a group by a.f1) a 
join (select distinct cnt 
        from (select count(*) cnt from tmp x group by x.f1) 
       order by cnt desc rows 2) x
on a.cnt_max = x.cnt;

2.5 выдал в трейсе:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
PLAN MERGE (SORT (SORT (SORT (X X NATURAL))), SORT (SORT (A A NATURAL)))
3 records fetched
  402928  ms, 266808 read(s), 40533616 fetch(es)

Table                             Natural     Index    Update    Insert
xpunge
**************************************************************************
******
TMP                              20000002

3.0 на таком же скрипте выдал:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
PLAN HASH (SORT (SORT (X X NATURAL)), SORT (A A NATURAL))
2 records fetched
  481901  ms, 266817 read(s), 40266815 fetch(es)

Table                             Natural     Index    Update
xpunge
**************************************************************
******
TMP                              20000002

Ладно, время выполнения пока не смотрим - ДЕ сказал, что HJ пока несильно рулит на больших таблицах (кстати: это сколько страниц/строк в них должно быть, чтобы они стали считаться "большими" ?)

Но вот я вижу в ProcessExplorer'e, что диск интенсивно юзался на запись.
Почему это не отражается в writes, пусть даже это были "вспомогательные структуры" ?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38358122
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидНо вот я вижу в ProcessExplorer'e, что диск интенсивно юзался на запись.
Почему это не отражается в writes, пусть даже это были "вспомогательные структуры" ?
reads/writes/fetches/marks - это счетчики страничного кеша, который используется для работы с файлом БД. Активность временных файлов к кешу не относится и ими не фиксируется. Для этого будут вводиться отдельные счетчики.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38358126
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидкстати: это сколько страниц/строк в них должно быть, чтобы они стали считаться "большими"
более 100К строк примерно
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38358234
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидНо вот я вижу в ProcessExplorer'e, что диск интенсивно юзался на запись.
Почему это не отражается в writes, пусть даже это были "вспомогательные структуры" ?
reads/writes/fetches/marks - это счетчики страничного кеша, который используется для работы с файлом БД. Активность временных файлов к кешу не относится и ими не фиксируется. Для этого будут вводиться отдельные счетчики.Теперь понятно, спасибо. Это будет тоже в 3.х введено ?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38358249
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

надеюсь да
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38358554
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидты индекс специально создал, чтобы похерить скорость этого запроса? Ибо никакой пользы от него я не вижуПользы от него нет, но получается, что ФБ при его наличии.... фактически перестаёт работать с единственным запросом, который ему передан.
Это видно и в ProcessExplorere'e (нулевые как ЦПУ, так и очередь к диску), и в mon$-таблицах.
В аттаче - лог результатов запросов к mon$io_stats и mon$record_stats, с интервалом ~ в одну минуту.

Видно же невоор. глазом, что ФБ почти ничего не делает!
ПОЧЕМУ ?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38358666
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидПОЧЕМУ ?Потому что RANDOM IO
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38358689
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladПотому что RANDOM IOНу, и ? вот идёт ФБ себе по индексу, видит ключ_1. Дальше он вытаскивает соотв-щий rdb$db_key и прыгает в DP. Дальше делает "прыг" по индексу на ключ_2, и опять лезет в DP.
Я должен видеть эту его активность в mon$-таблицах. И там какая-то активность действительно есть. Призрачная только - см аттаченный файл, в который статистика собиралась 1 раз в минуту несколько раз.
Такой "немощи" никогда не бывает, например, при обычном select * from t order by <indexed_field>.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38358775
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

я уже 15 минут пытаюсь найти посты, относящиеся только к этому вопросу - это невозможно.
ЗАДАВАЙ ОДИН ВОПРОС В ОДНОЙ ТЕМЕ
или я буду этот бардак игнорировать не читая.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38358789
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladя уже 15 минут пытаюсь найти посты, относящиеся только к этому вопросу - это невозможно.
ЗАДАВАЙ ОДИН ВОПРОС В ОДНОЙ ТЕМЕ или я буду этот бардак игнорировать не читая.А как ты искал, по " Всем темам автора " ? Так это не правильно, там уже давно трудно искать
Я обычно пытаюсь "возвращаться в топег", если сам могу его найти и если это не приведёт к его "перепрыгиванию" на совсем другой вопрос.
А про random_io - это мы в личке обсуждали, см прения от 00:11:35 17/09/2011 (key phrase: random io творит "чудеса"). Но то касалось валидации базы gfix'ом, я даже CORE-3602 завел в трекере тогда. Но валидация - это совсем другая тема.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38358800
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидА как ты искалЯ искал глазами, в одной этой теме.
Я не буду выворачиваться наизнанку, для того, чтобы фильтровать 10 потоков сознания в одной теме в поисках одного из них.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38358823
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТаблоидА как ты искалЯ искал глазами, в одной этой теме.
Я не буду выворачиваться наизнанку, для того, чтобы фильтровать 10 потоков сознания в одной теме в поисках одного из них.Ну так я специально запихивал разные вопросы в одну тему, т.к. речь в них идет всё равно об одном, а именно: о сравнении производительности 2.5 и 3.0. пару лет взад я также по трейсу натолкал много разных вопросов, но все они касались общего - трейса.

Ладно, если это не удобно для поиска, буду ваять по-старому: 1 вопрос = 1 топег. Лишь бы в помойку, как тут , не превратилось :-)

Но всё-таки прошу вопрос про отсутствие жизнедеятельности ФБ при выполнении конкретного запроса, указанного выше в этом топеге, добить здесь же .

Запрос этот молотит уже 4 часа. Я логирую отдельным "мониторным окном" 1 раз в 1 минуту значения в двух таблицах: mon$io_stats & mon$record_stats.
Лог накапливается в виде текста, и два результата из него: на 16:07 и на 19:07, я вытряхнул в эксель, расположил их "попарно вместе" (io к io, rec к rec) и вычел из значений на 19:07 значения на 16:07 - см. аттач.

Так вот, вопросик у мну.
Как такое может быть, что за ТРИ ЧАСА:
1) прочиталось всего ~113000 страниц (см лист "MON$IO_STATS_1607_vs_1907", группа ячеек выделена желтым цветом) ?
2) было совершено 48'700 seq_reads и "аж" 4'4 млн idx_reads ?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38358869
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТаблоидПОЧЕМУ ?Потому что RANDOM IO
Таблоиду нужно подарить SSD, вторым диском, для тестов (или дать погонять).
Я не сомневаюсь что у него получится раскрыть настоящую правду про Firebird+SSD :)
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38358888
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDeeу него получится раскрыть настоящую правду про Firebird+SSD :)дык это... что мешает почтеннейшим посетителям нашего кабачка, а также его завсегдатаям, повторить эти несложные тесты "у себя дома" ? Авось, и новое чего нароете.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38358893
чччД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У нас в серверной куча убитых ssd валяется. Думали, на шару можно на обычных ssd взлететь.
...
Сейчас, вроде, на коробочках с ширпотребовскими ssd прямо пишут: "Не для серверов".
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38358908
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDeeТаблоиду нужно подарить SSD, вторым диском, для тестов
проще ему подарить пиво. "серверные" SSD весьма дороги, и у них там все несколько иначе работает, чем у десктопных.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38358909
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
чччДУ нас в серверной куча убитых ssd валяется. Думали, на шару можно на обычных ssd взлететь.
...
Сейчас, вроде, на коробочках с ширпотребовскими ssd прямо пишут: "Не для серверов".
Вот серверный SSD от Intel: http://www.thg.ru/storage/obzor_intel_dc_s3700_test/index.html
Цены на price.ru: http://price.ru/search/pc-components/ssd/offers/?query=Intel SSD DC S3700&auto=1
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38358910
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
чччДУ нас в серверной куча убитых ssd валяется. Думали, на шару можно на обычных ssd взлететь.
дык. рассказывай. марка, модель, сколько проработало.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38358949
чччД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvчччДУ нас в серверной куча убитых ssd валяется. Думали, на шару можно на обычных ssd взлететь.
дык. рассказывай. марка, модель, сколько проработало.
На днях в офис загляну, расспрошу поподробнее.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38358972
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDee, чччД, kdv! товарищи!
один мой топег уже успешно был засорён оффтопом. Если не затруднит, идите какать куда-нить в другое место, плз...
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38358978
чччД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоиду, имхо, саперную лопатку подарить надо.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38358987
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
чччДТаблоиду, имхо, саперную лопатку подарить надо.Их есть у меня: Диля внезапно выслал на Новый год, полтора года взад :-)
Но какать оффтопить таки лучше идите все в Пятницу :-)
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38359021
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидто дождаться результата вот этого:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
set plan on; set stat on;
select a.f1, a.cnt_max from (select a.f1, count(*) cnt_max from tmp a group by a.f1) a 
join (select distinct cnt 
        from (select count(*) cnt from tmp x group by x.f1) 
       order by cnt desc rows 2) x
on a.cnt_max = x.cnt;
set stat off;
commit;
- становится нереальноНу, как сказать, я смог выждать аж 70 сек :)
Код: 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.
Query
------------------------------------------------
select a.f1, a.cnt_max
  from (select a.f1, count(*) cnt_max from tmp a group by a.f1) a
  join (select distinct cnt
         from (select count(*) cnt from tmp x group by x.f1)
        order by cnt desc rows 2) x
    on a.cnt_max = x.cnt;


Plan
------------------------------------------------
PLAN HASH (SORT (X X ORDER TMP_F1), A A ORDER TMP_F1)

Query Time
------------------------------------------------
Prepare       : 0.00 ms
Execute       : 68 734.00 ms
Avg fetch time: 34 367.00 ms

Memory
------------------------------------------------
Current: 565 226 992
Max    : 565 293 896
Buffers: 65 000

Operations
------------------------------------------------
Read   : 441 525
Writes : 0
Fetches: 59 570 905
Marks  : 0


Enchanced Info:
+--------------------------+-----------+-----------+-------------+---------+---------+---------+----------+----------+----------+
|        Table Name        |  Records  |  Indexed  | Non-Indexed | Updates | Deletes | Inserts | Backouts |  Purges  | Expunges |
|                          |   Total   |   reads   |    reads    |         |         |         |          |          |          |
+--------------------------+-----------+-----------+-------------+---------+---------+---------+----------+----------+----------+
|                       TMP|         0 |  20000002 |           0 |       0 |       0 |       0 |        0 |        0 |        0 |
+--------------------------+-----------+-----------+-------------+---------+---------+---------+----------+----------+----------+

ТаблоидДаже при кеше = 128К.Так ты ведь кеш файловой системы выкинул. Действительно - а зачем он нужен ?
Он был бы не нужен, если бы ты сначала всю таблицу в кеш ФБ затянул, быстрым натуралом.
Но ты не ищешь лёгких путей (я знаю) :)

ТаблоидНаблюдение в ProcessExplorer'e за ФБ_3 (с момента старта запроса) показывает, что сначала он интенсивно читает диск, но затем диск ему становится нужным всё меньше и меньше, пока потребность эта не станет близкой к нулю.
Тут по законам жанра должно расти использование CPU ("ведь кто-то же должен работать!") - ан нет!Наблюдать тоже надо знать как. Твой нижний график в PE (который IO), означает совсем не чтения с диска, а чтения из файлового кеша.
Который, очевидно, не содержал в себе всей таблицы (про индекс я молчу) в начале выполнения запроса.
Потому ты и наблюдаешь быстрые чтения из кеша в начале процесса и мало-мало потом, когда кеш не в состоянии обслужить твой запрос.
А так как random'ность в твоём тесте дичайшая, то и получаешь ты честную сотню страниц в секунду...
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38359027
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladНу, как сказать, я смог выждать аж 70 сек :)
<...>
Buffers: 65 000
<...>
ТаблоидДаже при кеше = 128К.Так ты ведь кеш файловой системы выкинул. Действительно - а зачем он нужен ? Почему это "выкинул" ? я отлично помню, что этот выкидыш будет только при установке DefaultDBCachePages > FileSystemCacheThreshold, налетал уже раньше на эти грабли :-)
А потому сразу же вонзил в firebird.conf FileSystemCacheThreshold = 512K , что какбэ больше 128К :-)
Или на этот параметр (FileSystemCacheThreshold) есть какое-то "скрытое ограничение сверху", при превышении которого файловый кеш всё таки будет игнорироваться ?

hvladТвой нижний график в PE (который IO), означает совсем не чтения с диска, а чтения из файлового кеша.
Который, очевидно, не содержал в себе всей таблицы (про индекс я молчу) в начале выполнения запроса.
Потому ты и наблюдаешь быстрые чтения из кеша в начале процесса и мало-мало потом, когда кеш не в состоянии обслужить твой запрос.
А так как random'ность в твоём тесте дичайшая, то и получаешь ты честную сотню страниц в секунду...ОК, я проверю попозжее следующее: перегружу этот сервак и запущу на нём скрипт со 100500 командами вида:
Код: plaintext
1.
2.
3.
select * from tmp where x = 123654;
select * from tmp where x = 951032;
select * from tmp where x = 357148;
...
- это ведь тоже будет дичайший рандом, так ?
Ну, и запущу также мониторинг, аналогичный: из mon$io_stats + mon$rec_stats. Надо будет сравнить "скорость полета".

Пока же установил кеш базы = 65000 страниц, рестартовал ФБ и запустил запрос и мониторинг по-новой.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38359034
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидПока же установил кеш базы = 65000 страниц, рестартовал ФБ и запустил запрос и мониторинг по-новой.В общем, оставляю его летать одного в ночи с 64К буферами кеша. Ибо конца-краю этому кисляку не видно - см аттач, ЦПУ опять в нуле, диск еле-еле дёргается.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38359092
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидТаблоидПока же установил кеш базы = 65000 страниц, рестартовал ФБ и запустил запрос и мониторинг по-новой.В общем, оставляю его летать одного в ночи с 64К буферами кеша. Ибо конца-краю этому кисляку не видно - см аттач, ЦПУ опять в нуле, диск еле-еле дёргается.В общем, чудес не бывает: за ночь так ничего и не родилось, несмотря на кеш = 65000.
Например, за три часа с 05:00 по 08:00 изменения в mon$io_stats - такие же нищенские, как и при кеше = 128К:
DTSMON$STAT_IDMON$STAT_GROUPMON$PAGE_READSMON$PAGE_WRITESMON$PAGE_FETCHESMON$PAGE_MARKS05:00:45.576010382446490417825179113305:00:45.57602103656405:00:45.576032001005:00:45.5760430033005:00:45.5760513824984117679140205:00:45.5760623824943017678432005:00:45.5760733824772017678008005:00:45.576081002105:00:45.576091002108:00:12.0760105212878159624372225199808:00:12.07602103656408:00:12.076032001008:00:12.0760430033008:00:12.0760515213197124111577208:00:12.0760625213156024110869008:00:12.0760735212985024110445008:00:12.076081002108:00:12.0760910021differences:10 1 388 414 692 6 547 046 865 21 - - - - 32 - - - - 43 - - - - 51 1 388 213 - 6 432 437 - 62 1 388 213 - 6 432 437 - 73 1 388 213 - 6 432 437 - 81 - - - - 91 - - - -

Ну, и по mon$record_stats дифференты тоже совсем не айс:
DTSMON$STAT_IDMON$STAT_GROUPMON$RECORD_SEQ_READSMON$RECORD_IDX_READS05:00:48.59101049940714797605:00:48.5910212202605:00:48.5910320005:00:48.5910430805:00:48.591051220714308805:00:48.5910620714304905:00:48.5910730714304105:00:48.5910810005:00:48.5910910008:00:18.73201088000975866308:00:18.7320212202608:00:18.7320320008:00:18.7320430808:00:18.732051220974889308:00:18.7320620974885408:00:18.7320730974884608:00:18.7320810008:00:18.73209100difference:10 38 060 2 610 687 21 - - 32 - - 43 - - 51 - 2 605 805 62 - 2 605 805 73 - 2 605 805 81 - - 91 - -
2.6 млн индексных чтений за три часа, т.е. 240 idx_reads в секунду - это совсем не айс...
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38359120
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
То ли ФБ-3 именно на виндузе (2003 server sp2) так тупит, то ли диск на этой тачке совсем #%$$#&!
Ибо на линухе всё просто взлетело, на тех же данных и кеше = 65000. И это было видно сразу - CPU был загружен по-взрослому:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
top - 09:05:29 up 7 days, 12:37,  3 users,  load average: 0.22, 0.35, 0.43
Tasks: 125 total,   1 running, 124 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  : 70.7%us, 29.3%sy,  0.0%ni,  0.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.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.0%sy,  0.0%ni,100.0%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:   4056652k total,  2388800k used,  1667852k free,   193488k buffers
Swap: 16383996k total,     9056k used, 16374940k free,  1591792k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 7940 firebird  20   0  810m 308m 7144 S 99.8  7.8   0:52.26 firebird
    1 root      20   0 19400 1220 1032 S  0.0  0.0   0:19.30 init        

Код: 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.
Select Expression
    -> Filter
        -> Hash Join (inner)
            -> First N Records
                -> Sort
                    -> Aggregate
                        -> Table "X X" Access By ID
                            -> Index "TMP_F1" Scan
            -> Record Buffer
                -> Aggregate
                    -> Table "A A" Access By ID
                        -> Index "TMP_F1" Scan

          F1               CNT_MAX
============ =====================
         526                 10291
         427                 10280

Current memory = 15150432
Delta memory = 14308912
Max memory = 15365808
Elapsed time= 47.59 sec
Cpu = 0.00 sec
Buffers = 65000
Reads = 10676063
Writes = 4
Fetches = 49414923
SQL> set stat off;
SQL> commit;

.................

PLAN HASH (SORT (X X ORDER TMP_F1), A A ORDER TMP_F1)
2 records fetched
  47584 ms, 10675853 read(s), 49413773 fetch(es)

Table                             Natural     Index
******************************************************
TMP                                        20000002

PS. Странно, впрочем, что у Влада был сильно другой результат по числу фетчей:
Код: plaintext
1.
2.
3.
Read   : 441 525
Writes : 0
Fetches: 59 570 905
Marks  : 0
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38359414
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид240 idx_reads в секундуhvladА так как random'ность в твоём тесте дичайшая, то и получаешь ты честную сотню страниц в секунду...Ты до сих пор удивлён ?

ТаблоидТо ли ФБ-3 именно на виндузе (2003 server sp2) так тупит, то ли диск на этой тачке совсем #%$$#&!
Ибо на линухе всё просто взлетелоНет, там всё уже было в файловом кеше
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38359489
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladв 3-ке (пока ещё) сломана защита от большого натурального скана.Вроде починил, завтра сможешь проверить.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38359510
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТаблоид240 idx_reads в секундуhvladА так как random'ность в твоём тесте дичайшая, то и получаешь ты честную сотню страниц в секунду...Ты до сих пор удивлён ?Уже нет. Запустил перфмон и вижу, что диск на эту машину был принесён с помойки:
1) средняя длина очереди диска = 1.12 (x 100.000)
2) средняя скорость чтения с диска, байт/сек, = 770000 (x 0.0001)
3) среднее время чтения с диска, сек, = 0.007 (x 1000.000).

На этом навозе можно только детские тесты запускать :(
Перейду-ка на линух снова. Там хоть и виртуалка с 4 гигами, но зато шевелится.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38359511
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladhvladв 3-ке (пока ещё) сломана защита от большого натурального скана.Вроде починил, завтра сможешь проверить.ОК, псип.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38359526
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЗапустил перфмон и вижу, что диск на эту машину был принесён с помойки:
1) средняя длина очереди диска = 1.12 (x 100.000)
2) средняя скорость чтения с диска, байт/сек, = 770000 (x 0.0001)
3) среднее время чтения с диска, сек, = 0.007 (x 1000.000).Совершенно обычный десктопный винт. Просто с пустым кешем тяжко получить с него нечто бОльшее.
Сделай count(*) по таблице перед тестом, удивишься.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38359632
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladСовершенно обычный десктопный винт. Просто с пустым кешем тяжко получить с него нечто бОльшее.
Сделай count(*) по таблице перед тестом, удивишься.Сделал, два раза для верности :-)
Оба раза были reads = ~ 133500 страниц, при том что:
Код: plaintext
1.
2.
3.
PAGE_SIZE 4096
Number of DB pages allocated =  150607 
SQL> show table;
       TMP
- т.е. в кеш подключения (65000) мало что влезло.
Код: 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.
Database:  192.168.0.201/3330:empty30, User:
SQL> set stat on; select count(*) from tmp;

                COUNT
=====================
             10000001

Current memory = 289655072
Delta memory = 360920
Max memory = 289768136
Elapsed time= 12.17 sec
Buffers = 65000
Reads = 133584
Writes 0
Fetches = 20198532
SQL> set stat on; select count(*) from tmp;

                COUNT
=====================
             10000001

Current memory = 289655072
Delta memory = 0
Max memory = 289768136
Elapsed time= 12.53 sec
Buffers = 65000
Reads = 133485
Writes 0
Fetches = 20133480

И это выглядит как-то странно: что помешало содержимому таблицы "зацепиться посильнее" за кеш ?..

В общем, жду опять уже 20 в лишним минут. Срубаю к ЧМ.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38359659
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидВ общем, жду опять уже 20 в лишним минутА сколько у тебя там памяти всего ?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38359737
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Блин, прочухалась машина эта.
И причина была простая: в разеделе "Свойства системы" / "Дополнительно" / "Быстродействие" / "Параметры", дальше в отдельном окне опять во вкладке "Дополнительно" кто-то из недоброжелателей ФБ установил радиокнопки на оптимизацию работы ПРОГРАММ, вместо служб, и использование памяти также было оптимизировано под программы, вместо системного кеша (см скриншот).
В общем, после рестарта компа и удаления ненужных старых служб файловый кеш стал равен 450 мегов вместо прежних 140-150.
Ну, и родилось наконец-то за 12 минут.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
SQL> set plan on; set stat on;
SQL> select a.f1, a.cnt_max from (select a.f1, count(*) cnt_max from tmp a group by a.f1) a
CON> join (select distinct cnt
CON>         from (select count(*) cnt from tmp x group by x.f1)
CON>        order by cnt desc rows 2) x
CON> on a.cnt_max = x.cnt;

PLAN HASH (SORT (X X ORDER TMP_F1), A A ORDER TMP_F

          F1               CNT_MAX
============ =====================
         781                 10337
         444                 10329

Current memory = 303123000
Delta memory = 13479304
Max memory = 303754112
Elapsed time= 766.94 sec
Buffers = 65000
Reads = 10659939
Writes 52
Fetches = 49373746
SQL> set stat off;
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38359740
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТаблоидВ общем, жду опять уже 20 в лишним минутА сколько у тебя там памяти всего ?1 Гб. Но проблема была не в этом нищенском размере, а в настройке быстрод-вия Win 2003 Server'a как простой рабочей станции. Кто это сделал - уже не выяснить. Но руки я бы им поотшибал непременно.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38359773
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТаблоид240 idx_reads в секундуhvladА так как random'ность в твоём тесте дичайшая, то и получаешь ты честную сотню страниц в секунду...Ты до сих пор удивлён ?

ТаблоидТо ли ФБ-3 именно на виндузе (2003 server sp2) так тупит, то ли диск на этой тачке совсем #%$$#&!
Ибо на линухе всё просто взлетелоНет, там всё уже было в файловом кешеВернемся к нашим баранам.
Дичайший рандом_io, как выясняется, не так уж страшен, если ФБ имеет б о льший процент попаданий при поиске в файловом кеше, чем некий "страшный порог".
То число страниц, которые он вытряхнул с диска (Reads = 10'659'939), а не из кеша, НЕ говорит ничего о времени, потраченном на это. А диск - самое узкое место.

Так вот, вопрос: можно ли завести доп. счетчик производительности (в трейсе или видимый только set stat on - пофигу), показывающий именно время , затраченное на вычитку данных с ДИСКА, а не из кеша операционки ? Грубо говоря, показать Reads * <среднее время на 1 reads в ms> - можно ?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38359783
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидТак вот, вопрос: можно ли завести доп. счетчик производительности (в трейсе или видимый только set stat on - пофигу), показывающий именно время , затраченное на вычитку данных с ДИСКА, а не из кеша операционки ? Грубо говоря, показать Reads * <среднее время на 1 reads в ms> - можно ?Программа понятия не имеет, откуда ОСь дала ей данные.
Среднее время read\write вывести можно. Я только пока не уверен, что это будет бесплатно.
Ну и за большой период времени это будет так же бесполезно, как и средняя тем-ра по больнице.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38359796
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladСреднее время read\write вывести можно. Я только пока не уверен, что это будет бесплатно.
Ну и за большой период времени это будет так же бесполезно, как и средняя тем-ра по больнице.Если будет не только среднее, но еще и min/max время одного reads'a/writes'a, то будет ясен разброс значений и "степень доверия" к среднему.
А что касается платы за это - всегда можно сравнить, если будет вкл/вЫкл в trace.conf'e
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38359893
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидТак вот, вопрос: можно ли завести доп. счетчик производительности (в трейсе или видимый только set stat on - пофигу), показывающий именно время , затраченное на вычитку данных с ДИСКА, а не из кеша операционки ?
это будет ближе к бете, но исключительно опционально, ибо дорого
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38359908
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrэто будет ближе к бете, но исключительно опционально, ибо дорогов трекер нужно заносить, чтобы не забылось ?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38359985
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

нет
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38360137
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидпосле рестарта компа и удаления ненужных старых служб файловый кеш стал равен 450 мегов вместо прежних 140-150.
Ну, и родилось наконец-то за 12 минут.Рано я радовался. Рестартанул комп еще разок, проверил затем, что нет старых сервисов и файловый кеш снова около 450 Мб - да, всё ОК.
Запустил isql, провел предварительную "вычитку" таблицы (select count(*) from ...).
Запустил основной запрос - и он заклинил, гад, почти на 3 часа
Код: 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.
C:\1Install\fb30>isql 192.168.0.201/3330:empty30 -user sysdba -pas masterke -n
Database:  192.168.0.201/3330:empty30, User: sysdba
SQL> out nul; select count(*) from tmp;
SQL> set plan on; set stat on;
SQL> select a.f1, a.cnt_max from (select a.f1, count(*) cnt_max from tmp a group by a.f1) a
CON> join (select distinct cnt
CON>         from (select count(*) cnt from tmp x group by x.f1)
CON>        order by cnt desc rows 2) x
CON> on a.cnt_max = x.cnt;

PLAN HASH (SORT (X X ORDER TMP_F1), A A ORDER TMP_F1)
Current memory = 304264576
Delta memory = 14620920
Max memory = 304936248
Elapsed time=  6643.75 sec 
Buffers = 65000
Reads = 10663599
Writes 460
Fetches = 49437024
SQL> set stat off;
.................................
6643597 ms, 10659719 read(s), 49365119 fetch(es)

Table                             Natural     Index
****************************************************
TMP                                        20000002


Что измениться могло по сравнению с неслыханной удачей, когда роды прошли за 12 минут - не понимаю.
Однако, в ProcExplorer'e активность диска стала уже другой - см аттач: диск явно ожил.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38361482
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladв 3-ке (пока ещё) сломана защита от большого натурального скана.Проверил на WI-T3.0.0.30583 - починилось, работает :-)
Natural больше не вытесняет результаты индексных поисков.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38363639
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 dimitr: а будет ли в ФБ-3 что-то делаться вот по этому направлению ?
dimitr http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=904994&msg=11800732
... в 3-ке есть желание многое переделать во внутренностях мониторинга, как насчет изоляции, так и насчет алгоритмики. я проверил тест из того топика на скорость получения ID аттача и транзакции из mon$transactions vs current_connection + current_transaction - и вижу, что воз и ныне там. Различие в 6 с лишним раз.
current_connection, current_transaction: 3.47"
Код: 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.
SQL> select cast('now' as timestamp) t0 from rdb$database;

T0                              2013-08-12 17:22:35.6040


SQL> set stat on;
SQL> set term ^;
SQL> execute block as
CON>   declare n int = 10000000;
CON>   declare v_att int;
CON>   declare v_trn int;
CON> begin
CON>   while (n>0) do begin
CON>     v_att=current_connection;
CON>     v_trn=current_transaction;
CON>     n=n-1;
CON>   end
CON> end^
Current memory = 311518264
Delta memory = 9528
Max memory = 313634856
Elapsed time= 3.47 sec
Buffers = 65000
Reads = 0
Writes 0
Fetches = 0
SQL> set term ;^
SQL> set stat off;
SQL> rollback;
SQL> set echo off;
SQL> select cast('now' as timestamp) t1 from rdb$database;

T1                              2013-08-12 17:22:39.1090
mon$transactions: 22.7"
Код: 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> select cast('now' as timestamp) t0 from rdb$database;

T0                              2013-08-12 17:35:00.3590


SQL> set stat on;
SQL> set term ^;
SQL> execute block as
CON>   declare n int = 10000000;
CON>   declare v_att int;
CON>   declare v_trn int;
CON>   declare x_att int;
CON>   declare x_trn int;
CON> begin
CON>   v_att=current_connection;
CON>   v_trn=current_transaction;
CON>   while (n>0) do begin
CON>     select mon$attachment_id, mon$transaction_id
CON>     from mon$transactions
CON>     where mon$attachment_id = :v_att and mon$transaction_id = :v_trn
CON>     into x_att, x_trn;
CON>     n=n-1;
CON>   end
CON> end^
Current memory = 311545968
Delta memory = 85440
Max memory = 313634856
Elapsed time= 22.74 sec
Buffers = 65000
Reads = 0
Writes 0
Fetches = 1
SQL> set term ;^
SQL> set stat off;
SQL> rollback;
SQL> set echo off;
SQL> select cast('now' as timestamp) t1 from rdb$database;

T1                              2013-08-12 17:35:23.1180
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38363740
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И еще пара вопросов.

1. В топеге про сортировку широких выборок было как-то сказано:dimitrв 3.0 будет мониторинг temp-хранилищаЭто будет в альфе или в бете ? И будет ли вообще ?

2. Примерно в то же время (не могу пока найти тынц) тут была приведена ссылка на спецбилд ФБ, в котором был реализован пересмотренный алгоритм сортировки. В алгоритме этом вместо сортировки всех кортежей (ключей + всех остальных полей) идет сортировка только ключей с последующим соединением со всеми остальными полями. Я тестировал ту сборку, вроде бы даже находил одну-две баги (отсылал в личку).
Но хотелось бы "намять бока" этой сборку на линухе. Реально ли сиё ?
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38363829
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

1. будет в бете
2. собирать сам будешь
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38388392
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидпока ФБ не выполнит откаты обрубленного bulk DML ?откаты обрубленного будут ускорены, ты же сам об этом просил в трекереГлянул сегодня и... неужто дождались ?!.. http://svn.code.sf.net/p/firebird/code/firebird/trunk/ChangeLog
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
 2013-09-04 17:52  dimitr 
   M src/jrd/jrd.cpp
Avoid rescheduling if we're kindly asked to stop immediately.

 2013-09-04 17:46  dimitr 
   M src/jrd/Attachment.h
   M src/jrd/jrd.cpp
Cleanup and use the explicit rollback via TIP for all kinds of forced disconnections.
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38388393
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

это другое (оно связано, но совсем чуть-чуть)
...
Рейтинг: 0 / 0
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38417783
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидВах!.. а в чём там дело было ? Такое ускорение выглядит как-то... подозрительно
ничего сверхестественного, глянь в трекере . Оно давно напрашивалось, но руки дошли только сейчас. Правда, эффект несколько больше ожидаемого :-) но твои тесты вечно не от мира сего...



Тут обнаружил что сломался рекурсивный запрос если он идёт по двум и более веткам.

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
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.
WITH RECURSIVE H 
AS (SELECT 1 AS CODE_HORSE, 
           2 AS CODE_FATHER, 
           3 AS CODE_MOTHER 
    FROM RDB$DATABASE 
    UNION ALL 
    SELECT 2 AS CODE_HORSE, 
           4 AS CODE_FATHER, 
           5 AS CODE_MOTHER 
    FROM RDB$DATABASE 
    UNION ALL 
    SELECT 3 AS CODE_HORSE, 
           4 AS CODE_FATHER, 
           5 AS CODE_MOTHER 
    FROM RDB$DATABASE 
    UNION ALL 
    SELECT 4 AS CODE_HORSE, 
           NULL AS CODE_FATHER, 
           NULL AS CODE_MOTHER 
    FROM RDB$DATABASE 
    UNION ALL 
    SELECT 5 AS CODE_HORSE, 
           NULL AS CODE_FATHER, 
           NULL AS CODE_MOTHER 
    FROM RDB$DATABASE), 
R 
AS (SELECT H.CODE_HORSE AS CODE_HORSE, 
           H.CODE_FATHER AS CODE_FATHER, 
           H.CODE_MOTHER AS CODE_MOTHER, 
           CAST('' AS VARCHAR(10)) AS MARK, 
           0 AS DEPTH 
    FROM H 
    WHERE H.CODE_HORSE = 1 
    UNION ALL 
    SELECT H.CODE_HORSE AS CODE_HORSE, 
           H.CODE_FATHER AS CODE_FATHER, 
           H.CODE_MOTHER AS CODE_MOTHER, 
           'F' || R.MARK AS MARK, 
           R.DEPTH + 1 AS DEPTH 
    FROM R 
    JOIN H ON R.CODE_FATHER = H.CODE_HORSE 
    WHERE R.DEPTH < 5 
    UNION ALL 
    SELECT H.CODE_HORSE AS CODE_HORSE, 
           H.CODE_FATHER AS CODE_FATHER, 
           H.CODE_MOTHER AS CODE_MOTHER, 
           'M' || R.MARK AS MARK, 
           R.DEPTH + 1 AS DEPTH 
    FROM R 
    JOIN H ON R.CODE_MOTHER = H.CODE_HORSE 
    WHERE R.DEPTH < 5) 
SELECT * 
FROM R 



FB 2.5

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
CODE_HORSE CODE_FATHER CODE_MOTHER MARK DEPTH 
         1    2    3        0 
         2    4    5    F   1 
         4              FF  2 
         5              MF  2 
         3    4    5    M   1 
         4              FM  2 
         5              MM  2 

FB 3.0

Код: plaintext
1.
2.
3.
CODE_HORSE CODE_FATHER CODE_MOTHER MARK DEPTH 
         1    2    3    0 
         2    4    5    F   1 
         4              FF  2 

Это случано не связано с оптимизацией UNION? В трекере создал тикет CORE-4240
...
Рейтинг: 0 / 0
161 сообщений из 161, показаны все 7 страниц
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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