powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Время prepare запроса
46 сообщений из 46, показаны все 2 страниц
Время prepare запроса
    #39461285
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
От чего может зависить время prepare? От индексов, триггеров, размера таблицы, а ещё от чего? Вопрос к чему - в боевой базе время подготовки запроса "плавает" от 5 мс до 3 минут. Почему?
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461295
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemar,

Одного и того же, или разных?
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461297
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WildSeryGallemar,

Одного и того же, или разных?
Одного и того же
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461300
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemar,

1. Делался ли перед этим prepare других запросов в которые входят те же таблицы
2. Загрузка системы в момент prepare
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461302
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисGallemar,

1. Делался ли перед этим prepare других запросов в которые входят те же таблицы
2. Загрузка системы в момент prepare

1. Делался. Вообще таблица одна из основных, шапка документа. В неё постоянно идет чтение/запись.
2. Загрузка какая? Нагрузка аппаратки или нагрузка на Бд?
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461305
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemar,

в ОС нагрузка на процессор, диски. Наиболее вероятно что какой-то тяжёлый запрос выполняется в это время
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461307
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис, тяжелый запрос на эту таблицу или вообще в базе?
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461320
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemar,

вообще в базе. Ты последи когда prepare идёт медленно. Догадки можно строить долго
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461337
Коваленко Дмитрий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GallemarОт чего может зависить время prepare? От индексов, триггеров, размера таблицы, а ещё от чего? Вопрос к чему - в боевой базе время подготовки запроса "плавает" от 5 мс до 3 минут.
Как вариант - от количества отложенных операций на клиенте, работающем через fbclient.dll
10-минутный "prepare"
Код: vbnet
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.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
option explicit

dim cn

set cn=createobject("ADODB.Connection")

cn.Provider="LCPI.IBProvider.3"

cn.Properties("location").value="localhost:d:\database\ram\ibp_test_fb30_d3_2.gdb"
cn.Properties("user id").value="GAMER"
cn.Properties("password").value="vermut"
cn.Properties("dbclient_library").value="fbclient_30.dll"

call cn.Open()

call cn.BeginTrans()

dim cmd, rs
set cmd=createobject("ADODB.Command")

set cmd.ActiveConnection=cn

cmd.CommandText="select ID from DUAL"

dim n

n=0

wscript.echo now()&" - START"

while(n<50000)
 n=n+1 

 if((n mod 10000)=0)then
  wscript.echo now()&" - "&n
 end if

 set rs=cmd.Execute()

 call rs.Close()
 
 set rs=nothing
wend

wscript.echo now()&" - STOP "

wscript.echo now()&" - SET QUERY TEXT"

cmd.CommandText="select ID+1 from DUAL"

wscript.echo now()&" - PREPARE+EXECUTE [relax and wait]"

set rs=cmd.Execute()

wscript.echo now()&" - FETCH FIRST RECORD"

wscript.echo "ID+1="&cstr(rs(0).value)

wscript.echo now()&" - EXIT"



Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
29.05.2017 10:32:11 - START
29.05.2017 10:32:12 - 10000
29.05.2017 10:32:15 - 20000
29.05.2017 10:32:18 - 30000
29.05.2017 10:32:22 - 40000
29.05.2017 10:32:27 - 50000
29.05.2017 10:32:27 - STOP
29.05.2017 10:32:27 - SET QUERY TEXT
29.05.2017 10:32:27 - PREPARE+EXECUTE [relax and wait]
29.05.2017 10:42:44 - FETCH FIRST RECORD
ID+1=2
29.05.2017 10:42:44 - EXIT

По факту, конечно, здесь тупит не prepare. Но вызов идет именно isc_dsql_prepare.

GallemarПочему?

Потому что вот

----
А еще можно помучать однонаправленные списки объектов
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461349
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Коваленко ДмитрийА еще можно помучать однонаправленные списки объектов
Это только сборка клиента или именно сервер:
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461351
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
?
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461355
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисGallemar,

