Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
частота сбора статистики
|
|||
|---|---|---|---|
|
#18+
Вопрос вот в чем. Есть база: справочники, нормализованные таблицы фактов и, на их основе, денормализованные MQT с индексами. Есть процедура (в которую встроена некая бизнес-логика) формирующая и выполняющая динамический запрос из MQT. Процедура создана, MQT наполнены, статистика по индексам создана, процедура запущена, refresh age=any. Работает хорошо. Через некоторое время (несколько часов), при том что ни одна (!) таблица в базе не обновлялась, процедура начинает работать медленнее. Через несколько суток время работы увеличивается с 0.7 сек до 7-10 сек... После сбора статистики опять все работает замечательно. Включил автоматический сбор статистики по ночам, но и это оказалось редко - к середине дня все начинает ощутимо тормозить. Помогите разобраться, в чем проблема. Не верю, что нужно так часто собирать статистику для редко меняющейся таблицы, чтобы запрос работал с постоянной нормальной скоростью. (Версия DB2 9.1, Gentoo, kernel 2.6.x) Заранее спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2008, 00:42 |
|
||
|
частота сбора статистики
|
|||
|---|---|---|---|
|
#18+
А план-то меняется? И что именно в нем меняется? Может, запрос начинает тормозить, потому что сбор статистики считывает что-нибудь большое (например, MQT) в буфер, а с течением времени другие запросы выбивают большую часть страниц MQT из буфера и процедура должна их считывать заново? Как себя диски ведут в том и другом случае? Что снапшоты показывают? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2008, 01:21 |
|
||
|
частота сбора статистики
|
|||
|---|---|---|---|
|
#18+
Не-а, план не меняется. Исследовал на нескольких запросах - везде происходит одно и то же. Для теста переписал этот кусок на статические таблицы и запросы (в процедуре) вместо динамических запросов к MQT. Результат тот же... Диски? а что диски? жужжат, top показывает небольшой всплеск, а нагрузка больше на проц падает. Какие именно снапшоты интересуют? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2008, 21:09 |
|
||
|
частота сбора статистики
|
|||
|---|---|---|---|
|
#18+
Думаю, для начала надо смотреть, как в течение дня меняются: bufferpool hit ratio (отношение physical reads к logical) количество сортировок, в т.ч. sort overflows ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2008, 21:21 |
|
||
|
частота сбора статистики
|
|||
|---|---|---|---|
|
#18+
По сортировкам ничего интересного не увидел. А вот по буферпулам пронаблюдал следующее: после сбора статистики начинаю активно бродить по разделу сайта = создавать множество запросов. У буферпулов hit ratio получаю 90-99%. По прошествии некоторого времени начинаю снова запускать эти запросы - попадание 60-80%, но буквально через несколько минут возрастает до прежних 90-99%, при этом скорость реально повышается. Сделал вывод, что действительно нужные страницы выбиваются из буферпулов другими запросами, при этом начинается большее обращение к диску. Видимо, недостаточная активность данного типа запросов (на базе основан портал, проходящий тестирование) порождает данные проблемы. Должны ли они (проблемы производительности) уйти при постоянных однородных нагрузках (прошу не гарантий, а мнения :)) и можно ли их избежать уже сейчас? ЗЫ. Пробовал настраивать размер буферпулов, изменений не увидел и оставил автонастройку. Может, что-то не докрутил в этой стороне? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2008, 11:58 |
|
||
|
|

start [/forum/topic.php?fid=43&msg=35584489&tid=1603634]: |
0ms |
get settings: |
6ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
64ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 214ms |
| total: | 378ms |

| 0 / 0 |
