Страница 1 из 3

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

Добавлено: 13 апр 2011, 17:05
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
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.

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

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

Добавлено: 13 апр 2011, 17:41
hvlad
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 раз больше чтений и что-то пишет на диск.

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

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

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

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

БД более 6 Гб.

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

Добавлено: 13 апр 2011, 17:56
Zoran
Еще дополнительная информация: Выполнение части запроса - в 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


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

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

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

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

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

Добавлено: 13 апр 2011, 20:27
kdv
первым делом, если один и тот же запрос по разному работает с одной и той же базой, нужно сравнить ПЛАНЫ запроса на 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. Где планы?

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

Добавлено: 14 апр 2011, 10:33
Zoran
первым делом, если один и тот же запрос по разному работает с одной и той же базой, нужно сравнить ПЛАНЫ запроса на 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. Но если это неправильная настройка сервера, или несовместимость с чем нибудь, тогда будем разбираться.

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

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

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

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

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

Добавлено: 14 апр 2011, 11:03
hvlad
Налицо полное непонимание заданных вопросов и попытка сравнить яблоки с апельсинами.

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

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

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

Добавлено: 14 апр 2011, 11:55
Zoran
а попробовать разные значения 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.

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

Добавлено: 14 апр 2011, 12:47
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 удовлетворительные, я уже писал.
Выберите себе любой нормальный стабильный линукс не самый древний и поддерживаемый как его производителем, так и производителями соотв. железа (кроме процессора там есть ещё немножко железок...)

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

Добавлено: 14 апр 2011, 12:47
Zoran
Переставили.
Выполнение запроса на Суперклассик

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

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?

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

Добавлено: 14 апр 2011, 12:52
Zoran
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 удовлетворительные, я уже писал.
Выберите себе любой нормальный стабильный линукс не самый древний и поддерживаемый как его производителем, так и производителями соотв. железа (кроме процессора там есть ещё немножко железок...)
К сожалению Федору на данном сервере переставить никак нельзя.
Вы предполагаете, что проблема в оси? Мы можем развернуть другую, но, к сожалению, уже на другом сервере. Только скажется ли это?

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

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

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

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

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

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

Добавлено: 14 апр 2011, 13:36
Zoran
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 сек. (т.е. быстрее)

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

Добавлено: 14 апр 2011, 13:48
hvlad
БД большая ? Есть возможность предоставить её для анализа ?

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

Добавлено: 14 апр 2011, 14:00
Zoran
БД 4697МБ. К сожалению предоставить для анализа конкретно эту не можем.

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

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

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

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

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