На FB2.5 в 3 раза увеличилось время выполненения запроса

Совместимость InterBase, Firebird, Yaffil между собой и по версиям

Модераторы: kdv, Alexey Kovyazin

Zoran
Сообщения: 37
Зарегистрирован: 27 авг 2008, 12:08

На FB2.5 в 3 раза увеличилось время выполненения запроса

Сообщение Zoran » 13 апр 2011, 17:05

При переходе FB 2.1->2.5 в 3 раза увеличилось время выполнения запроса. Запросы выполняются через IBExpert.

Сервер: 2 процессора AMD Opteron 2,66, 4Гб ОЗУ. ОС - Linux Fedora Core 8.0/
Оба FB стоят на одном сервере сервере с той лишь разницей, что 2.5 стоит в chroot-окружении и там же лежат базы для него.

1. Простое чтение из таблицы (Select * from "MyBase") - время почти не отличается
FB 2.1. | . FB 2.5
Prepare time = 360ms. | . Prepare time = 328ms
Execute time = 1m 8s 469ms. | . Execute time = 1m 9s 328ms
Avg fetch time = 0,45 ms. | . Avg fetch time = 0,45 ms
Current memory = 2 006 996. | . Current memory = 61 460 728
Max memory = 8 747 984. | . Max memory = 72 923 536
Memory buffers = 75. | . Memory buffers = 2 048
Reads from disk to cache = 3 238. | . Reads from disk to cache = 42 493
Writes from cache to disk = 0. | . Writes from cache to disk = 474
Fetches from cache = 343 527. | . Fetches from cache = 10 591 924

2. Сложный запрос (ниже пример)

Код: Выделить всё

       select NP.ID, 'Клиент: '||NP."Alias"||'     Значение: '||NP."Name"
  from
    "B_GetAP" NP   --Используется View
    left join "l_AC" AC on (((lastdaymonth(NP."DateStart")) = AC."StopDate") AND (NP."DateStart" = AC."StartDate") AND (NP."ID" = AC."AccountNo"))
    left join "l_AG" AG on ((NP."GroupNo" = AG."ID"))
  
  where
  (abs(z(AC."ControlSum")) < abs(z((Case AG."AccountType"
  when 'A' then  (Select Sum(C."Summ") from "b_AgrC" C
  left join "b_AgrS" S on (C."AgrSID" = S."ID")  where (C."Date" between NP."DateStart" and (lastdaymonth(NP."DateStart")))  and 
  (S."KB" = NP."ID") and "Status" = 656) 
  else
   (Select -Sum(C."Summ") from "b_AgrC" C
  left join "b_AgrS" S on (C."AgrSID" = S."ID")  where (C."Date" between NP."DateStart" and (lastdaymonth(NP."DateStart")))  and 
  (S."DB" = NP."ID") and "Status" = 656) end
  ))))


FB 2.1. | . FB 2.5
Prepare time = 359ms. | . Prepare time = 515ms
Execute time = 8s 391ms. | . Execute time = 52s 719ms
Current memory = 1 970 780. | . Current memory = 60 540 564
Max memory = 8 747 872. | . Max memory = 72 923 536
Memory buffers = 75. | . Memory buffers = 2 048
Reads from disk to cache = 395. | . Reads from disk to cache = 28 140
Writes from cache to disk = 0 . | . Writes from cache to disk = 157
Fetches from cache = 7 081 331. | . Fetches from cache = 0

Мы сейчас пытаемся разобраться почему так происходит и на каких запросах происходит замедление.
Подскажите, почему такое происходит. Предполагалось, что этот FB будет пусть незначительно, но быстрее. Может ли это быть из-за особенностей установки FB.

Если нужна какая-то дополнительная информация - пишите вопросы.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48
Контактная информация:

Re: На FB2.5 в 3 раза увеличилось время выполненения запроса

Сообщение hvlad » 13 апр 2011, 17:41

Zoran писал(а):При переходе FB 2.1->2.5 в 3 раза увеличилось время выполнения запроса. Запросы выполняются через IBExpert.

Сервер: 2 процессора AMD Opteron 2,66, 4Гб ОЗУ. ОС - Linux Fedora Core 8.0/
Оба FB стоят на одном сервере сервере с той лишь разницей, что 2.5 стоит в chroot-окружении и там же лежат базы для него.

