iBase.ru Forum

Форум по InterBase, Firebird и Yaffil
http://ibaseforum.ru/

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

http://ibaseforum.ru/viewtopic.php?f=10&t=5400

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

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

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

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

Добавлено: 14 апр 2011, 14:19
Zoran
Выполнили тот же запрос на маленькой БД (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 выполнить посоветуете на разных версиях? Может это поможет разобраться.

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

Добавлено: 14 апр 2011, 14:23
Zoran
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 раза выполнял.

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

Добавлено: 14 апр 2011, 14:26
hvlad
Ещё раз - несчастные 3150 записи тянутся аж целых 3 секунды ???

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

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

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

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

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

Добавлено: 14 апр 2011, 14:32
Zoran
На соседнем серваке
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

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

Добавлено: 14 апр 2011, 14:36
Zoran
Выполнил 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

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

Добавлено: 14 апр 2011, 14:42
hvlad
Zoran писал(а):На соседнем серваке
Опять CS vs SS

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

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

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

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

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

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

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

Добавлено: 15 апр 2011, 12:25
Zoran
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."

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

Добавлено: 15 апр 2011, 12:57
Zoran
После рекомпиляции процедур и вью нужный 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 также стал работать по другому. )

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

Добавлено: 15 апр 2011, 21:15
dimitr
а конфиги у 2.1 и 2.5 одинаковые?

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

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

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

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

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

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

Добавлено: 18 апр 2011, 12:17
hvlad
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 прописан в реестре.

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

Добавлено: 18 апр 2011, 13:07
Zoran
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
По итогу к восстановленной с ошибкой базе можно подключиться и приходится вручную перекомпилировать все процедуры и вью, а также включать заново индексы. Можно эту ошибку как-нибудь побороть?

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

Добавлено: 18 апр 2011, 13:16
hvlad
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
Часовой пояс: UTC+03:00
Страница 2 из 3
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/