ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / select ... from <some_complex_sp>: работает долго, а в где именно затык - непонятно
6 сообщений из 6, страница 1 из 1
select ... from <some_complex_sp>: работает долго, а в где именно затык - непонятно
    #38648216
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hi all

Продолжаю издевацца над ФБ-3. Запустил снова OLTP-EMUL тест, 35 аттачей (копейки!).
В отдельном окне работает трейс с конфигом, фильтрующим только запросы, длящиеся свыше 15 сек.

Вот один из перлов:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
execute block returns( . . . )  
as                                                                         
   declare v_linked_client_order smallint;                                 
begin                                                                      
    if ( exists( select * from v_qdistr_avl_res ) ) then                 
    begin                                                                  
      v_linked_client_order = iif( rand() > 0.2, null, -1 );            
      select min(p.doc_list_id), min(client_order_id), count(*),        
             sum(p.purchase), sum(p.retail)                              
      from sp_customer_reserve( :v_linked_client_order ) p                
      into reserve_doc_id, client_order_id, total_lines, purchase_sum, retail_sum;       
      suspend;                                                             
   end                                                                     
end
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (V_QDISTR_AVL_RES Q INDEX (QDISTR_RCV_ID))
PLAN (P NATURAL)
0 records fetched
   17663 ms , 42 write(s), 1032735 fetch(es), 292 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$INDICES                                       1                                                            
RDB$EXCEPTIONS                                    1                                                            
TMP$SHOPPING_CART                       5       716         6         2                   2                    
ZTMP_SHOPPING_CART                                                    4                                        
FIFO_RULES                             56       357                                                            
QDISTR                             231795     12321        28                                                  
ABEND_LOG                                                            28                                        
PERF_LOG                                          2         2         2


Есть что-то сюрреалистичное в значении времени (17 сек), при том, что:
0) число фетчей - 1032735 - не очень велико;
1) всего-то 230 тыс NR'ов и 12 тыс IR'ов (остальное рояля вообще не играет, КМК);
2) нет reads;
3) почти нет writes.

Транзакции все работают с TIL = SNAPSHOT NO WAIT ==> затрат на тупое ожидание высвобождения ресурсов тут нет (да и быть не могло, ибо снапшот обломался бы при select ... from ... for update with lock, в отличие от RC)

Отсутствие в статистике затрат на сортировки - бич нашего времени. Скорее всего, всё упёрлось именно в них.
Кроме того, план в 3.х для случая вызова ХП теперь выглядит сверхлаконично. Раньше вода была мокрее: можно было в карусадне планов выявить "виновника торжества".

И как теперь искать, "в где косяк" ??
...
Рейтинг: 0 / 0
22.05.2014, 00:01
| Ответить | Цитировать | Написать  
select ... from <some_complex_sp>: работает долго, а в где именно затык - непонятно
    #38648302
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
не вижу ничего удивительного. ХЗ что у тебя там в хранимой процедуре sp_customer_reserve делается, может цикл на 10E9 итераций , который не обращается ни к какой таблицы, но время таки занимает
...
Рейтинг: 0 / 0
22.05.2014, 06:58
| Ответить | Цитировать | Написать  
select ... from <some_complex_sp>: работает долго, а в где именно затык - непонятно
    #38648438
anpl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
anpl
Участник
Код: sql
1.
sp_customer_reserve( :v_linked_client_order )


процентов на 70% уверен что вот эта штука! :)
...
Рейтинг: 0 / 0
22.05.2014, 10:06
| Ответить | Цитировать | Написать  
select ... from <some_complex_sp>: работает долго, а в где именно затык - непонятно
    #38648474
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов Денисне вижу ничего удивительного. ХЗ что у тебя там в хранимой процедуре sp_customer_reserve делается, может цикл на 10E9 итераций , который не обращается ни к какой таблицы, но время таки занимаетНету там такого, 99.9% операций - с базой.

полу0xFF. Не хватает аналога ораклового dbms_hprof ("иерархич. профайлера"). Очень мощная штука: накапливает по-тихому статистику time_in + time_out для каждого места в pl/sql, где что-то вызывается (в т.ч. где идёт переключение в sql, а не только pl/sql'ные вызовы). А затем выводит всё в сводном виде, и сразу понятно, на каких строках кода больше всего тратится времени.
...
Рейтинг: 0 / 0
22.05.2014, 10:24
| Ответить | Цитировать | Написать  
select ... from <some_complex_sp>: работает долго, а в где именно затык - непонятно
    #38648492
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

у меня кстати была хотелка чтобы в трейсе можно было посмотреть explain форму плана. Влад сказал что это будет это делать ближе к бете и просил напомнить. Хотя твою проблему это не решит.

ТаблоидОтсутствие в статистике затрат на сортировки
там надо не только показывать затраты на сортировку, но и на хэширование (HASH) и на материлизацию. Я подозреваю что это будет агрегировано в одном блоке.

Кроме того ещё может помочь оценочные затраты на отдельные операции в explain плане такие как cost и cardinality + хорошо бы иметь оценочные затраты памяти на сортировку и хэш таблицу. Ещё было бы хорошо в explain плане видеть селективность индексов и предикатов, потому как некоторые предикаты такие как field between 1 and 5 оперируют некими константами и их неплохо было бы видеть для понимания почему такой план построен.
...
Рейтинг: 0 / 0
22.05.2014, 10:31
| Ответить | Цитировать | Написать  
select ... from <some_complex_sp>: работает долго, а в где именно затык - непонятно
    #38648499
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
ТаблоидНе хватает аналога ораклового dbms_hprof
помнится была идея сделать системную функцию для вывода произвольного пользовательского сообщения в трейс (хотя это и не то же самое, но иногда могло бы помочь)
...
Рейтинг: 0 / 0
22.05.2014, 10:34
| Ответить | Цитировать | Написать  
6 сообщений из 6, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / select ... from <some_complex_sp>: работает долго, а в где именно затык - непонятно
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&tid=1563580]:
 0ms
get settings:
 8ms
get forum list:
 13ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 179ms
get topic data:
 8ms
get forum data:
 4ms
get page messages:
 42ms
get tp. blocked users:
 1ms
others: 213ms
total:  472ms
созд. / загр.: 472ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]