Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Время prepare запроса
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2017, 09:09 |
|
||
|
Время prepare запроса
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисGallemar, тут не те объёмы чтобы prepare долгим было. В тесте у kdv время prepare было 20 сек на терабайтной БД. Где табличка была в несколько миллиардов записей. Там одних PP было 30000. Я думаю, что под нагрузкой в разы может возрастать длительность именно этой стадии. Если нагрузка на ту же таблицу и коннектов несколько сотен. При этом еще симптомом может служить длинная очередь к страничной блокировке. По номеру страницы можно определить что это PP, и именно той таблицы. Если да, то случай тот самый. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2017, 09:18 |
|
||
|
Время prepare запроса
|
|||
|---|---|---|---|
|
#18+
Average version length: 41.48, total versions: 37992, max versions: 6972 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2017, 09:58 |
|
||
|
Время prepare запроса
|
|||
|---|---|---|---|
|
#18+
Average version length: 41.84, total versions: 75366, max versions: 20017 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2017, 12:26 |
|
||
|
Время prepare запроса
|
|||
|---|---|---|---|
|
#18+
Gallemar, Постеснялся бы таким хвастаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2017, 16:49 |
|
||
|
Время prepare запроса
|
|||
|---|---|---|---|
|
#18+
WildSeryGallemar, Постеснялся бы таким хвастаться. Почему? Это же проблема не администрирования базы,а разработки системы и ее эксплуатации. Вечером пройдет регламентнвй sweep и статистика будет сброшена. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 00:14 |
|
||
|
Время prepare запроса
|
|||
|---|---|---|---|
|
#18+
Gallemar, сюда бы еще разницу Next-OAT, плюс из mon$transactions самую старую, сколько она живет. Впрочем, не думаю что тут будут какие-то открытия, потому что при интенсивности транзакций в этой системе цифры вполне нормальные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 00:40 |
|
||
|
Время prepare запроса
|
|||
|---|---|---|---|
|
#18+
kdv, позже скину,у нас шесть утра,я только глаза открыл.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 00:52 |
|
||
|
Время prepare запроса
|
|||
|---|---|---|---|
|
#18+
kdvGallemar, сюда бы еще разницу Next-OAT, плюс из mon$transactions самую старую, сколько она живет. Статистика за май в аттаче. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 07:31 |
|
||
|
Время prepare запроса
|
|||
|---|---|---|---|
|
#18+
GallemarkdvGallemar, сюда бы еще разницу Next-OAT, плюс из mon$transactions самую старую, сколько она живет. Статистика за май в аттаче. Взял на себя смелость отформатировать файл, разбить сутки подчеркиваниями, добавить колонку с Next-OAT . Без всего этого файл является не более чем сырым источником первичных данных. Вижу что практически ежедневно разрыв Next-OAT доходит до 1млн и более. Соответственно, практически ежедневно, за редким исключением, есть долгоиграющие транзакции которые держат версии. Отследить источник думаю достаточно просто - помониторить OT или OAT в течение дня, если она не меняется часа 3 - то через MON$-таблицы посмотреть что за транзакция и какой в ней запрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 08:22 |
|
||
|
Время prepare запроса
|
|||
|---|---|---|---|
|
#18+
fraksОтследить источник думаю достаточно просто - помониторить OT или OAT в течение дня, если она не меняется часа 3 - то через MON$-таблицы посмотреть что за транзакция и какой в ней запрос. В Mon$? Там только активные транзакции. Включен аудит, смотрим кто застревает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 08:54 |
|
||
|
Время prepare запроса
|
|||
|---|---|---|---|
|
#18+
GallemarfraksОтследить источник думаю достаточно просто - помониторить OT или OAT в течение дня, если она не меняется часа 3 - то через MON$-таблицы посмотреть что за транзакция и какой в ней запрос. В Mon$? Там только активные транзакции. Включен аудит, смотрим кто застревает. Так OAT это по твоему какие? Они у тебя и долгоиграют. Фишка в том что ты можешь заранее узнать какой номер транзакции тебя интересует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 09:29 |
|
||
|
Время prepare запроса
|
|||
|---|---|---|---|
|
#18+
Например транзация 40913795 провисела 09.05.2017 с 9 до 16 часов, т.е. более 7 часов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 09:31 |
|
||
|
Время prepare запроса
|
|||
|---|---|---|---|
|
#18+
Gallemar, со всем этим надо не сюда, а к разработчику идти. Например, какого фига 3 мая с 20 до 21 налетело под полтора миллиона транзакций, и при этом OAT застряло? Не вижу никаких проблем 3-4 раз в день снимать mon$attachments, mon$transactions и mon$statements и углядеть, что именно застревает. У нас для этого есть MonLogger. Чего-то трассировать на данном этапе не вижу смысла. Хотя, раз разработчик уже трассировал, значит софт будет исправлен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 13:35 |
|
||
|
Время prepare запроса
|
|||
|---|---|---|---|
|
#18+
Транзакции застревают в разное время,последнюю неделю больше ночью. Пока трассирую с минимальными настройками - коннекты и транзакции. Мой мониторинг умеет только счетчики транзакций фиксировать,для детального разбора надо переписывать. Monlogger у меня есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 14:27 |
|
||
|
Время prepare запроса
|
|||
|---|---|---|---|
|
#18+
Gallemar, Тр-ция 22 483 043, активна *сегодня* в 11-00 и в 12-00 - это ночью ??? У тебя каждый день есть застревание OAT на час-два-пять. В чём проблема найти её и приложение в таблицах мониторинга ? В чём проблема найти в аудите эту тр-цию и опять-же приложение ? Что ты вообще ищешь ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 14:37 |
|
||
|
Время prepare запроса
|
|||
|---|---|---|---|
|
#18+
Не ту колонку скопировал - об этой тр-ции речь выше : 22 540 698 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 14:38 |
|
||
|
Время prepare запроса
|
|||
|---|---|---|---|
|
#18+
fraksОтследить источник думаю достаточно просто - помониторить OT или OAT в течение дня, если она не меняется часа 3 - то через MON$-таблицы посмотреть что за транзакция и какой в ней запрос.Уточню - OIT искать нет смысла, это по-определению уже не активная тр-ция. Т.е. смотреть нужно на OAT. И активного запроса в ней может и не быть. Посмотреть нужно, но не стоит ожидать его там найти. Разве что там действительно какой-то фатальный мноночасовый запрос... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 14:44 |
|
||
|
Время prepare запроса
|
|||
|---|---|---|---|
|
#18+
Хотел бы поделиться своей идеей которая облегчает поиск источника проблем. После того как глядя на текст запросов в мониторинге пытался отпределить в каком месте приложения этот запрос вызывается, принял для себя стандарт шапки запроса, первой строкой пишется имя формы/модуля, имя компонента с запросом. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. Теперь видя запрос в таблицах мониторинга сразу понятно откуда он вызывается, а в пределах модуля/формы уже проще найти как он употребляется и что там с транзакцией. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 04:05 |
|
||
|
Время prepare запроса
|
|||
|---|---|---|---|
|
#18+
ОФФ fraks> Хотел бы поделиться своей идеей которая облегчает поиск источника проблем. Идея интересная, но если уж взял за правило - не проще ли было бы просто запросы "проинвентаризировать"? Я такое делал разок, но только для "важных", не всех. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 06:56 |
|
||
|
Время prepare запроса
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов РустамОФФ fraks> Хотел бы поделиться своей идеей которая облегчает поиск источника проблем. Идея интересная, но если уж взял за правило - не проще ли было бы просто запросы "проинвентаризировать"? Что ты имеешь ввиду под "проинвентаризировать"? У меня в приложении 180 форм, в большинстве из них по 2-15 запросов. Проблему с зависающими транзакциями я решил, но до сих пор встречаются формы где запросы не отформатированы по моему стандарту. Помню что когда-то у FIB-ов была приблуда для централизованно посмотреть запросы по всем формам. Но тогда она мне была не нужна а сейчас не вижу ее. Да и пес с ней. При маневрах с компонентами буду мигрировать на UIB - там как раз тот минимуум что я использую, и UIB есть под Lazarus. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 08:21 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=39462852&tid=1561559]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
66ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
| others: | 13ms |
| total: | 181ms |

| 0 / 0 |