1. Простое чтение из таблицы (Select * from "MyBase") - время почти не отличается
FB 2.1. | . FB 2.5

Memory buffers = 75. | . Memory buffers = 2 048
Reads from disk to cache = 3 238. | . Reads from disk to cache = 42 493
Writes from cache to disk = 0. | . Writes from cache to disk = 474
Fetches from cache = 343 527. | . Fetches from cache = 10 591 924
а) судя по размеру кеша - сравниваем классик 2.1 с супером 2.5
б) похоже 2.5 собирает большую кучу мусора, т.к. при бОльшем кеше делает в 14 раз больше чтений и что-то пишет на диск.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48
Контактная информация:

Re: На FB2.5 в 3 раза увеличилось время выполненения запроса

Сообщение hvlad » 13 апр 2011, 17:42

Zoran писал(а):ОС - Linux Fedora Core 8.0
Сколько ей лет ? 2.5 требует относительно свежих версий ядра и glibc

Zoran
Сообщения: 37
Зарегистрирован: 27 авг 2008, 12:08

Re: На FB2.5 в 3 раза увеличилось время выполненения запроса

Сообщение Zoran » 13 апр 2011, 17:46

hvlad писал(а):...
б) похоже 2.5 собирает большую кучу мусора, т.к. при бОльшем кеше делает в 14 раз больше чтений и что-то пишет на диск.
И как это лечить или что нам предпринять? Переход был осуществлен 3 дня назад, т.е. БД совсем новенькая. Мусора там накопиться не могло и неужели дальше будет хуже?
Сколько ей лет ? 2.5 требует относительно свежих версий ядра и glibc
glibc-2.7-2
2.6.25.11-60.fc8

БД более 6 Гб.

Zoran
Сообщения: 37
Зарегистрирован: 27 авг 2008, 12:08

Re: На FB2.5 в 3 раза увеличилось время выполненения запроса

Сообщение Zoran » 13 апр 2011, 17:56

Еще дополнительная информация: Выполнение части запроса - в 2.5 он выполнился быстрее.

Код: Выделить всё

     select NP.ID, 'Клиент: '||NP."Alias"||'     Значение: '||NP."Name"
  from
    "B_GetAP" NP   --Используется View
    left join "l_AC" AC on (((lastdaymonth(NP."DateStart")) = AC."StopDate") AND (NP."DateStart" = AC."StartDate") AND (NP."ID" = AC."AccountNo"))
    left join "l_AG" AG on ((NP."GroupNo" = AG."ID"))
FB 2.1. | . FB 2.5
Prepare time = 656ms. | .Prepare time = 312ms
Execute time = 1s 172ms. | .Execute time = 594ms
Avg fetch time = 1,20 ms. | .Avg fetch time = 0,58 ms
Current memory = 2 026 384. | .Current memory = 58 455 524
Max memory = 8 803 252. | .Max memory = 72 923 536
Memory buffers = 75. | .Memory buffers = 2 048
Reads from disk to cache = 164. | .Reads from disk to cache = 94
Writes from cache to disk = 1. | .Writes from cache to disk = 2
Fetches from cache = 133 295. | .Fetches from cache = 0


Сейчас сравню запросы с использованием функций и с агрегацией.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48
Контактная информация:

Re: На FB2.5 в 3 раза увеличилось время выполненения запроса

Сообщение hvlad » 13 апр 2011, 18:00

Zoran писал(а):
hvlad писал(а):...
б) похоже 2.5 собирает большую кучу мусора, т.к. при бОльшем кеше делает в 14 раз больше чтений и что-то пишет на диск.
И как это лечить или что нам предпринять? Переход был осуществлен 3 дня назад, т.е. БД совсем новенькая. Мусора там накопиться не могло и неужели дальше будет хуже?
Для начала не нужно сравнивать кислое с зелёным.
Наличие мусора можно проверить gstat'ом.
Zoran писал(а):
Сколько ей лет ? 2.5 требует относительно свежих версий ядра и glibc
glibc-2.7-2
2.6.25.11-60.fc8
2.7 - это минимальная версия, которая вроде как работоспособна. Но всё равно она очень стара.

PS Ну и кто надоумил ставить боевой сервер на экспериментальную ОСь ?

kdv
Forum Admin
Сообщения: 6575
Зарегистрирован: 25 окт 2004, 18:07
Контактная информация:

