Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
 время выполнения запроса  [new]
che_work
Member

Откуда:
Сообщений: 19
Добрый день!
В рунтайме программа в цикле формирует запросы к БД для заполнения книги в Экселе.
порядка 30тыс селектов разной степени сложности (размерность таблицы 900 на 35).
время выполнения одного запроса 3-10сек. Например такой

select count(id) from sc inner join scf on sc.id=scf.stat_card_id where sc_id!=-1 and (period_id = 20 or period_id = 19 ) and ((( scf.res=21 or scf.res=32 or scf.res=1 or scf.res=31 or scf.res=4 or scf.res=5 or scf.res=6 or scf.res=7 or scf.res=8 or scf.res=9 or scf.res=10 or scf.res=11 or scf.res=12 or scf.res=13 or scf.res=14 or scf.res=15 or scf.res=17 or scf.res=18 or scf.res=16 or scf.res=20) ) ) and (( scf.res=1 ) ) and sc.mode_sc in (0,1,4)

План выполнения такой
Plan
PLAN JOIN (SCF INDEX (SCF_RES, SCF_PERIOD_ID, SCF_PERIOD_ID), SC INDEX (RDB$PRIMARY51))

Adapted Plan
PLAN JOIN (SCF INDEX (SCF_RES, SCF_PERIOD_ID, SCF_PERIOD_ID), SC INDEX (PK_SC))

------ Performance info ------
Prepare time = 0ms
Execute time = 3s 276ms
Avg fetch time = 3 276,00 ms
Current memory = 43 336 744
Max memory = 43 482 792
Memory buffers = 2 048
Reads from disk to cache = 52 484
Writes from cache to disk = 0
Fetches from cache = 5 515 962

FB - SS 2.5.1.26351
Win7(64)
Для доступа к базе используются компоненты FIB.
КОличество записей в SC и SCF порядка 10млн.

Это нормальное (обычное) время выполнения запроса или можно как-то ускорить, чтобы было менее секунды.
Сейчас для расчета такой таблицы уходит порядка суток!
+
13 сен 18, 22:16    [21674236]     Ответить | Цитировать Сообщить модератору
 Re: время выполнения запроса  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 8786
che_work,

страничный кеш подымай, раз уж у тебя супер. Например до 50K. Не знаю насколько его можно ещё задрать в 2.5, но не больше чем FileSystemCacheThreshold.
Запрос наверное тоже можно ускорить, но я так понял они у вас автоматом строятся
13 сен 18, 22:31    [21674250]     Ответить | Цитировать Сообщить модератору
 Re: время выполнения запроса  [new]
che_work
Member

Откуда:
Сообщений: 19
Симонов Денис
che_work,

страничный кеш подымай, раз уж у тебя супер. Например до 50K. Не знаю насколько его можно ещё задрать в 2.5, но не больше чем FileSystemCacheThreshold.
Запрос наверное тоже можно ускорить, но я так понял они у вас автоматом строятся

Да, не указывал - настройки сервера все дефолтные.
DefaultDbCachePages - этот параметр?
13 сен 18, 22:35    [21674253]     Ответить | Цитировать Сообщить модератору
 Re: время выполнения запроса  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 8786
che_work,

да. Если программу разрабатываешь ты, можно попробовать аккуратно перейти на 3.0
13 сен 18, 22:43    [21674262]     Ответить | Цитировать Сообщить модератору
 Re: время выполнения запроса  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 46126

che_work
Например такой

Это настоящий запрос или "чисто для примера"? В первом случае его формирователю надо
что-нибудь оторвать за условие "(scf.res=21 or scf.res=1) and scf.res=1".

Posted via ActualForum NNTP Server 1.5

14 сен 18, 00:17    [21674292]     Ответить | Цитировать Сообщить модератору
 Re: время выполнения запроса  [new]
hvlad
Member

Откуда:
Сообщений: 10018
che_work
порядка 30тыс селектов
...
можно как-то ускорить
Избавиться от 30к запросов. Другого пути нет.
14 сен 18, 09:01    [21674350]     Ответить | Цитировать Сообщить модератору
 Re: время выполнения запроса  [new]
che_work
Member

Откуда:
Сообщений: 19
Dimitry Sibiryakov
che_work
Например такой

