ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
25 сообщений из 161, страница 2 из 7
  2  все
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352605
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
я бы сказал, что в этой теме не стоит (пока что) кричать караул и вопрошать "а почему?", надо просто выкладывать тесты и цифры результатов. А потом сравнить с бетой или RC.
...
Рейтинг: 0 / 0
02.08.2013, 11:36:04
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38352719
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Наконец-то официальная альфа тройки вышла. Теперь можно релиз-ноты почитать.
...
Рейтинг: 0 / 0
02.08.2013, 12:25:15
| Ответить | Цитировать | Написать  
Сравнение производительности 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
02.08.2013, 14:44:38
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38353169
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Причём тут GTT. Вставка, обновление и удаление на тройке медленнее чем на 2.5 и для обычных таблицы
...
Рейтинг: 0 / 0
02.08.2013, 15:20:11
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38353197
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов ДенисПричём тут GTT. Вставка, обновление и удаление на тройке медленнее чем на 2.5 и для обычных таблицы1) то, что работу с GTT оптимизировать можно и, наверное , это будет сделано - об этом говорил Влад (см предыдущий мой пост). Про ускорение dml c fixed-таблицами он не говорил - ни прямо, ни намёками. По кр. мере, за последние 3 года я не видел этого :-)
2) я вчера тестил только вставки в fixed-таблицу, в моноконнекте. Сильного проседания не заметил. Давай свой тест "на погляд", плз.
...
Рейтинг: 0 / 0
02.08.2013, 15:34:08
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38353302
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
чуть позже обязательно предоставлю.
...
Рейтинг: 0 / 0
02.08.2013, 16:24:46
| Ответить | Цитировать | Написать  
Сравнение производительности 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
02.08.2013, 21:33:53
| Ответить | Цитировать | Написать  
Сравнение производительности 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
03.08.2013, 10:37:25
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38353823
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидвопиющая о необходимости своей проверки
оптимизатор проверять еще рано, он в альфе практически не менялся. Всему свое время.

ТаблоидНа WI-V2.5.3.26682 ситуация с обоими вариантами точно такая же
ну и что тогда этот тест делает в этой ветке?
...
Рейтинг: 0 / 0
03.08.2013, 10:56:22
| Ответить | Цитировать | Написать  
Сравнение производительности 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
03.08.2013, 11:16:05
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38353844
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидА когда примерно проверять можно будет ?
Beta 1

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

По поводу потребления памяти тройкой. Рано радуешься. Взгляни в диспетчер задач. Там он рисует значение в сотни раз больше чем показывает в статистике. Вероятно из этой статистики исключена память занятая кэшем.
...
Рейтинг: 0 / 0
03.08.2013, 23:56:25
| Ответить | Цитировать | Написать  
Сравнение производительности 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
04.08.2013, 02:33:50
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354161
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
первое, что я вижу - что ты тестируешь 2.5 в архитектуре SC или CS. Вопрос - нафига, если тебе нужны равные условия? Во-вторых, статистика в 3.0 неисправна - в нее не попадает кеш и значения под 4GB явно левые, не соответствующие истине. Как поправим - отпишусь, надо будет повторить тест.

ЗЫ. твой второй "мониторный" коннект только мешает смотреть, делай селект из MON$ в том же коннекте что и тест.
...
Рейтинг: 0 / 0
04.08.2013, 09:12:11
| Ответить | Цитировать | Написать  
Сравнение производительности 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
04.08.2013, 10:05:18
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354186
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидкак только будет сравнение работы нескольких коннектов, надо будет вернуть 2.5 в режим SuperClassic'a. Я прав ?
проверять надо будет на всех архитектурах, чтобы иметь отправную точку в виде "немасштабируемого" старого SS
...
Рейтинг: 0 / 0
04.08.2013, 10:41:01
| Ответить | Цитировать | Написать  
Сравнение производительности 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
04.08.2013, 10:47:50
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354197
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид,

пытаюсь воспроизвести большие числа в allocated-счетчиках и не могу, у меня там все нормально. Для свежесозданной базы без данных у тебя такое же безобразие выдается?
...
Рейтинг: 0 / 0
04.08.2013, 11:04:49
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354200
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидПовторил запрос, mon$-таблицу запрашивал из этого же isql-окна
признавайся, коммитился перед вторым MON$-запросом? Надо так: mon$-commit-test-mon$.
...
Рейтинг: 0 / 0
04.08.2013, 11:06:53
| Ответить | Цитировать | Написать  
Сравнение производительности 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
04.08.2013, 11:32:18
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354209
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrпытаюсь воспроизвести большие числа в allocated-счетчиках и не могу, у меня там все нормально. Для свежесозданной базы без данных у тебя такое же безобразие выдается?Сейчас попробую на отресторенной. Только не знаю, сколько этот b/r будет длиться, ибо .fdb весит под гиг.
...
Рейтинг: 0 / 0
04.08.2013, 11:33:22
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354212
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидя рестартовал ФБ_2.5 и выполнил вот это
чем бы в тебя запустить отсюда? Я тебе говорю НЕ КОММИТИТЬ после выполнения тестового запроса, а ты опять за свое...
...
Рейтинг: 0 / 0
04.08.2013, 11:39:47
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354213
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид.fdb весит под гиг
какое слово во фразе "база БЕЗ ДАННЫХ " тебе непонятно? (с) DS
...
Рейтинг: 0 / 0
04.08.2013, 11:40:53
| Ответить | Цитировать | Написать  
Сравнение производительности 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
04.08.2013, 11:47:43
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38354219
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrТаблоид.fdb весит под гигкакое слово во фразе "база БЕЗ ДАННЫХ " тебе непонятно? (с) DSпфф... не проснулся я еще: вчерась почти 600 км отмотал по дорогам "нечерноземья" :-/
сейчас проверю.
...
Рейтинг: 0 / 0
04.08.2013, 11:49:26
| Ответить | Цитировать | Написать  
25 сообщений из 161, страница 2 из 7
  2  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=38353844&tid=1564261]:
 0ms
get settings:
 10ms
get forum list:
 17ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 202ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 84ms
get tp. blocked users:
 1ms
others: 196ms
total:  529ms
созд. / загр.: 529ms
x
x
Закрыть


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