Re: На FB2.5 в 3 раза увеличилось время выполненения запроса

Сообщение kdv » 13 апр 2011, 20:27

первым делом, если один и тот же запрос по разному работает с одной и той же базой, нужно сравнить ПЛАНЫ запроса на 2.1 и 2.5.
Если отличаются - выяснить, почему.

Далее, вы упорно сравниваете классик с суперсервером. Это разные архитектуры, и кроме того, у них разные стратегии сборки мусора. У Классика всегда GCPolicy = cooperative независимо от настройки в firebird.conf, у SuperServer эту опцию можно менять с разными результатами. По поводу мусора Влад уже ответил про gstat (с опциями -a -r), я еще добавлю - IBAnalyst (скачать можно тут же на форуме, вверху).

хотите сравнить - сравнивайте классик с классиком, или хотя бы классик с суперклассиком.

по второму запросу:
Reads from disk to cache = 395. | . Reads from disk to cache = 28 140
либо это разные данные (разные базы), либо на 2.5 план отличается от 2.1. Где планы?

Zoran
Сообщения: 37
Зарегистрирован: 27 авг 2008, 12:08

Re: На FB2.5 в 3 раза увеличилось время выполненения запроса

Сообщение Zoran » 14 апр 2011, 10:33

первым делом, если один и тот же запрос по разному работает с одной и той же базой, нужно сравнить ПЛАНЫ запроса на 2.1 и 2.5.
Если отличаются - выяснить, почему.
Планы абсолютно идентичны:
  • FB 2.1
    Plan
    PLAN JOIN (C INDEX (b_AgrCalendar_IDX1), S INDEX (IPK_b_AgrSpecific))
    PLAN JOIN (C INDEX (b_AgrCalendar_IDX1), S INDEX (IPK_b_AgrSpecific))
    PLAN JOIN (JOIN (SORT (JOIN (JOIN (JOIN (JOIN (NP AC INDEX (b_AgrCalendar_IDX1), NP S INDEX (IPK_b_AgrSpecific)), NP A INDEX (RDB$PRIMARY1)), NP C INDEX (PK_CLIENT)), NP CURR INDEX (RDB$PRIMARY5))
    PLAN JOIN (JOIN (JOIN (JOIN (NP AC INDEX (b_AgrCalendar_IDX1), NP S INDEX (IPK_b_AgrSpecific)), NP A INDEX (RDB$PRIMARY1)), NP C INDEX (PK_CLIENT)), NP CURR INDEX (RDB$PRIMARY5))), AC INDEX (FK_l_AccountControl1), AG INDEX (PK_l_AccountGroup)))

    ------ Performance info ------
    Prepare time = 391ms
    Execute time = 8s 984ms
    Current memory = 1 992 820

    FB 2.5
    Plan
    PLAN JOIN (C INDEX (b_AgrCalendar_IDX1), S INDEX (IPK_b_AgrSpecific))
    PLAN JOIN (C INDEX (b_AgrCalendar_IDX1), S INDEX (IPK_b_AgrSpecific))
    PLAN JOIN (JOIN (SORT (JOIN (JOIN (JOIN (JOIN (NP AC INDEX (b_AgrCalendar_IDX1), NP S INDEX (IPK_b_AgrSpecific)), NP A INDEX (RDB$PRIMARY1)), NP C INDEX (PK_CLIENT)), NP CURR INDEX (RDB$PRIMARY5))
    PLAN JOIN (JOIN (JOIN (JOIN (NP AC INDEX (b_AgrCalendar_IDX1), NP S INDEX (IPK_b_AgrSpecific)), NP A INDEX (RDB$PRIMARY1)), NP C INDEX (PK_CLIENT)), NP CURR INDEX (RDB$PRIMARY5))), AC INDEX (FK_l_AccountControl1), AG INDEX (PK_l_AccountGroup)))

    ------ Performance info ------
    Prepare time = 1s 250ms
    Execute time = 23s 563ms
    Current memory = 41 347 080
Статистика IBAnalist
FB 2.1
Изображение

FB 2.5
Изображение
Далее, вы упорно сравниваете классик с суперсервером. Это разные архитектуры, и кроме того, у них разные стратегии сборки мусора. У Классика всегда GCPolicy = cooperative независимо от настройки в firebird.conf, у SuperServer эту опцию можно менять с разными результатами. По поводу мусора Влад уже ответил про gstat (с опциями -a -r), я еще добавлю - IBAnalyst (скачать можно тут же на форуме, вверху).