Это настоящий запрос или "чисто для примера"? В первом случае его формирователю надо
что-нибудь оторвать за условие "(scf.res=21 or scf.res=1) and scf.res=1".
Не нужно отрывать.
Запрос реальный, не "для примера". Есть и более сложные - связь по трем-четырем таблицам inner join, условия для проверки на бОльшее количество строк.
Так построен алгоритм формирования запросов - условия по строке таблицы + условия по графе.
В общем от этого не уйти. Но ведь не это же причина "тормозов" ?
Собственно я хотел узнать: при таких условиях время 3-10 сек - это "тормоза" или норма? Или можно улучшить хотя бы в несколько раз?
И тогда еще попутно вопрос - в толстом клиенте замерял время выполнения этих же запросов. Там время выполнения больше - 10-20 сек, чем в ibexpert-е. Наверное так и должно быть? (работа компонентов FIB? сервера). Или же время должно быть сопоставимо?
14 сен 18, 10:41    [21674449]     Ответить | Цитировать Сообщить модератору
 Re: время выполнения запроса  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 46126

che_work
В общем от этого не уйти. Но ведь не это же причина "тормозов" ?

Может быть и в этом. Изучай http://www.ibase.ru/dataaccesspaths/

che_work
Собственно я хотел узнать: при таких условиях время 3-10 сек - это
"тормоза" или норма? Или можно улучшить хотя бы в несколько раз?

Это тормоза. Улучшить, скорее всего, можно.

Posted via ActualForum NNTP Server 1.5

14 сен 18, 12:43    [21674614]     Ответить | Цитировать Сообщить модератору
 Re: время выполнения запроса  [new]
Ivan_Pisarevsky
Member

Откуда: НН
Сообщений: 8106
che_work
Там время выполнения больше - 10-20 сек, чем в ibexpert-е. Наверное так и должно быть? (работа компонентов FIB? сервера).
Я тебе страшную тайну приоткрою, в эксперте используются ФИБ-ы. :)

che_work
Memory buffers = 2 048
Reads from disk to cache = 52 484
Увеличивай первый параметр (научное имя DefaultDbCachePages в конфиге), чтобы второй приблизился к нулю и при этом сервер не вывалился в своп.

Сам сервер обновить как минимум до 2.5.8
14 сен 18, 13:21    [21674660]     Ответить | Цитировать Сообщить модератору
 Re: время выполнения запроса  [new]
che_work
Member

Откуда:
Сообщений: 19
Ivan_Pisarevsky
che_work
Там время выполнения больше - 10-20 сек, чем в ibexpert-е. Наверное так и должно быть? (работа компонентов FIB? сервера).
Я тебе страшную тайну приоткрою, в эксперте используются ФИБ-ы. :)

che_work
Memory buffers = 2 048
Reads from disk to cache = 52 484
Увеличивай первый параметр (научное имя DefaultDbCachePages в конфиге), чтобы второй приблизился к нулю и при этом сервер не вывалился в своп.

Сам сервер обновить как минимум до 2.5.8
Спасибо. Проверю
14 сен 18, 14:45    [21674787]     Ответить | Цитировать Сообщить модератору
 Re: время выполнения запроса  [new]
che_work
Member

Откуда:
Сообщений: 19
+
поставил FB - SS 2.5.8.
Увеличил DefaultDbCachePages. Сделал равным 65 536.

Первый раз после запуска службы в ibexpert-e показатели такие
Prepare time = 0ms
Execute time = 1m 21s 464ms
Avg fetch time = 81 464,00 ms
Current memory = 1 099 025 072
Max memory = 1 099 034 816
Memory buffers = 65 536
Reads from disk to cache = 49 544
Writes from cache to disk = 0
Fetches from cache = 5 515 962

Второй раз выполнил запрос - данные дргие.
Prepare time = 0ms
Execute time = 2s 995ms
Avg fetch time = 2 995,00 ms
Current memory = 1 099 025 192
Max memory = 1 099 148 544
Memory buffers = 65 536
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 5 515 962

Лучше , но всё равно сравнимо с первоначальным. Наверное настройками сервера кардинально показатели не улучшить
14 сен 18, 15:24    [21674838]     Ответить | Цитировать Сообщить модератору
 Re: время выполнения запроса  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 46126

che_work
Memory buffers = 65 536
Лучше , но всё равно сравнимо с первоначальным.
А ведь тебя специально
предупреждали, чтобы ты не ставил 65536 или любое другое число, большее, чем
SystemCacheTreshold...

С таким отношением, я так понимаю, про селективность индексов и сбор статистики лучше
вообще не заикаться.

Posted via ActualForum NNTP Server 1.5