вообще в базе. Ты последи когда prepare идёт медленно. Догадки можно строить долго
Да тут главная проблема, что о медленном prepare я узнаю постфактум, на следующий день. Остается только постоянно гонять трассировку, в надежде поймать тяжелый запрос, ну и gstat статистику о таблице смотреть.
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461363
Коваленко Дмитрий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GallemarКоваленко ДмитрийА еще можно помучать однонаправленные списки объектов
Это только сборка клиента или именно сервер:
В первом случае тупит fbclient.

А во втором - сервер.
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461397
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Analyzing database pages ...
DOCHEAD (1019)
Primary pointer page: 2181 <- увеличение может косвенно говорить об увеличении времени подготовки?:
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461404
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemar,

тут не те объёмы чтобы prepare долгим было. В тесте у kdv время prepare было 20 сек на терабайтной БД. Где табличка была в несколько миллиардов записей. Там одних PP было 30000.
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461410
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисТам одних PP было 30000.
и они были равномерно размазаны по терабайтному файлу БД.
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461419
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Целиком статистика этой таблицы:
Analyzing database pages ...
DOCHEAD (1019)
Primary pointer page: 2181, Index root page: 2182
Average record length: 178.34, total records: 21068778
Average version length: 54.89, total versions: 71119, max versions: 1024
Data pages: 283423, data page slots: 283423, average fill: 89%
Fill distribution:
0 - 19% = 12
20 - 39% = 2
40 - 59% = 7
60 - 79% = 3
80 - 99% = 283399
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461427
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GallemarAnalyzing database pages ...
DOCHEAD (1019)
Primary pointer page: 2181, Index root page: 2182
Average record length: 178.34, total records: 21068778
Average version length: 54.89, total versions: 71119, max versions: 1024 Ужас. Тут мусор кто-нибудь собирает ?
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461429
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
когда-то давно ещё на проверке прав могли возникнуть тормоза.
но это вродь допиливали.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461436
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GallemarДа тут главная проблема, что о медленном prepare я узнаю постфактум, на следующий день.Откуда известно, что тормозит именно препаре ?
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461477
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladGallemarAnalyzing database pages ...
DOCHEAD (1019)
Primary pointer page: 2181, Index root page: 2182
Average record length: 178.34, total records: 21068778
Average version length: 54.89, total versions: 71119, max versions: 1024 Ужас. Тут мусор кто-нибудь собирает ?

Собирает. Sweep делается раз в сутки,просто в эту таблицу постоянно чтение/запись.
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461478
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladGallemarДа тут главная проблема, что о медленном prepare я узнаю постфактум, на следующий день.Откуда известно, что тормозит именно препаре ?
Трассировал вместе с разработчиком софтины
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461576
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladGallemarДа тут главная проблема, что о медленном prepare я узнаю постфактум, на следующий день.Откуда известно, что тормозит именно препаре ?
Могу на почту скинуть логи и переписку с разработчиком,его умозаключения.
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461716
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemar,

Умозаключения вряд-ли надо (хотя можно), но лучше факты - лог трейса, раз трейсом исследовали.
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461724
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdv, позже скину. Только трейс не фб,а самой софтины.
...
Рейтинг: 0 / 0
Время prepare запроса
    #39461992
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladУжас. Тут мусор кто-нибудь собирает ?
Разве это ужас? Вот ужас:
Analyzing database pages ...
DOCHEAD (1019)
Primary pointer page: 2181, Index root page: 2182
Average record length: 178.36, total records: 21093443
Average version length: 40.68, total versions: 25773, max versions: 3672
Data pages: 283691, data page slots: 283691, average fill: 89%
Fill distribution:
0 - 19% = 78
20 - 39% = 2
40 - 59% = 7
60 - 79% = 3
80 - 99% = 283601
...
Рейтинг: 0 / 0
Время prepare запроса
    #39462000
Roman Simakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисGallemar,