хотите сравнить - сравнивайте классик с классиком, или хотя бы классик с суперклассиком.
Почему я не могу их сравнивать. Я выбираю для себя наиболее производительную систему. Именно исходя из этого я и сравниваю. По заявлениям новый FB должен быть быстрее, а по факту оказывается значительно медленнее.

Если вы мне скажете, что это нормально и так и должно быть "...из-за разной стратегии сборки мусора..." или еще из-за чего, я просто верну базы на 2.1. Но если это неправильная настройка сервера, или несовместимость с чем нибудь, тогда будем разбираться.

Какие еще данные Вам необходимо получить для продолжения обсуждения?
Заранее всем Спасибо.

kdv
Forum Admin
Сообщения: 6575
Зарегистрирован: 25 окт 2004, 18:07
Контактная информация:

Re: На FB2.5 в 3 раза увеличилось время выполненения запроса

Сообщение kdv » 14 апр 2011, 10:58

я просто верну базы на 2.1.
а попробовать разные значения GCPolicy? Попробовать классик или суперклассик 2.5? Вы же экспериментируете, так в чем проблема проверить?

И базы у вас все-таки неодинаковые.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48
Контактная информация:

Re: На FB2.5 в 3 раза увеличилось время выполненения запроса

Сообщение hvlad » 14 апр 2011, 11:03

Налицо полное непонимание заданных вопросов и попытка сравнить яблоки с апельсинами.

Зачем спрятал статистику в последних запросах (которые с планами) ?
Когда поймёшь отличие CS от SS ?
Кто ищет версии записей в статистике header page ?

Короче - учиться, учиться и учиться...

Zoran
Сообщения: 37
Зарегистрирован: 27 авг 2008, 12:08

Re: На FB2.5 в 3 раза увеличилось время выполненения запроса

Сообщение Zoran » 14 апр 2011, 11:55

а попробовать разные значения GCPolicy? Попробовать классик или суперклассик 2.5? Вы же экспериментируете, так в чем проблема проверить?
Сейчас будем пробовать классик и суперклассик.
И базы у вас все-таки неодинаковые.
Сделали бакап в выходные с 2.1 и развернули на 2.5. На 2.5. с тех пор работают. Да, базы не одинаковые, но отличия небольшие. Если Вы считаете, что проблема в этом, то мы сделаем одинаковые и будем проверять на них. Но думаю проблема не в этом.
Налицо полное непонимание заданных вопросов и попытка сравнить яблоки с апельсинами.
Отличия я прочитал, но, возможно, действительно не понимаю.
Встречный вопрос: Если у нас " Сервер: 2 процессора AMD Opteron 2,66, 4Гб ОЗУ. ОС - Linux Fedora Core 8.0, glibc-2.7-2 2.6.25.11-60.fc8" что нам нужно поставить? Сервер используется только для FB.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48
Контактная информация:

Re: На FB2.5 в 3 раза увеличилось время выполненения запроса

Сообщение hvlad » 14 апр 2011, 12:47

Zoran писал(а):Встречный вопрос: Если у нас " Сервер: 2 процессора AMD Opteron 2,66, 4Гб ОЗУ. ОС - Linux Fedora Core 8.0, glibc-2.7-2 2.6.25.11-60.fc8" что нам нужно поставить? Сервер используется только для FB.
Есть понимание, что такое федора и для кого она предназначена ?
Версии ядра и glibc удовлетворительные, я уже писал.
Выберите себе любой нормальный стабильный линукс не самый древний и поддерживаемый как его производителем, так и производителями соотв. железа (кроме процессора там есть ещё немножко железок...)

Zoran
Сообщения: 37
Зарегистрирован: 27 авг 2008, 12:08

Re: На FB2.5 в 3 раза увеличилось время выполненения запроса

Сообщение Zoran » 14 апр 2011, 12:47

Переставили.
Выполнение запроса на Суперклассик

Код: Выделить всё

