ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
25 сообщений из 161, страница 4 из 7
  4  все
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355863
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоид1) сообщение вида:
Код: plaintext
1.
2.
3.
Statement failed, SQLSTATE = HY008
operation was cancelled
...
- появляется в сеансе_1 только после завершения отката инсертов.
Хотя в трейсе сообщение о завершении оператора delete from mon$statements появляется практически сразу же за его стартом:И это совершенно правильно

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

А откат массового DML может произойти ввиду срубания приложения на любой усеровской тачке. В любой момент.
И что получается, ДБА (или задание крона :)) должен будет ждать 2-3-5-... минут результатов мониторинга, пока ФБ не выполнит откаты обрубленного bulk DML ?
...
Рейтинг: 0 / 0
05.08.2013, 22:37:03
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355871
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
05.08.2013, 22:43:33
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355872
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидпока ФБ не выполнит откаты обрубленного bulk DML ?
откаты обрубленного будут ускорены, ты же сам об этом просил в трекере
...
Рейтинг: 0 / 0
05.08.2013, 22:46:36
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355873
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидИ что получается, ДБА (или задание крона :)) должен будет ждать 2-3-5-... минутнет, пусть лучше БД развалится на части - но зато мгновенно
...
Рейтинг: 0 / 0
05.08.2013, 22:48:11
| Ответить | Цитировать | Написать  
Сравнение производительности 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
05.08.2013, 22:51:58
| Ответить | Цитировать | Написать  
Сравнение производительности 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
05.08.2013, 23:00:50
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355881
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидВах!.. а в чём там дело было ? Такое ускорение выглядит как-то... подозрительно
ничего сверхестественного, глянь в трекере . Оно давно напрашивалось, но руки дошли только сейчас. Правда, эффект несколько больше ожидаемого :-) но твои тесты вечно не от мира сего...

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

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

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

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

это нормально. Оракл тоже усердно все закешировал, но он в consistent gets считает и чтения из временной таблицы тоже.
...
Рейтинг: 0 / 0
05.08.2013, 23:02:30
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355884
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидА с какого это перепугу она "развалится мгновенно на части" ?Вот этот вопрос и надо изучить.
...
Рейтинг: 0 / 0
05.08.2013, 23:11:43
| Ответить | Цитировать | Написать  
Сравнение производительности 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
05.08.2013, 23:15:45
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355896
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Таблоидничего сверхестественного, глянь в трекере .Там написано, что Fix Version/s: 3.0 Alpha 2
Если скачивать снапшот с обычного адреса - эта фича уже будет в нём, или на сайте только Alpha- 1 ?
...
Рейтинг: 0 / 0
05.08.2013, 23:22:41
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38355973
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидне объясняет, почему не только юнион 8 строк, но и соединение 8 таблиц теперь будет выполняться быстрее прежнего на несколько порядков
потому что это соединение юнионов методом nested loop, т.е. юнионы перевыполняются туеву хучу раз

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

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

ТаблоидЕсли скачивать снапшот с обычного адреса - эта фича уже будет в нём, или на сайте только Alpha-1 ?
в снапшоте будет
...
Рейтинг: 0 / 0
06.08.2013, 06:36:18
| Ответить | Цитировать | Написать  
Сравнение производительности 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
06.08.2013, 07:19:01
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38356542
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидстарый 2.5 в два раза быстрее, чем новый 3.0
правильнее будет - новый 2.5 (то бишь 2.5.3) был быстрее как нового 3.0, так и старого 2.5.2. Причина найдена, справедливость восстановлена.
...
Рейтинг: 0 / 0
06.08.2013, 13:40:37
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38356557
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Симонов ДенисПосмотрел исправленную статистику. Очень интересно
небось размер страницы 16К в большой и 4К в маленькой? Я никаких странностей у себя не наблюдаю.
...
Рейтинг: 0 / 0
06.08.2013, 13:49:49
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38356596
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
dimitr,
Может быть. Посмотрю. Я просто думал, что пока кэш не заполнен и статистика должна быть небольшой. Выходит, что память сразу резервируется и независимо заполнен кэш или нет отображается таковой.
...
Рейтинг: 0 / 0
06.08.2013, 14:04:52
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38356598
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Симонов ДенисВыходит, что память сразу резервируется и независимо заполнен кэш или нет отображается таковой.
конечно
...
Рейтинг: 0 / 0
06.08.2013, 14:05:45
| Ответить | Цитировать | Написать  
Сравнение производительности 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
06.08.2013, 14:31:02
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38356658
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,
dimitr уже ответил. Скорее всего так и есть. Размер страниц разный. После работы перепроверю.
...
Рейтинг: 0 / 0
06.08.2013, 14:33:30
| Ответить | Цитировать | Написать  
Сравнение производительности 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
06.08.2013, 15:03:42
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38356866
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидоно уже включено в снапшот или еще нет ?
если внимательно читать мои посты, то очевидно что нет
...
Рейтинг: 0 / 0
06.08.2013, 15:52:40
| Ответить | Цитировать | Написать  
Сравнение производительности 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
06.08.2013, 17:33:08
| Ответить | Цитировать | Написать  
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
    #38357196
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Таблоид,

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

Так и было. Извиняюсь.
...
Рейтинг: 0 / 0
06.08.2013, 20:50:06
| Ответить | Цитировать | Написать  
25 сообщений из 161, страница 4 из 7
  4  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=38355881&tid=1564261]:
 0ms
get settings:
 10ms
get forum list:
 21ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 261ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 84ms
get tp. blocked users:
 2ms
others: 226ms
total:  624ms
созд. / загр.: 624ms
x
x
Закрыть


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