Тут нет ошибки ? 3150 записей за 7 секунд ?Zoran писал(а):6. Прямой селест из таблицы 3150 записей на 2.1 выполнялся 7 сек, на 2.5 4,5 сек. (т.е. быстрее)
На FB2.5 в 3 раза увеличилось время выполненения запроса
Модераторы: kdv, Alexey Kovyazin
Re: На FB2.5 в 3 раза увеличилось время выполненения запроса
Re: На FB2.5 в 3 раза увеличилось время выполненения запроса
Выполнили тот же запрос на маленькой БД (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 выполнить посоветуете на разных версиях? Может это поможет разобраться.
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
Повторное выполнение
Код: Выделить всё
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 раза увеличилось время выполненения запроса
Перевыполнил. На данный момент показало одинаковый результат.hvlad писал(а):Тут нет ошибки ? 3150 записей за 7 секунд ?Zoran писал(а):6. Прямой селест из таблицы 3150 записей на 2.1 выполнялся 7 сек, на 2.5 4,5 сек. (т.е. быстрее)
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
Код: Выделить всё
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
Последний раз редактировалось Zoran 14 апр 2011, 14:26, всего редактировалось 1 раз.
Re: На FB2.5 в 3 раза увеличилось время выполненения запроса
Ещё раз - несчастные 3150 записи тянутся аж целых 3 секунды ???
Re: На FB2.5 в 3 раза увеличилось время выполненения запроса
Да. Именно такие показатели. Но я думаю это можно списать на канал. Сейчас попробую тоже самок выполнить с сервака который стоит там рядом.
Re: На FB2.5 в 3 раза увеличилось время выполненения запроса
Или select count(*) делатьZoran писал(а):Да. Именно такие показатели. Но я думаю это можно списать на канал. Сейчас попробую тоже самок выполнить с сервака который стоит там рядом.
Re: На FB2.5 в 3 раза увеличилось время выполненения запроса
На соседнем серваке
2.1
2.5
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
Код: Выделить всё
------ 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 раза увеличилось время выполненения запроса
Выполнил Select count(*)
2.5
2.1
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
Код: Выделить всё
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 раза увеличилось время выполненения запроса
Опять CS vs SSZoran писал(а):На соседнем серваке
Re: На FB2.5 в 3 раза увеличилось время выполненения запроса
На Windows это воспроизводится на малой БД ?Zoran писал(а):Т.е. на маленькой БД 2.5 также работает медленнее на этом запросе. Хотя и не так критично.
Re: На FB2.5 в 3 раза увеличилось время выполненения запроса
Да, я же написал:hvlad писал(а):Опять CS vs SSZoran писал(а):На соседнем серваке
Мы не можем переставить версию сейчас. Только вечером. Но я уже писал, что на 2.5 CS время выполнения тоже, что и на SS.Версии 2.1.2 Classic и 2.5 SS. На 2.5 классик переключить сможем только ночью. Но как показал предыдущий тест разница в производительности получается небольшая.
Не проверял. Все базы лежат на удаленном сервере линукс.hvlad писал(а):На Windows это воспроизводится на малой БД ?Zoran писал(а):Т.е. на маленькой БД 2.5 также работает медленнее на этом запросе. Хотя и не так критично.
Сейчас попробую под виндой тестовый пример собрать.
Re: На FB2.5 в 3 раза увеличилось время выполненения запроса
можем подписать соглашение о конфиденциальности. Если нужно, поменяйте какие-нибудь значения в строковых столбцах.БД 4697МБ. К сожалению предоставить для анализа конкретно эту не можем.
Re: На FB2.5 в 3 раза увеличилось время выполненения запроса
Мы постараемся подготовить тестовую базу, просто это займет время .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
Re: На FB2.5 в 3 раза увеличилось время выполненения запроса
После рекомпиляции процедур и вью нужный SQL стал выполняться. Один из индексов также пришлось включить заново. (После восстановления из бакапа он оказался отключенным)
Теперь на Windows машине имеем 2.5SS запущенный как служба и 2.1SS запущенный как приложение.
Статистика:
По итогу на Windows машине мы имеем отставание FB2.5 на 3 сек. Это где-то 15% отставания .
Имеет смысл на такой базе тестовый пример собрать для Вас?
Под линукс пока имеем одинаковый результат на тех же самых вчерашних базах. (т.е. базы исходные не меняли, но после установки 2.5 классик 2.1 также стал работать по другому. )
Теперь на 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
Имеет смысл на такой базе тестовый пример собрать для Вас?
Под линукс пока имеем одинаковый результат на тех же самых вчерашних базах. (т.е. базы исходные не меняли, но после установки 2.5 классик 2.1 также стал работать по другому. )
Re: На FB2.5 в 3 раза увеличилось время выполненения запроса
а конфиги у 2.1 и 2.5 одинаковые?
Re: На FB2.5 в 3 раза увеличилось время выполненения запроса
перестаньте приводить "адаптированный план". у вас там какие-то пк без явно заданного имени constraint, поэтому адаптированный план вам не поможет, он вообще нужен в редких случаях, и выводится ibexpert-ом, а не firebird-ом.
Re: На FB2.5 в 3 раза увеличилось время выполненения запроса
Конфиги одинаковые. Была сделана установка с параметрами по умолчанию. Все параметры внутри конфигов закомментированы.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 раза увеличилось время выполненения запроса
Потому что gbak от 2.1 работает с firebird.msg от 2.5. Скорее всего ты gbak скопировал в каталог 2.5 или же путь к 2.5 прописан в реестре.Zoran писал(а):При попытке восстановления версией gbak от FB2.1 имеем ошибкуИнтуитивно можно догадаться, что старая версия не может восстановить бакап новой, но почему ошибка такая: " Expected backup version 1..9. Found 9."Код: Выделить всё
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
Re: На FB2.5 в 3 раза увеличилось время выполненения запроса
Понятно. Спасибо. Но всетаки больше интересовала вторая ошибка: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 раза увеличилось время выполненения запроса
Это из-за того, что в 2.5 security class'ы именуются не так, как привык 2.1Zoran писал(а):Но всетаки больше интересовала вторая ошибка:По итогу к восстановленной с ошибкой базе можно подключиться и приходится вручную перекомпилировать все процедуры и вью, а также включать заново индексы. Можно эту ошибку как-нибудь побороть?Код: Выделить всё
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
Народ вроде находил как обойти, поищи на sql.ru