Plan
PLAN JOIN (C INDEX (b_AgrCalendar_IDX1), S INDEX (IPK_b_AgrSpecific))
PLAN JOIN (C INDEX (b_AgrCalendar_IDX1), S INDEX (IPK_b_AgrSpecific))
PLAN JOIN (JOIN (SORT (JOIN (JOIN (JOIN (JOIN (NP AC INDEX (b_AgrCalendar_IDX1), NP S INDEX (IPK_b_AgrSpecific)), NP A INDEX (RDB$PRIMARY1)), NP C INDEX (PK_CLIENT)), NP CURR INDEX (RDB$PRIMARY5))
PLAN JOIN (JOIN (JOIN (JOIN (NP AC INDEX (b_AgrCalendar_IDX1), NP S INDEX (IPK_b_AgrSpecific)), NP A INDEX (RDB$PRIMARY1)), NP C INDEX (PK_CLIENT)), NP CURR INDEX (RDB$PRIMARY5))), AC INDEX (FK_l_AccountControl1), AG INDEX (PK_l_AccountGroup)))


------ Performance info ------
Prepare time = 296ms
Execute time = 21s 375ms
Current memory = 2 010 524
Max memory = 8 788 664
Memory buffers = 75
Reads from disk to cache = 379
Writes from cache to disk = 0
Fetches from cache = 7 081 323
Выполнение запроса на классик

Код: Выделить всё

Plan
PLAN JOIN (C INDEX (b_AgrCalendar_IDX1), S INDEX (IPK_b_AgrSpecific))
PLAN JOIN (C INDEX (b_AgrCalendar_IDX1), S INDEX (IPK_b_AgrSpecific))
PLAN JOIN (JOIN (SORT (JOIN (JOIN (JOIN (JOIN (NP AC INDEX (b_AgrCalendar_IDX1), NP S INDEX (IPK_b_AgrSpecific)), NP A INDEX (RDB$PRIMARY1)), NP C INDEX (PK_CLIENT)), NP CURR INDEX (RDB$PRIMARY5))
PLAN JOIN (JOIN (JOIN (JOIN (NP AC INDEX (b_AgrCalendar_IDX1), NP S INDEX (IPK_b_AgrSpecific)), NP A INDEX (RDB$PRIMARY1)), NP C INDEX (PK_CLIENT)), NP CURR INDEX (RDB$PRIMARY5))), AC INDEX (FK_l_AccountControl1), AG INDEX (PK_l_AccountGroup)))

------ Performance info ------
Prepare time = 297ms
Execute time = 23s 469ms
Current memory = 1 906 988
Max memory = 8 683 780
Memory buffers = 75
Reads from disk to cache = 395
Writes from cache to disk = 0
Fetches from cache = 7 081 331
Напомню, выполнение данного запроса на FB 2.1 Classic занимает 8,21 сек.
В данном случае запрос выполнялся на той же базе, на которой проверялся 2.1. ODS не переделывали и он остался 11.1.
План запроса всегда одинаковый.

Какие еще параметры посоветуете поковырять у FB?

Zoran
Сообщения: 37
Зарегистрирован: 27 авг 2008, 12:08

Re: На FB2.5 в 3 раза увеличилось время выполненения запроса

Сообщение Zoran » 14 апр 2011, 12:52

hvlad писал(а):
Zoran писал(а):Встречный вопрос: Если у нас " Сервер: 2 процессора AMD Opteron 2,66, 4Гб ОЗУ. ОС - Linux Fedora Core 8.0, glibc-2.7-2 2.6.25.11-60.fc8" что нам нужно поставить? Сервер используется только для FB.
Есть понимание, что такое федора и для кого она предназначена ?
Версии ядра и glibc удовлетворительные, я уже писал.
Выберите себе любой нормальный стабильный линукс не самый древний и поддерживаемый как его производителем, так и производителями соотв. железа (кроме процессора там есть ещё немножко железок...)
К сожалению Федору на данном сервере переставить никак нельзя.
Вы предполагаете, что проблема в оси? Мы можем развернуть другую, но, к сожалению, уже на другом сервере. Только скажется ли это?

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48
Контактная информация:

Re: На FB2.5 в 3 раза увеличилось время выполненения запроса

Сообщение hvlad » 14 апр 2011, 12:53

Zoran писал(а):Напомню, выполнение данного запроса на FB 2.1 Classic занимает 8,21 сек.
В данном случае запрос выполнялся на той же базе, на которой проверялся 2.1. ODS не переделывали и он остался 11.1.
План запроса всегда одинаковый.