14 сен 18, 15:49    [21674865]     Ответить | Цитировать Сообщить модератору
 Re: время выполнения запроса  [new]
che_work
Member

Откуда:
Сообщений: 19
Dimitry Sibiryakov
che_work
Memory buffers = 65 536
Лучше , но всё равно сравнимо с первоначальным.
А ведь тебя специально
предупреждали, чтобы ты не ставил 65536 или любое другое число, большее, чем
SystemCacheTreshold...

С таким отношением, я так понимаю, про селективность индексов и сбор статистики лучше
вообще не заикаться.

Я проверил разные варианты - 8К, 16К, 32К, 64К
Сейчас поставил 64000
Результат:
+
Plan
PLAN JOIN (STAT_CARD_FLAT INDEX (SCF_RES_MEETING, SCF_PERIOD_ID, SCF_PERIOD_ID), STAT_CARD INDEX (RDB$PRIMARY51))

Adapted Plan
PLAN JOIN (STAT_CARD_FLAT INDEX (SCF_RES_MEETING, SCF_PERIOD_ID, SCF_PERIOD_ID), STAT_CARD INDEX (PK_STAT_CARD))

------ Performance info ------
Prepare time = 0ms
Execute time = 1m 18s 516ms
Avg fetch time = 78 516,00 ms
Current memory = 1 073 490 616
Max memory = 1 073 500 504
Memory buffers = 64 000
Reads from disk to cache = 49 544
Writes from cache to disk = 0
Fetches from cache = 5 515 96

Plan
PLAN JOIN (STAT_CARD_FLAT INDEX (SCF_RES_MEETING, SCF_PERIOD_ID, SCF_PERIOD_ID), STAT_CARD INDEX (RDB$PRIMARY51))

Adapted Plan
PLAN JOIN (STAT_CARD_FLAT INDEX (SCF_RES_MEETING, SCF_PERIOD_ID, SCF_PERIOD_ID), STAT_CARD INDEX (PK_STAT_CARD))

------ Performance info ------
Prepare time = 0ms
Execute time = 2s 902ms
Avg fetch time = 2 902,00 ms
Current memory = 1 073 490 712
Max memory = 1 073 614 104
Memory buffers = 64 000
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 5 515 962
14 сен 18, 16:14    [21674891]     Ответить | Цитировать Сообщить модератору
 Re: время выполнения запроса  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 8786
che_work,

значит остаётся только переписывать запросы в человеческий вид

Ну и 30000 SELECT запросов в цикле это бред, над архитектурой надо крепко подумать
14 сен 18, 17:03    [21674942]     Ответить | Цитировать Сообщить модератору
 Re: время выполнения запроса  [new]
che_work
Member

Откуда:
Сообщений: 19
Симонов Денис
che_work,

значит остаётся только переписывать запросы в человеческий вид

Ну и 30000 SELECT запросов в цикле это бред, над архитектурой надо крепко подумать
понятно, спасибо
14 сен 18, 17:28    [21674968]     Ответить | Цитировать Сообщить модератору
 Re: время выполнения запроса  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 46126

che_work
Я проверил разные варианты - 8К, 16К, 32К, 64К

Ок, всё закэшировано.

Раз уж ты самостоятельно изучать теорию не хочешь, идём дальше по шагам.

Если выкинуть из запроса бессмысленный мусор, в нём остаётся три полезных условия:
1) period_id = 20 or period_id = 19
2) scf.res=1
3) sc.mode_sc in (0,1,4)

Сколько записей подпадают под эти условия по отдельности (в штуках и процентах от общего
числа записей в соответствующей таблице)?

Posted via ActualForum NNTP Server 1.5

15 сен 18, 17:34    [21675596]     Ответить | Цитировать Сообщить модератору
 Re: время выполнения запроса  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 8786
Dimitry Sibiryakov,

да бесполезно это. Ты ему один запрос поправишь, а него ещё 29999 построенных по тому же принципу
15 сен 18, 17:58    [21675603]     Ответить | Цитировать Сообщить модератору
 Re: время выполнения запроса  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 46126

Симонов Денис
Ты ему один запрос поправишь, а него ещё 29999 построенных по тому же принципу

Значит и будем править принцип. Может, ему статистику индексов просто пересчитать надо?..

Posted via ActualForum NNTP Server 1.5

15 сен 18, 18:09    [21675606]     Ответить | Цитировать Сообщить модератору
Все форумы / Firebird, InterBase Ответить