Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 производительность(задача)  [new]
dimakz
Member

Откуда:
Сообщений: 1574
такая задачка, хочу посм. вр.отклика:

Время отклика = Время обслуживания + Время ожидания  
(Response Time = Service Time + Wait Time)
вот скрипт:
select a.value+b.e "Responce Time", a.value "Total CPU time", b.e "Total Wait Time", b.e*100/(a.value+b.e) dola from
(select  value --"Total CPU time"
from v$sysstat where  name = 'CPU used by this session' ) a,
(select sum(time_waited) e-- "Total Wait Time"
from v$system_event where event not in ('pmon timer', 'smon timer', 'rdbms ipc
message', 'parallel dequeue wait', 'virtual circuit', 'SQL*Net
message from client', 'client message', 'NULL event')) b

т.е.вр.ожидания составляет 98% или наоборот - 2% ?
29 янв 08, 10:27    [5214471]     Ответить | Цитировать Сообщить модератору
 Re: производительность(задача)  [new]
dimakz
Member

Откуда:
Сообщений: 1574
теперь хочу посмотреть,
как потребляет ЦПУ наша БД. Для этого рассчитаем компонент прочее ЦПУ (CPU other) по формуле:
Прочее ЦПУ = Время отклика – Время разбора предложений – Время рекурсивных запросов
(CPU other = CPU used by this session – Parse time CPU – Recursive CPU)

скрипт
select a.value "Total CPU",
b.value "Parse CPU",
c.value "Recursive CPU",
a.value - b.value - c.value "Other",
(a.value - b.value - c.value)/c.value dola
from v$sysstat a, v$sysstat b, v$sysstat c
where a.name = 'CPU used by this session'
and b.name = 'parse time cpu'
and c.name = 'recursive cpu usage';
Total CPU Parse CPU Recursive CPU Other
1247878341 60612258 178974883 1008291200

а высокий процент отношения Прочее ЦПУ/Время отклика говорит о наличии неэффективных SQL, просматривающих слишком много блоков в кэше СУБД – т.е. совершающих логические чтения., в данный момент это составляет 5.6 , а в процентном соотношении будет 0.056% , так?
29 янв 08, 10:58    [5214695]     Ответить | Цитировать Сообщить модератору
 Re: производительность(задача)  [new]
dimakz
Member

Откуда:
Сообщений: 1574
теперь хочу посмотреть,
как потребляет ЦПУ наша БД. Для этого рассчитаем компонент прочее ЦПУ (CPU other) по формуле:
Прочее ЦПУ = Время отклика – Время разбора предложений – Время рекурсивных запросов
(CPU other = CPU used by this session – Parse time CPU – Recursive CPU)

скрипт
select a.value "Total CPU",
b.value "Parse CPU",
c.value "Recursive CPU",
a.value - b.value - c.value "Other",
(a.value - b.value - c.value)/c.value dola
from v$sysstat a, v$sysstat b, v$sysstat c
where a.name = 'CPU used by this session'
and b.name = 'parse time cpu'
and c.name = 'recursive cpu usage';
Total CPU Parse CPU Recursive CPU Other
1247878341 60612258 178974883 1008291200

а высокий процент отношения Прочее ЦПУ/Время отклика говорит о наличии неэффективных SQL, просматривающих слишком много блоков в кэше СУБД – т.е. совершающих логические чтения., в данный момент это составляет 5.6 , а в процентном соотношении будет 0.056% , так?
29 янв 08, 11:00    [5214712]     Ответить | Цитировать Сообщить модератору
 Re: производительность(задача)  [new]
dimakz
Member

Откуда:
Сообщений: 1574
никто не знает?
29 янв 08, 12:39    [5215455]     Ответить | Цитировать Сообщить модератору
 Re: производительность(задача)  [new]
evgenyg
Member

Откуда:
Сообщений: 355
Пожалуй начните здесь читать.
Craig Shallahamer, “Response Time Analysis For Oracle Based Systems”
Мне нравится его изложение.
Ну и почти основоположники:
Anjo Kolk, Shari Yamaguchi, Jim Viscusi, “Yet Another Performance Profiling Method (or YAPP)”, Oracle corporation, June 1999.
А потом задавайте вопросы.
29 янв 08, 13:10    [5215705]     Ответить | Цитировать Сообщить модератору
 Re: производительность(задача)  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
dimakz
никто не знает?

Это все не о чем.

dimakz
т.е.вр.ожидания составляет 98% или наоборот - 2% ?

Во вторых, ты не показал результатов запроса, поэтому очень странно спрашивать 98 или 2 там, где нет вообще ничего. А во первых время ожидания в рамках всей системы вещь очень сомнительная в принципе, ресурс ожидания не ограничен, допустим кто-то минуту держит блокировку, если его ждут 10 сессий получим 10 минут ожидания, будет 100 сессий 100 минут ожидания и о чем говорит минуту ждали или 100 минут? Существенно эта минута для тех 100 сессий или нет? Да по разному может если ожидаемое время лтклика тех 100 сессий 10 сек, то это проблема, а если они сутки работают, то и незаметно.

dimakz

а высокий процент отношения Прочее ЦПУ/Время отклика говорит о наличии неэффективных SQL, просматривающих слишком много блоков в кэше СУБД – т.е. совершающих логические чтения., в данный момент это составляет 5.6 , а в процентном соотношении будет 0.056% , так?
Ни о чем он не говорит, в принципе может говорить как о наличии неэффективных SQL, так и об эффективной работе системы, как о излишне потребляющем cpu хранимом коде, так и об эфективных алгоритмах и методах не приводящих к ожиданиям, лишним рекурсивным вызовам и.т.д. Тяжело вытощить из данных о системе вцелом конкретику, она там тонет, в лучшем случае данные для анализа могут дать изменения этих характеристик по времени.
Да и в запросе считается не "отношение Прочее ЦПУ/Время отклика", а отношение "Прочее ЦПУ/non-user cpu (recursive)" , и 5.6 тут получается 560%, т.е. время непосредственно на пользовательские вызовы без времени парсинга (а почему без? чем провинилось?) в шерсть раз больше чем время на служебные recursive вызовы (а почему тогда парсинг сюда не добавлен, это получается ведь тоже тогда своеобразное время на организацию и обслуживание вызова, а не на непосредствавенное выполнение). Гипотетически, чем больше это соотношение тем лучше, т.е. меньше CPU тратится на организацию работы вызовов и большее на непосредственно на полезную работу пользовательских вызовов.


Статья Craig Shallahamer интересна с точки зрения общего подхода измерения времени отклика и понимания его компонент. Когда он начинает рассматривать примеры на основе измерений времени отклика в целом по системе то как я и говорил источником информации оказывается историческое изменение показателей (5.4 Историчный контекст системы )
или требуется переход к анализу на уровне сессии - "Следующий шаг – выполнить классический анализ на основе событий ожидания сессии" (5.3 Интерактивный контекст системы, случай 2).
Но Craig Shallahamer даже в контексе статистики в целом по системе не сосредотачивается на конкретных коэфициентах, а рассматриваети профиль ожиданий и долю отдельных груп ожиданий и соотношение ожиданий и времени cpu.
29 янв 08, 13:33    [5215846]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить