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


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