тут не те объёмы чтобы prepare долгим было. В тесте у kdv время prepare было 20 сек на терабайтной БД. Где табличка была в несколько миллиардов записей. Там одних PP было 30000.

Я думаю, что под нагрузкой в разы может возрастать длительность именно этой стадии. Если нагрузка на ту же таблицу и коннектов несколько сотен.
При этом еще симптомом может служить длинная очередь к страничной блокировке. По номеру страницы можно определить что это PP, и именно той таблицы.
Если да, то случай тот самый.
...
Рейтинг: 0 / 0
Время prepare запроса
    #39462036
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Average version length: 41.48, total versions: 37992, max versions: 6972
...
Рейтинг: 0 / 0
Время prepare запроса
    #39462170
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Average version length: 41.84, total versions: 75366, max versions: 20017
...
Рейтинг: 0 / 0
Время prepare запроса
    #39462525
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemar,

Постеснялся бы таким хвастаться.
...
Рейтинг: 0 / 0
Время prepare запроса
    #39462734
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WildSeryGallemar,

Постеснялся бы таким хвастаться.
Почему? Это же проблема не администрирования базы,а разработки системы и ее эксплуатации. Вечером пройдет регламентнвй sweep и статистика будет сброшена.
...
Рейтинг: 0 / 0
Время prepare запроса
    #39462749
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemar,

сюда бы еще разницу Next-OAT, плюс из mon$transactions самую старую, сколько она живет. Впрочем, не думаю что тут будут какие-то открытия, потому что при интенсивности транзакций в этой системе цифры вполне нормальные.
...
Рейтинг: 0 / 0
Время prepare запроса
    #39462755
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdv, позже скину,у нас шесть утра,я только глаза открыл....
...
Рейтинг: 0 / 0
Время prepare запроса
    #39462793
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvGallemar,

сюда бы еще разницу Next-OAT, плюс из mon$transactions самую старую, сколько она живет.
Статистика за май в аттаче.
...
Рейтинг: 0 / 0
Время prepare запроса
    #39462808
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GallemarkdvGallemar,
сюда бы еще разницу Next-OAT, плюс из mon$transactions самую старую, сколько она живет.
Статистика за май в аттаче.

Взял на себя смелость отформатировать файл, разбить сутки подчеркиваниями, добавить колонку с Next-OAT .
Без всего этого файл является не более чем сырым источником первичных данных.

Вижу что практически ежедневно разрыв Next-OAT доходит до 1млн и более.
Соответственно, практически ежедневно, за редким исключением, есть долгоиграющие транзакции которые держат версии.
Отследить источник думаю достаточно просто - помониторить OT или OAT в течение дня, если она не меняется часа 3 - то через MON$-таблицы посмотреть что за транзакция и какой в ней запрос.
...
Рейтинг: 0 / 0
Время prepare запроса
    #39462824
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fraksОтследить источник думаю достаточно просто - помониторить OT или OAT в течение дня, если она не меняется часа 3 - то через MON$-таблицы посмотреть что за транзакция и какой в ней запрос.
В Mon$? Там только активные транзакции. Включен аудит, смотрим кто застревает.
...
Рейтинг: 0 / 0
Время prepare запроса
    #39462847
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GallemarfraksОтследить источник думаю достаточно просто - помониторить OT или OAT в течение дня, если она не меняется часа 3 - то через MON$-таблицы посмотреть что за транзакция и какой в ней запрос.
В Mon$? Там только активные транзакции. Включен аудит, смотрим кто застревает.

Так OAT это по твоему какие? Они у тебя и долгоиграют.
Фишка в том что ты можешь заранее узнать какой номер транзакции тебя интересует.
...
Рейтинг: 0 / 0
Время prepare запроса
    #39462852
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Например транзация 40913795 провисела 09.05.2017 с 9 до 16 часов, т.е. более 7 часов.
...
Рейтинг: 0 / 0
Время prepare запроса
    #39463065
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemar,

