powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
25 сообщений из 161, страница 5 из 7
Сравнение производительности 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
25 сообщений из 161, страница 5 из 7
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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