Какие еще параметры посоветуете поковырять у FB?
Т.е. БД та же самая теперь ?
Какая точная версия 2.1 была ?
Что, если выполнить запрос несколько раз подряд ?
Делался ли полный фетч результатов ?

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48
Контактная информация:

Re: На FB2.5 в 3 раза увеличилось время выполненения запроса

Сообщение hvlad » 14 апр 2011, 13:17

Zoran писал(а):Вы предполагаете, что проблема в оси?
В данном случае - нет. Но предупреждение я сделал.

Zoran
Сообщения: 37
Зарегистрирован: 27 авг 2008, 12:08

Re: На FB2.5 в 3 раза увеличилось время выполненения запроса

Сообщение Zoran » 14 апр 2011, 13:36

hvlad писал(а):Т.е. БД та же самая теперь ?
Да. БД таже самая. Именно тот же самый файл, лежащий на том же месте.
hvlad писал(а):Какая точная версия 2.1 была ?
Инсталляционный файл - FirebirdCS-2.1.2.18118-0.i686
hvlad писал(а):Что, если выполнить запрос несколько раз подряд ?
Если выполнять запрос несколько раз подряд, то статистика почти одинаковая. отличается на несколько сотых долей. Прочие параметры также почти идентичны.
hvlad писал(а):Делался ли полный фетч результатов ?
Да. Делается полный фетч. (галка в IB Fetch All установлена). Кстати результатом запроса является 0 записей. Анализ производительности в IB Expert у 2.1 и 2.5 также почти одинаковый. (Могу привести).

В итоге после серии экспериментов:
1. Весь запрос выполняется в 3 раза медленнее
2. Выборка только из вьюхи с джойном 2 таблиц выполняется в 2 раза быстрее.
3. выборка из вьюхи с джойном 2 таблиц и фильтром по числовому параметру выполняется медленнее почти в 2 раза.
4. Выполнение того же запроса без использования LastDay(грешил на rfunc) дало ускорение на 3 секунды. На 2.1 не выполнялось, но видно что пользы не дало.
5. Прямой селект из таблицы 400000 записей выполнялся одинково 1мин 9 сек.
6. Прямой селест из таблицы 3150 записей на 2.1 выполнялся 7 сек, на 2.5 4,5 сек. (т.е. быстрее)

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48
Контактная информация:

Re: На FB2.5 в 3 раза увеличилось время выполненения запроса

Сообщение hvlad » 14 апр 2011, 13:48

БД большая ? Есть возможность предоставить её для анализа ?

Zoran
Сообщения: 37
Зарегистрирован: 27 авг 2008, 12:08

Re: На FB2.5 в 3 раза увеличилось время выполненения запроса

Сообщение Zoran » 14 апр 2011, 14:00

БД 4697МБ. К сожалению предоставить для анализа конкретно эту не можем.

Сейчас попробуем проверить теже запросы на меньших БД. Проверим сохраняется ли соотношение времени выполнения.

Также есть предложение развернуть стенд под виндой на другой машине. И сравнить соотношение производительности разных версий FB. Это имеет смысл? Или ковырять только линукс?

hvlad - а у вас нет тестовой БД, чтоб мы могли проверить выполнение различных запросов. Мы в принципе можем ее сами сгенерировать. Непонятно на что думать. На какие-то конкретные операции или на конфигурирование сервера. Что посоветуете?

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48
Контактная информация:

Re: На FB2.5 в 3 раза увеличилось время выполненения запроса

Сообщение hvlad » 14 апр 2011, 14:13

Zoran писал(а):Также есть предложение развернуть стенд под виндой на другой машине. И сравнить соотношение производительности разных версий FB. Это имеет смысл? Или ковырять только линукс?
Имеет.
По крайней мере попробовать можно.
Вообще-то такие стенды делают до перехода на новую версию :)
Zoran писал(а):hvlad - а у вас нет тестовой БД, чтоб мы могли проверить выполнение различных запросов.
У меня их десятки, но я не понял их связи с вами :)
Zoran писал(а):Мы в принципе можем ее сами сгенерировать.
Если есть способ сгенерировать БД, на которой воспроизводится такая разница между 2.1 и 2.5 - то давайте его сюда.
Zoran писал(а):Непонятно на что думать. На какие-то конкретные операции или на конфигурирование сервера. Что посоветуете?
Для начала хотелось бы воспроизвести проблему.

Ответить

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость