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

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

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

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

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

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

Zoran писал(а):6. Прямой селест из таблицы 3150 записей на 2.1 выполнялся 7 сек, на 2.5 4,5 сек. (т.е. быстрее)
Тут нет ошибки ? 3150 записей за 7 секунд ?

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

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

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

Выполнили тот же запрос на маленькой БД (173МБ)
2.1 . | . 2.5
Выполнение запроса
Prepare time = 297ms . | . Prepare time = 328ms
Execute time = 1s 109ms . | . Execute time = 1s 906ms
Avg fetch time = 369,67 ms . | . Avg fetch time = 635,33 ms
Current memory = 1 948 644 . | . Current memory = 40 189 892
Max memory = 3 796 688 . | . Max memory = 43 619 368
Memory buffers = 75 . | . Memory buffers = 2 048
Reads from disk to cache = 0 . | . Reads from disk to cache = 0
Writes from cache to disk = 0 . | . Writes from cache to disk = 0
Fetches from cache = 820 203 . | . Fetches from cache = 962 742

Повторное выполнение Prepare time = 313ms . | . Prepare time = 328ms
Execute time = 1s 78ms . | . Execute time = 1s 890ms
Avg fetch time = 359,33 ms . | . Avg fetch time = 630,00 ms
Current memory = 1 948 632 . | . Current memory = 40 189 892
Max memory = 3 796 688 . | . Max memory = 43 619 368
Memory buffers = 75 . | . Memory buffers = 2 048
Reads from disk to cache = 0 . | . Reads from disk to cache = 0
Writes from cache to disk = 0 . | . Writes from cache to disk = 0
Fetches from cache = 820 203 . | . Fetches from cache = 962 742

Т.е. на маленькой БД 2.5 также работает медленнее на этом запросе. Хотя и не так критично.
Версии 2.1.2 Classic и 2.5 SS. На 2.5 классик переключить сможем только ночью. Но как показал предыдущий тест разница в производительности получается небольшая.

Может какие-то конкретные SQL выполнить посоветуете на разных версиях? Может это поможет разобраться.

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

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

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

hvlad писал(а):
Zoran писал(а):6. Прямой селест из таблицы 3150 записей на 2.1 выполнялся 7 сек, на 2.5 4,5 сек. (т.е. быстрее)
Тут нет ошибки ? 3150 записей за 7 секунд ?
Перевыполнил. На данный момент показало одинаковый результат.
2.5.

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

Plan
PLAN (b_AgrCalendar NATURAL)

------ Performance info ------
Prepare time = 313ms
Execute time = 3s 94ms
Avg fetch time = 0,99 ms
Current memory = 55 282 044
Max memory = 67 967 756
Memory buffers = 2 048
Reads from disk to cache = 47
Writes from cache to disk = 26
Fetches from cache = 18 996
2.1.

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

Plan
PLAN (b_AgrCalendar NATURAL)

------ Performance info ------
Prepare time = 312ms
Execute time = 3s 94ms
Avg fetch time = 1,01 ms
Current memory = 1 911 816
Max memory = 2 176 832
Memory buffers = 75
Reads from disk to cache = 23
Writes from cache to disk = 0
Fetches from cache = 6 178
Результат - 3065 записей. Но на тот момент АИ 2.1 выдавал 7,1с. Я 2 раза выполнял.
Последний раз редактировалось Zoran 14 апр 2011, 14:26, всего редактировалось 1 раз.

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

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

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

Ещё раз - несчастные 3150 записи тянутся аж целых 3 секунды ???

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

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

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

Да. Именно такие показатели. Но я думаю это можно списать на канал. Сейчас попробую тоже самок выполнить с сервака который стоит там рядом.

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

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

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

Zoran писал(а):Да. Именно такие показатели. Но я думаю это можно списать на канал. Сейчас попробую тоже самок выполнить с сервака который стоит там рядом.
Или select count(*) делать

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

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

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

На соседнем серваке
2.1

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

Prepare time = 0ms
Execute time = 0ms
Avg fetch time = 0,00 ms
Current memory = 1 924 016
Max memory = 2 188 980
Memory buffers = 75
Reads from disk to cache = 1
Writes from cache to disk = 0
Fetches from cache = 265
2.5

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

------ Performance info ------
Prepare time = 47ms
Execute time = 31ms
Avg fetch time = 1,29 ms
Current memory = 55 313 676
Max memory = 67 967 756
Memory buffers = 2 048
Reads from disk to cache = 63
Writes from cache to disk = 0
Fetches from cache = 355 852

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

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

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

Выполнил Select count(*)

2.5

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

Prepare time = 344ms
Execute time = 47ms
Avg fetch time = 47,00 ms
Current memory = 55 325 140
Max memory = 67 967 756
Memory buffers = 2 048
Reads from disk to cache = 37
Writes from cache to disk = 2
Fetches from cache = 6 350
2.1

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

Prepare time = 329ms
Execute time = 31ms
Avg fetch time = 31,00 ms
Current memory = 1 813 216
Max memory = 2 176 832
Memory buffers = 75
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 6 179

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

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

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

Zoran писал(а):На соседнем серваке
Опять CS vs SS

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

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

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

Zoran писал(а):Т.е. на маленькой БД 2.5 также работает медленнее на этом запросе. Хотя и не так критично.
На Windows это воспроизводится на малой БД ?

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

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

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

hvlad писал(а):
Zoran писал(а):На соседнем серваке
Опять CS vs SS
Да, я же написал:
Версии 2.1.2 Classic и 2.5 SS. На 2.5 классик переключить сможем только ночью. Но как показал предыдущий тест разница в производительности получается небольшая.
Мы не можем переставить версию сейчас. Только вечером. Но я уже писал, что на 2.5 CS время выполнения тоже, что и на SS.
hvlad писал(а):
Zoran писал(а):Т.е. на маленькой БД 2.5 также работает медленнее на этом запросе. Хотя и не так критично.
На Windows это воспроизводится на малой БД ?
Не проверял. Все базы лежат на удаленном сервере линукс.
Сейчас попробую под виндой тестовый пример собрать.

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

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

Сообщение kdv » 15 апр 2011, 00:00

БД 4697МБ. К сожалению предоставить для анализа конкретно эту не можем.
можем подписать соглашение о конфиденциальности. Если нужно, поменяйте какие-нибудь значения в строковых столбцах.

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

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

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

kdv писал(а):
БД 4697МБ. К сожалению предоставить для анализа конкретно эту не можем.
можем подписать соглашение о конфиденциальности. Если нужно, поменяйте какие-нибудь значения в строковых столбцах.
Мы постараемся подготовить тестовую базу, просто это займет время :(.

На данный момент имеем:
1. После переустановки SS2.5 на Classic2.5 под линукс и переустановки паралельно FB 2.1 Classic имеем одинаково медленное выполнение запросов 19-20 сек. (на SS было 22-26). Разбираемся почему :(

2. При восстановлении бакапа под 2.1 получаем ошибку

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

D:\DataBase>"C:\Program Files\Firebird\Firebird_2_5\bin\gbak.exe" -r -t -l "D:\D
ataBase\MyBase_25.bak" "D:\DataBase\MyBase_21.fdb" -user SYSDBA -password masterke
y
gbak: ERROR:action cancelled by trigger (3) to preserve data integrity
gbak: ERROR:    table/procedure has non-SQL security class defined
gbak:Exiting before completion due to errors
БД восстанавливается без вью, процедур и триггеров.
Разбираемся. Не подскажете в чем проблема?

При попытке восстановления версией gbak от FB2.1 имеем ошибку

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

IBE: Starting restore. Current time: 10:39:52
IBE: Unsuccessful execution caused by system error that does not preclude successful execution of subsequent statements.
     Expected backup version 1..9.  Found 9.
IBE: Restore completed. Current time: 10:39:52. Elapsed time: 00:00:00
Интуитивно можно догадаться, что старая версия не может восстановить бакап новой, но почему ошибка такая: " Expected backup version 1..9. Found 9."

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

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

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

После рекомпиляции процедур и вью нужный SQL стал выполняться. Один из индексов также пришлось включить заново. (После восстановления из бакапа он оказался отключенным)

Теперь на Windows машине имеем 2.5SS запущенный как служба и 2.1SS запущенный как приложение.
Статистика:

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

2.1  .     |     .  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)))

-- Предыдущий кусок идентичен на 2.1 и 2.5, но следующий присутствует только в 2.5 ----
Adapted 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 (INTEG_320)), NP C INDEX (PK_CLIENT)), NP CURR INDEX (INTEG_324))
PLAN JOIN (JOIN (JOIN (JOIN (NP AC INDEX (b_AgrCalendar_IDX1), NP S INDEX (IPK_b_AgrSpecific)), NP A INDEX (INTEG_320)), NP C INDEX (PK_CLIENT)), NP CURR INDEX (INTEG_324))), AC INDEX (FK_l_AccountControl1), AG INDEX (PK_l_AccountGroup)))
------------------------------------------------------------------------------------------------------------------------

------ Performance info ------
Prepare time = 0ms  .     |     .  Prepare time = 0ms
Execute time = 13s 781ms  .     |     .  Execute time = 16s 500ms
Avg fetch time = 15,09 ms  .     |     .  Avg fetch time = 18,07 ms
Current memory = 34 869 240  .     |     .  Current memory = 34 506 932
Max memory = 43 516 332  .     |     .  Max memory = 43 157 212
Memory buffers = 2 048  .     |     .  Memory buffers = 2 048
Reads from disk to cache = 0  .     |     .  Reads from disk to cache = 123
Writes from cache to disk = 0  .     |     .  Writes from cache to disk = 0
Fetches from cache = 15 126 545  .     |     .  Fetches from cache = 15 126 535
По итогу на Windows машине мы имеем отставание FB2.5 на 3 сек. Это где-то 15% отставания :(.

Имеет смысл на такой базе тестовый пример собрать для Вас?
Под линукс пока имеем одинаковый результат на тех же самых вчерашних базах. (т.е. базы исходные не меняли, но после установки 2.5 классик 2.1 также стал работать по другому. )

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

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

Сообщение dimitr » 15 апр 2011, 21:15

а конфиги у 2.1 и 2.5 одинаковые?

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

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

Сообщение kdv » 16 апр 2011, 01:15

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

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

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

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

dimitr писал(а):а конфиги у 2.1 и 2.5 одинаковые?
Конфиги одинаковые. Была сделана установка с параметрами по умолчанию. Все параметры внутри конфигов закомментированы.
kdv писал(а):перестаньте приводить "адаптированный план". у вас там какие-то пк без явно заданного имени constraint, поэтому адаптированный план вам не поможет, он вообще нужен в редких случаях, и выводится ibexpert-ом, а не firebird-ом.
Я стараюсь приводить максимально имеющуюся у меня информацию. Я не знаю какая именно может вам понадобиться, а какую вы хотели бы получить - вы не говорите.

На данный момент актуальны вопросы:
1. Почему GBAK один и тот же бакап в 2.5 поднимает нормально, а в 2.1 с ошибкой. Ошибку я писал выше.
2. У кого нибудь была ситуация, что FB в 2.5 выполнял запросы значительно медленнее, чем в 2.1. У нас данная ситуация и под линукс и под windows.

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

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

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

Zoran писал(а):При попытке восстановления версией gbak от FB2.1 имеем ошибку

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

IBE: Starting restore. Current time: 10:39:52
IBE: Unsuccessful execution caused by system error that does not preclude successful execution of subsequent statements.
     Expected backup version 1..9.  Found 9.
IBE: Restore completed. Current time: 10:39:52. Elapsed time: 00:00:00
Интуитивно можно догадаться, что старая версия не может восстановить бакап новой, но почему ошибка такая: " Expected backup version 1..9. Found 9."
Потому что gbak от 2.1 работает с firebird.msg от 2.5. Скорее всего ты gbak скопировал в каталог 2.5 или же путь к 2.5 прописан в реестре.

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

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

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

hvlad писал(а):Потому что gbak от 2.1 работает с firebird.msg от 2.5. Скорее всего ты gbak скопировал в каталог 2.5 или же путь к 2.5 прописан в реестре.
Понятно. Спасибо. Но всетаки больше интересовала вторая ошибка:

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

D:\DataBase>"C:\Program Files\Firebird\Firebird_2_5\bin\gbak.exe" -r -t -l "D:\D
ataBase\MyBase_25.bak" "D:\DataBase\MyBase_21.fdb" -user SYSDBA -password masterke
y
gbak: ERROR:action cancelled by trigger (3) to preserve data integrity
gbak: ERROR:    table/procedure has non-SQL security class defined
gbak:Exiting before completion due to errors
По итогу к восстановленной с ошибкой базе можно подключиться и приходится вручную перекомпилировать все процедуры и вью, а также включать заново индексы. Можно эту ошибку как-нибудь побороть?

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

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

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

Zoran писал(а):Но всетаки больше интересовала вторая ошибка:

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

D:\DataBase>"C:\Program Files\Firebird\Firebird_2_5\bin\gbak.exe" -r -t -l "D:\D
ataBase\MyBase_25.bak" "D:\DataBase\MyBase_21.fdb" -user SYSDBA -password masterke
y
gbak: ERROR:action cancelled by trigger (3) to preserve data integrity
gbak: ERROR:    table/procedure has non-SQL security class defined
gbak:Exiting before completion due to errors
По итогу к восстановленной с ошибкой базе можно подключиться и приходится вручную перекомпилировать все процедуры и вью, а также включать заново индексы. Можно эту ошибку как-нибудь побороть?
Это из-за того, что в 2.5 security class'ы именуются не так, как привык 2.1
Народ вроде находил как обойти, поищи на sql.ru

Ответить

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

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