Начало » Использование СУБД » Firebird, HQbird, InterBase » FB 5.0 Производительность, оптимизация
FB 5.0 Производительность, оптимизация [сообщение #4716] |
Thu, 28 March 2024 15:19 |
pastor
Сообщений: 83 Зарегистрирован: June 2022 Географическое положение: Калуга
|
Member |
|
|
Вот такая фигня.
Оптимизация заключалась в выкидывании из запроса мастер таблицы, т.к. в след. джойне было условие 1:1 по FK
подготовка данных - заливка во временные таблицы - 18 сек. одинаково.
выборка из временных таблиц - через execute stmt
"FB50 not Optimized"
1 record(s) was(were) inserted into LOG_EVENTS
26 record(s) was(were) inserted into TMP$ATTRIBUTES
26536 record(s) was(were) inserted into TMP$ITEMS
563640 record(s) was(were) inserted into TMP$VALUES
70 record(s) was(were) inserted into TMP$ATTRIBUTE_AGREGATES
2 record(s) was(were) inserted into TMP$DIMENSIONS
26536 record(s) was(were) inserted into TMP$FACTS
1 record(s) was(were) inserted into STAT$REPORTS
------ Performance info ------
Prepare time = 0ms
Execute time = 2m 1s 140ms
Avg fetch time = 62,73 ms
Current memory = 1 688 768 688
Max memory = 1 720 519 616
Memory buffers = 99 999
Reads from disk to cache = 3 261
Writes from cache to disk = 1 486
Fetches from cache = 290 453 657
"FB50 Optimized"
1 record(s) was(were) inserted into LOG_EVENTS
26 record(s) was(were) inserted into TMP$ATTRIBUTES
26536 record(s) was(were) inserted into TMP$ITEMS
563640 record(s) was(were) inserted into TMP$VALUES
70 record(s) was(were) inserted into TMP$ATTRIBUTE_AGREGATES
2 record(s) was(were) inserted into TMP$DIMENSIONS
26536 record(s) was(were) inserted into TMP$FACTS
1 record(s) was(were) inserted into STAT$REPORTS
------ Performance info ------
Prepare time = 0ms
Execute time = 2m 18s 15ms
Avg fetch time = 71,18 ms
Current memory = 1 708 350 400
Max memory = 1 804 928 048
Memory buffers = 99 999
Reads from disk to cache = 0
Writes from cache to disk = 1 486
Fetches from cache = 223 855 928
"FB25 not Optimized"
26536 record(s) was(were) inserted into TMP$ITEMS
563640 record(s) was(were) inserted into TMP$VALUES
70 record(s) was(were) inserted into TMP$ATTRIBUTE_AGREGATES
26536 record(s) was(were) inserted into TMP$FACTS
2 record(s) was(were) inserted into TMP$DIMENSIONS
1 record(s) was(were) inserted into LOG_EVENTS
1 record(s) was(were) inserted into STAT$REPORTS
26 record(s) was(were) inserted into TMP$ATTRIBUTES
------ Performance info ------
Prepare time = 0ms
Execute time = 2m 17s 453ms
Avg fetch time = 70,89 ms
Current memory = 1 682 077 032
Max memory = 1 707 258 368
Memory buffers = 99 999
Reads from disk to cache = 3 584
Writes from cache to disk = 1 500
Fetches from cache = 370 518 541
"FB25 Optimized"
26536 record(s) was(were) inserted into TMP$ITEMS
563640 record(s) was(were) inserted into TMP$VALUES
70 record(s) was(were) inserted into TMP$ATTRIBUTE_AGREGATES
26536 record(s) was(were) inserted into TMP$FACTS
2 record(s) was(were) inserted into TMP$DIMENSIONS
1 record(s) was(were) inserted into LOG_EVENTS
1 record(s) was(were) inserted into STAT$REPORTS
26 record(s) was(were) inserted into TMP$ATTRIBUTES
------ Performance info ------
Prepare time = 0ms
Execute time = 1m 9s 688ms
Avg fetch time = 35,94 ms
Current memory = 1 682 268 816
Max memory = 1 707 258 368
Memory buffers = 99 999
Reads from disk to cache = 4
Writes from cache to disk = 1 566
Fetches from cache = 169 515 628
|
|
|
|
|
|
Re: FB 5.0 Производительность, оптимизация [сообщение #4720 является ответом на сообщение #4717] |
Thu, 28 March 2024 16:26 |
pastor
Сообщений: 83 Зарегистрирован: June 2022 Географическое положение: Калуга
|
Member |
|
|
Не самый оптимальный
От повтора запуска статистикак не меняется
select sum( cast(f.FACT_VALUE as numeric(15,2)))
from TMP$ITEMS i
join TMP$VALUES v0 on v0.ID_ITEM = i.ID and v0.ID_ATTRIBUTE = 0 and v0.ATTRIBUTE_VALUE = :OPER
join TMP$VALUES v7 on v7.ID_ITEM = i.ID and v7.ID_ATTRIBUTE = 7 -- код
join TMP$VALUES vG on vG.ID_ITEM = i.ID and vG.ID_ATTRIBUTE = 13
join TMP$FACTS f on f.ID_ITEM = i.ID
where v0.ID_ATTRIBUTE = 0 and v0.ATTRIBUTE_VALUE = :OPER
and v7.ATTRIBUTE_VALUE = :S7
and vG.ATTRIBUTE_VALUE = :S13
and f.ID_DIMENSION = :ID_PAY
План
--------------------------------------------------------------------------------
PLAN JOIN (F INDEX (TMP$FACTS_DIMENSION), I INDEX (TMP$ITEMS), V0 INDEX (TMP$VALUES), V7 INDEX (TMP$VALUES), VG INDEX (TMP$VALUES))
------ Performance info ------
Prepare time = 0ms
Execute time = 31ms
Avg fetch time = 31,00 ms
Current memory = 1 691 251 696
Max memory = 1 787 191 552
Memory buffers = 99 999
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 81 104
Оптимальный
select sum( cast(f.FACT_VALUE as numeric(15,2)))
from -- TMP$ITEMS i
--join TMP$VALUES v0 on v0.ID_ITEM = i.ID and v0.ID_ATTRIBUTE = 0 and v0.ATTRIBUTE_VALUE = :OPER
TMP$VALUES v0
join TMP$VALUES v7 on v7.ID_ITEM = v0.ID_ITEM and v7.ID_ATTRIBUTE = 7 -- код
join TMP$VALUES vG on vG.ID_ITEM = v0.ID_ITEM and vG.ID_ATTRIBUTE = 13
join TMP$FACTS f on f.ID_ITEM = v0.ID_ITEM
where v0.ID_ATTRIBUTE = 0 and v0.ATTRIBUTE_VALUE = :OPER
and v7.ATTRIBUTE_VALUE = :S7
and vG.ATTRIBUTE_VALUE = :S13
and f.ID_DIMENSION = :ID_PAY
Первый пуск
План
--------------------------------------------------------------------------------
PLAN JOIN (F INDEX (TMP$FACTS_DIMENSION), V0 INDEX (TMP$VALUES), V7 INDEX (TMP$VALUES), VG INDEX (TMP$VALUES))
------ Performance info ------
Prepare time = 0ms
Execute time = 31ms
Avg fetch time = 31,00 ms
Current memory = 1 691 251 792
Max memory = 1 787 191 552
Memory buffers = 99 999
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 61 484
Повторный пуск
План
--------------------------------------------------------------------------------
PLAN JOIN (F INDEX (TMP$FACTS_DIMENSION), V0 INDEX (TMP$VALUES), V7 INDEX (TMP$VALUES), VG INDEX (TMP$VALUES))
------ Performance info ------
Prepare time = 0ms
Execute time = 16ms
Avg fetch time = 16,00 ms
Current memory = 1 691 251 792
Max memory = 1 787 191 552
Memory buffers = 99 999
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 61 484
Таблицы временные, какой там план внутри процедуры - пес его знает.
вызывается так
for execute statement (PSQL) (S13:=:S13, S7:=:S7, ID_PAY:=:ID_PAY, OPER:=OPER)
into :M17
|
|
|
|
|
|
Re: FB 5.0 Производительность, оптимизация [сообщение #4728 является ответом на сообщение #4724] |
Fri, 29 March 2024 12:31 |
pastor
Сообщений: 83 Зарегистрирован: June 2022 Географическое положение: Калуга
|
Member |
|
|
меняем показания:
порезал код процедуры с 900 строк до 100.
остался последний ES,. тормоз остался
нашел четыре обращения к большим временным таблицам без ES
итого:
1. ES стали работать медленнее
есть две идентичные базы 2.5 и 5.0
в архиве - около 10 мб
прислать?
[Обновления: Fri, 29 March 2024 13:13] Известить модератора
|
|
|
|
Re: FB 5.0 Производительность, оптимизация [сообщение #4730 является ответом на сообщение #4716] |
Fri, 29 March 2024 14:04 |
pastor
Сообщений: 83 Зарегистрирован: June 2022 Географическое положение: Калуга
|
Member |
|
|
[color=blue]ASQL[/color] = 'select
v7.ATTRIBUTE_VALUE as CODE,
v8.ATTRIBUTE_VALUE as NAME,
cast(v13.ATTRIBUTE_VALUE as numeric(15,2)) as PRICE,
sum( cast(v14.ATTRIBUTE_VALUE as numeric(15,1))) as AMOUNT--,
from
TMP$VALUES v0
join TMP$VALUES v7 on v7.ID_ITEM = v0.ID_ITEM and v7.ID_ATTRIBUTE = 7 -- код
join TMP$VALUES v8 on v8.ID_ITEM = v0.ID_ITEM and v8.ID_ATTRIBUTE = 8 -- название
join TMP$VALUES v10 on v10.ID_ITEM = v0.ID_ITEM and v10.ID_ATTRIBUTE = 10 -- группа услуг
join TMP$VALUES v13 on v13.ID_ITEM = v0.ID_ITEM and v13.ID_ATTRIBUTE = 13 -- цена
join TMP$VALUES v14 on v14.ID_ITEM = v0.ID_ITEM and v14.ID_ATTRIBUTE = 14 -- кол-во
where v0.ID_ATTRIBUTE = 0 and v0.ATTRIBUTE_VALUE = :OPER
and v7.ATTRIBUTE_VALUE = :S7
and v10.ATTRIBUTE_VALUE = :S10
group by 1, 2, 3
order by 1, 2, 3';
вызывается вот так (995 раз)
модельные параметры:
OPER = 'SALE'
S7 = '1003'
S10 = 'Бассейн'
DB = 'NOW';
-- услуги в группировке по коду/имени/цене
CNT_ASQL = CNT_ASQL + 1;
for execute statement (ASQL) (S7:=:S1, S10:=:S10, OPER:=:OPER)
into :S7, :S8, :S13, :S14
do begin
/*
STRINGS = (select first 1 s.MON$EXPLAINED_PLAN from MON$COMPILED_STATEMENTS s
where S.MON$SQL_TEXT containing 'TMP$VALUES');
suspend;
*/
end -- услуги в группировке по коду/имени/цене
DE = 'NOW';
STRINGS = '<!-- "'|| :S1|| '" "'|| :S2|| '" '||datediff( millisecond, DB, DE)||' -->'; suspend;
FB50
изнутри процедуры
<!-- "1003" "3083" 130.0 -->
Select Expression
-> Sort (record length: 2628, key length: 1044)
-> Aggregate
-> Refetch
-> Sort (record length: 1152, key length: 1044)
-> Filter
-> Hash Join (inner)
-> Hash Join (inner)
-> Hash Join (inner)
-> Hash Join (inner)
-> Hash Join (inner)
-> Filter
-> Table "TMP$VALUES" as "V0" Access By ID
-> Bitmap
-> Index "TMP$VALUES_ATT" Range Scan (full match)
-> Record Buffer (record length: 561)
-> Filter
-> Table "TMP$VALUES" as "V7" Access By ID
-> Bitmap
- > Index "TMP$VALUES_ATT" Range Scan (full match)
-> Record Buffer (record length: 561)
-> Filter
-> Table "TMP$VALUES" as "V8" Access By ID
-> Bitmap
-> Index "TMP$VALUES_ATT" Range Scan (full match)
-> Record Buffer (record length: 561)
-> Filter
-> Table "TMP$VALUES" as "V10" Access By ID
-> Bitmap
-> Index "TMP$VALUES_ATT" Range Scan (full match)
-> Record Buffer (record length: 561)
-> Filter
-> Table "TMP$VALUES" as "V13" Access By ID
-> Bitmap
-> Index "TMP$VALUES_ATT" Range Scan (full match)
-> Record Buffer (record length: 561)
-> Filter
-> Table "TMP$VALUES" as "V14" Access By ID
-> Bitmap
-> Index "TMP$VALUES_ATT" Range Scan (full match)
отдельно, с теми же параметрами
------ Performance info ------
Prepare time = 0ms
Execute time = 172ms
Avg fetch time = 172,00 ms
Current memory = 456 180 224
Max memory = 538 854 576
Memory buffers = 99 999
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 255 640
PLAN SORT (SORT (HASH (HASH (HASH (HASH (HASH (V0 INDEX (TMP$VALUES_ATT), V7 INDEX (TMP$VALUES_ATT)), V8 INDEX (TMP$VALUES_ATT)), V10 INDEX (TMP$VALUES_ATT)), V13 INDEX (TMP$VALUES_ATT)), V14 INDEX (TMP$VALUES_ATT))))
------------------------------------------------------------ --------------------
------------------------------------------------------------ --------------------
------------------------------------------------------------ --------------------
FB25
изнутри процедуры
<!-- "1003" "3083" 85 -->
плана, есс-но нет
отдельно, с теми же параметрами
План
------------------------------------------------------------ --------------------
PLAN SORT (SORT (JOIN (V0 INDEX (TMP$VALUES_AV), V7 INDEX (TMP$VALUES), V8 INDEX (TMP$VALUES), V10 INDEX (TMP$VALUES), V13 INDEX (TMP$VALUES), V14 INDEX (TMP$VALUES))))
------ Performance info ------
Prepare time = 0ms
Execute time = 125ms
Avg fetch time = 125,00 ms
Current memory = 449 807 208
Max memory = 463 328 096
Memory buffers = 99 999
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 285 675
|
|
|
|
|
|
|
Re: FB 5.0 Производительность, оптимизация [сообщение #4735 является ответом на сообщение #4734] |
Fri, 29 March 2024 15:05 |
hvlad
Сообщений: 358 Зарегистрирован: August 2022
|
Senior Member |
|
|
pastor писал(а) Fri, 29 March 2024 13:59sim_84 писал(а) Fri, 29 March 2024 14:48Таблицы временные - оптимизатору не известны ни кардинальности, ни нормальные селективности индексов, вот и фигачит везде HASH JOIN.
Если бы таблицы были постоянными у оптимизатора 5-ки было бы выше шансов построить оптимальный план
я раз в два года беспокою Влада по этому поводу.
при использовании ES в 2.5 жизнь наладилась
после чесания репы, наладилась еще в 2.5 раза
в 5.0 немножко вернулась взад, на исходную
т.к. сбор отчетов через временные таблицы становится мейнстримом (кубы для нищебродов ), то хочется найти пусть и обходное, но решение
А насколько большие эти GTT ?
|
|
|
Re: FB 5.0 Производительность, оптимизация [сообщение #4736 является ответом на сообщение #4735] |
Fri, 29 March 2024 15:10 |
pastor
Сообщений: 83 Зарегистрирован: June 2022 Географическое положение: Калуга
|
Member |
|
|
hvlad писал(а) Fri, 29 March 2024 15:05pastor писал(а) Fri, 29 March 2024 13:59sim_84 писал(а) Fri, 29 March 2024 14:48Таблицы временные - оптимизатору не известны ни кардинальности, ни нормальные селективности индексов, вот и фигачит везде HASH JOIN.
Если бы таблицы были постоянными у оптимизатора 5-ки было бы выше шансов построить оптимальный план
я раз в два года беспокою Влада по этому поводу.
при использовании ES в 2.5 жизнь наладилась
после чесания репы, наладилась еще в 2.5 раза
в 5.0 немножко вернулась взад, на исходную
т.к. сбор отчетов через временные таблицы становится мейнстримом (кубы для нищебродов ), то хочется найти пусть и обходное, но решение
А насколько большие эти GTT ?
26 record(s) was(were) inserted into TMP$ATTRIBUTES
26536 record(s) was(were) inserted into TMP$ITEMS
563640 record(s) was(were) inserted into TMP$VALUES
70 record(s) was(were) inserted into TMP$ATTRIBUTE_AGREGATES
2 record(s) was(were) inserted into TMP$DIMENSIONS
26536 record(s) was(were) inserted into TMP$FACTS
это за месяц
около 1000 проходов - 2.5 минуты на АИ50 и 1 мин на АИ25
за год соответственно 6 млн записей
27 мин и 11 мин соответственно
[Обновления: Fri, 29 March 2024 15:10] Известить модератора
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: FB 5.0 Производительность, оптимизация [сообщение #4748 является ответом на сообщение #4747] |
Fri, 29 March 2024 15:50 |
pastor
Сообщений: 83 Зарегистрирован: June 2022 Географическое положение: Калуга
|
Member |
|
|
select
v7.ATTRIBUTE_VALUE as CODE,
v8.ATTRIBUTE_VALUE as NAME,
cast(v13.ATTRIBUTE_VALUE as numeric(15,2)) as PRICE,
sum( cast(v14.ATTRIBUTE_VALUE as numeric(15,1))) as AMOUNT--,
from
TMP$VALUES v0
join TMP$VALUES v7 on v7.ID_ITEM = v0.ID_ITEM and v7.ID_ATTRIBUTE = 7 -- код
join TMP$VALUES v8 on v8.ID_ITEM = v0.ID_ITEM and v8.ID_ATTRIBUTE = 8 -- название
join TMP$VALUES v10 on v10.ID_ITEM = v0.ID_ITEM and v10.ID_ATTRIBUTE = 10 -- группа услуг
join TMP$VALUES v13 on v13.ID_ITEM = v0.ID_ITEM and v13.ID_ATTRIBUTE = 13 -- цена
join TMP$VALUES v14 on v14.ID_ITEM = v0.ID_ITEM and v14.ID_ATTRIBUTE = 14 -- кол-во
where v0.ID_ATTRIBUTE = 0 and v0.ATTRIBUTE_VALUE = :OPER
and v7.ATTRIBUTE_VALUE = :S7
and v10.ATTRIBUTE_VALUE = :S10
group by 1, 2, 3
PLAN JOIN (V0 INDEX (TMP$VALUES_AV), V7 INDEX (TMP$VALUES), V8 INDEX (TMP$VALUES), V10 INDEX (TMP$VALUES), V13 INDEX (TMP$VALUES), V14 INDEX (TMP$VALUES))
order by 1, 2, 3
дало 170->106 ms в отдельном запросе
при попытке вставить в ES
Dynamic SQL Error.
SQL error code = -104.
Token unknown - line 22, column 30.
group.
<Missing arg #1 - possibly status vector overflow>.
-----------------------------------------------------------------------------------------
SQLCODE: -104
SQLSTATE: 42000
GDSCODE: 335544569
|
|
|
|
|
|
Re: FB 5.0 Производительность, оптимизация [сообщение #4752 является ответом на сообщение #4751] |
Fri, 29 March 2024 19:22 |
pastor
Сообщений: 83 Зарегистрирован: June 2022 Географическое положение: Калуга
|
Member |
|
|
в эксперте прокатилло
а доку по планам я сегодня в первый раз читал. и вней прям буквами - "перед order"
PS точно. слаб на глаза стал
PPS
------ Performance info ------
Prepare time = 0ms
Execute time = 49s 750ms
Avg fetch time = 49,95 ms
Current memory = 777 161 200
Max memory = 811 366 512
Memory buffers = 99 999
Reads from disk to cache = 0
Writes from cache to disk = 6 416
Fetches from cache = 125 050 775
[Обновления: Fri, 29 March 2024 19:28] Известить модератора
|
|
|
|
|
Re: FB 5.0 Производительность, оптимизация [сообщение #4756 является ответом на сообщение #4755] |
Sat, 30 March 2024 10:20 |
pastor
Сообщений: 83 Зарегистрирован: June 2022 Географическое положение: Калуга
|
Member |
|
|
это паллиатив
оно и так уже на нескольких обходных решениях держится
четыре предметные области, каждая со своим набором сущностей и атрибутов,
в каждой свои критерии группировки
свои произвольные\календарные\сезонн ые\тренировочные периоды
математически довольно легко формализуется
решается через отчеты по временным таблицам.
на небольших массивах - на отлично, 100% покрытие
на больших - упирается в быстродействие
лечится оно или нет? не знаю
может быть есть какое-нибудь элементарное решение типа весовых коэффициентов для временных таблиц оптимизатора, которое повысит вероятность использования индекса а не хаша.
или особенное вычисление/получение статистики индексов для временных таблиц (мы же знаем размер индекса,да?)
или в 6-ке будут гистограммы по мере наполнения данными
в исходниках оптимизатора я не ориентируюсь, вижу только внешние проявления, то вот, (стучу в бубен) взываю к Владу
чаще всего, (Небесный Ворон отвечает) получаю дельный совет
|
|
|
|
|
Re: FB 5.0 Производительность, оптимизация [сообщение #4761 является ответом на сообщение #4754] |
Sat, 30 March 2024 16:42 |
pastor
Сообщений: 83 Зарегистрирован: June 2022 Географическое положение: Калуга
|
Member |
|
|
hvlad писал(а) Fri, 29 March 2024 23:06pastor------ Performance info ------
Prepare time = 0ms
Execute time = 49s 750ms
Это нужно сравнивать с
pastorоколо 1000 проходов - 2.5 минуты на АИ50 и 1 мин на АИ25 ?
Т.е. стало чуть лучше, чем было в 2.5 ?
на 5.0 - 43 сек
на 2.5 - 47 секунд
там есть еще 4 (или уже 2? не помню) прохода по таблицам обычным запросом, без ES
это первые проходы сразу после коннекта
на втором удаляется по 600 000 записей
ЗЫ процедуры сильно урезаны по сравнению с оригиналом из первого поста.
[Обновления: Sat, 30 March 2024 17:01] Известить модератора
|
|
|
|
Переход к форуму:
Текущее время: Wed Dec 04 11:39:38 GMT+3 2024
Общее время, затраченное на создание страницы: 0.03134 секунд
|