со всем этим надо не сюда, а к разработчику идти. Например, какого фига 3 мая с 20 до 21 налетело под полтора миллиона транзакций, и при этом OAT застряло?
Не вижу никаких проблем 3-4 раз в день снимать mon$attachments, mon$transactions и mon$statements и углядеть, что именно застревает.
У нас для этого есть MonLogger.
Чего-то трассировать на данном этапе не вижу смысла. Хотя, раз разработчик уже трассировал, значит софт будет исправлен.
...
Рейтинг: 0 / 0
Время prepare запроса
    #39463114
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Транзакции застревают в разное время,последнюю неделю больше ночью. Пока трассирую с минимальными настройками - коннекты и транзакции. Мой мониторинг умеет только счетчики транзакций фиксировать,для детального разбора надо переписывать. Monlogger у меня есть.
...
Рейтинг: 0 / 0
Время prepare запроса
    #39463123
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemar,

Тр-ция 22 483 043, активна *сегодня* в 11-00 и в 12-00 - это ночью ???

У тебя каждый день есть застревание OAT на час-два-пять.
В чём проблема найти её и приложение в таблицах мониторинга ?
В чём проблема найти в аудите эту тр-цию и опять-же приложение ?

Что ты вообще ищешь ?
...
Рейтинг: 0 / 0
Время prepare запроса
    #39463124
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не ту колонку скопировал - об этой тр-ции речь выше : 22 540 698
...
Рейтинг: 0 / 0
Время prepare запроса
    #39463127
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fraksОтследить источник думаю достаточно просто - помониторить OT или OAT в течение дня, если она не меняется часа 3 - то через MON$-таблицы посмотреть что за транзакция и какой в ней запрос.Уточню - OIT искать нет смысла, это по-определению уже не активная тр-ция.
Т.е. смотреть нужно на OAT.
И активного запроса в ней может и не быть. Посмотреть нужно, но не стоит ожидать его там найти.
Разве что там действительно какой-то фатальный мноночасовый запрос...
...
Рейтинг: 0 / 0
Время prepare запроса
    #39463453
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хотел бы поделиться своей идеей которая облегчает поиск источника проблем.
После того как глядя на текст запросов в мониторинге пытался отпределить в каком месте приложения этот запрос вызывается, принял для себя стандарт шапки запроса, первой строкой пишется имя формы/модуля, имя компонента с запросом.

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
-- FrmOrders.QSel
--
-- Журнал заказов контрагентов
--

select
  sord.data,
...



Теперь видя запрос в таблицах мониторинга сразу понятно откуда он вызывается, а в пределах модуля/формы уже проще найти как он употребляется и что там с транзакцией.
...
Рейтинг: 0 / 0
Время prepare запроса
    #39463466
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ОФФ


fraks> Хотел бы поделиться своей идеей которая облегчает поиск источника проблем.

Идея интересная, но если уж взял за правило - не проще
ли было бы просто запросы "проинвентаризировать"?
Я такое делал разок, но только для "важных", не всех.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Время prepare запроса
    #39463507
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамОФФ


fraks> Хотел бы поделиться своей идеей которая облегчает поиск источника проблем.

Идея интересная, но если уж взял за правило - не проще
ли было бы просто запросы "проинвентаризировать"?


Что ты имеешь ввиду под "проинвентаризировать"?

У меня в приложении 180 форм, в большинстве из них по 2-15 запросов.
Проблему с зависающими транзакциями я решил, но до сих пор встречаются формы где запросы не отформатированы по моему стандарту.

Помню что когда-то у FIB-ов была приблуда для централизованно посмотреть запросы по всем формам. Но тогда она мне была не нужна а сейчас не вижу ее. Да и пес с ней. При маневрах с компонентами буду мигрировать на UIB - там как раз тот минимуум что я использую, и UIB есть под Lazarus.
...
Рейтинг: 0 / 0
46 сообщений из 46, показаны все 2 страниц
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Время prepare запроса
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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