Определение времени отклика, данное Международной организацией по стандартизации ISO, несмотря на простоту, достаточно полезно:

Время отклика - это полное время, прошедшее с момента завершения за­проса или команды компьютерной системе до начала ответа; например, пе­риод времени между событием окончания запроса и появлением первого символа ответа на терминале пользователя (взято на http://searchnetwork-ing.techtarget.com/sDefinition/0,,sid7_gci212896,00.htmr).

Время отклика представляет собой объективную меру взаимодействия между поставщиком и потребителем. Потребители компьютерных услуг хотят получать правильный ответ за наименьшее время и с наименьши­ми затратами. Цель аналитика по производительности Oracle заключа­ется в минимизации времени отклика в рамках экономических ограни­чений, наложенных владельцем системы. Если разложить время откли­ка на компоненты, то станет понятнее, каким путем этого достичь.

Диаграмма последовательности

Диаграмма последовательности - это удобный способ изображения составляющих времени отклика для действий пользователя. Диаграм­ма показывает передачу управления между уровнями технологическо­го стека в процессе выполнения пользовательской операции. Техноло­гический стек служит для представления многоуровневой архитекту­ры, образованной всеми элементами системы: пользователями, сетью, прикладными программами, ядром базы данных и оборудованием. Все элементы стека получают услуги от элементов нижележащего уровня и предоставляют услуги элементам, расположенным уровнем выше. На рис. 1.1 показана диаграмма последовательности для много­уровневой Oracle-системы.

Рис. 1.1 иллюстрирует приведенную ниже последовательность дейст­вий, наглядно показывая вклад каждого из уровней технологического стека в общее время отклика:

Пользователь, решив, что он хочет получить от системы, иницииру­ет запрос на получение данных, нажимая в броузере кнопку «OK». Практически мгновенно броузер принимает этот запрос. Ожидание пользователем ответа начинается с нажатия кнопки «OK».

Броузер, затратив несколько мгновений на формирование изобра­жения кнопки в прежнем, не нажатом состоянии, посылает HTTP-пакет в глобальную сеть (WAN). Некоторое время спустя запрос, пройдя по глобальной сети, достигает сервера приложений.

Сервер приложений, выполнив некоторые прикладные операции промежуточного уровня, формирует запрос к базе данных и отправ­ляет его по протоколу SQL*Net в локальную сеть (LAN). Запрос за некоторое время (быстрее, чем в глобальной сети) проходит по ло­кальной сети и поступает на сервер базы данных.

Процессор сервера БД выполняет ряд вычислений, и ядро Oracle формирует системный вызов с запросом на чтение с диска.

Через некоторое время системный вызов заканчивает чтение и воз­вращает управление процессу сервера БД.

Выполнив еще ряд вычислений на сервере, ядро Oracle формирует еще один вызов на чтение.

Затратив еще некоторое время на выполнение дисковых операций, системный вызов снова возвращает управление процессу сервера БД.

Ядро Oracle, затратив немного процессорного времени на завер­шающую обработку, формирует ответ на запрос сервера приложе­ний и отправляет его по протоколу SQL*Net в локальную сеть.

Сервер приложений преобразует полученные из базы данных ре­зультаты в формат HTML и отправляет их по глобальной сети бро­узеру по протоколу HTTP.

10. После отображения результатов на дисплее пользователя броузер возвращает управление пользователю. Получив запрошенную ин­формацию, пользователь заканчивает ожидание, длившееся в тече­ние времени отклика.

На мой взгляд, идеальное средство анализа производительности Oracle еще не создано. Такой идеальный инструмент анализа должен иметь графический интерфейс для представления диаграммы последова­тельности, с точностью до микросекунды показывающей распределе­ние составляющих времени отклика для любого действия пользовате­ля. Большой объем данных, обрабатываемых таким приложением, по­требует наличия развитых средств для обобщения и детализации, что­бы представить информацию именно так, как это требуется.

Вероятно, такое приложение скоро появится. Как вы увидите из этой книги, ядро Oracle уже может предоставить значительную часть дан­ных, необходимых для создания такой программы. Основными про­блемами на нынешний момент являются:

Отсутствие в большинстве узлов многоуровневой системы средств представления данных о времени отклика, аналогичных тем, кото­рые предоставляет ядро Oracle. О каких данных идет речь, уточня­ется в главе 7.

В некоторых архитектурах трудность сбора диагностических дан­ных, относящихся к конкретным пользовательским операциям. В главе 3 рассматриваются требования к представлению диагностических данных, а в главе 6 объясняется, как обойти трудности сбо­ра данных, возникающие в различных прикладных архитектурах.

Однако многое из того, что нам необходимо, уже существует. Начиная с версии Oracle 7.0.12, в ядро включена и развивается поддержка средств измерения времени отклика. Эта книга поможет вам разо­браться в том, как преимущества данного инструментария могут быть использованы в деле повышения производительности систем Oracle.

Профиль ресурсов

Полная диаграмма последовательности для любого мало-мальски слож­ного пользовательского действия содержит так много данных, что это заметно осложняет работу с ними. Следовательно, соображения удоб­ства диктуют необходимость каким-то образом обобщить эту информа­цию. В примере 1.2 в качестве такого обобщения показан профиль ре­сурсов. Профиль ресурсов - это просто таблица, содержащая удобное представление структуры времени отклика. Обычно профиль ресурсов содержит, как минимум, следующие атрибуты:

Категория операций

Суммарное время выполнения операций данной категории

Количество обращений к операциям данной категории

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

Идея применения профилей ресурсов далеко не нова. Наша компания вдохновилась ей благодаря статье о программах-профилировщиках, опубликованной в 1980-х годах [Bentley (1988) 3-13] и основанной, в свою очередь, на работе Дональда Кнута, вышедшей в начале 1970-х [Knuth (1971)]. Идея разложения времени отклика на составляющие настолько практична, что вы наверняка эксплуатировали ее, даже не сознавая того. Вспомните, как вы оптимизируете маршрут в свое любимое место. Представьте себе тот «райский уголок», в котором вы все­гда чувствуете прилив сил. Для меня это ближайший магазин «Wood-craft Supply» (http://www.woodcraft.com), где продаются не только все­возможные инструменты, способные отрезать пальцы и ломать ребра, но и книги и журналы, объясняющие, как этого избежать.

Вот как может выглядеть профиль ресурсов для путешествия по горо­ду с оживленным движением в час пик (время выражено в минутах):

Если, предположим, до магазина всего пятнадцать миль, вам, вероят­но, не очень понравится перспектива полуторачасового стояния в проб­ках. Независимо от того, мыслите вы категориями профилей ресурсов или нет, вы скорее всего придете к тому же способу оптимизации, что и я: пожалуй, лучше отправиться в магазин, когда движение станет менее интенсивным.

Профили ресурсов помогают однозначно поставить задачу для проекта повышения производительности Oracle. В примере 1.3 представлен про­филь ресурсов программы формирования платежной ведомости, рас­смотренной ранее в разделе «Концентрация на пользовательских опера­циях». Не имея такого профиля, администраторы БД три месяца би­лись над известной им проблемой конкуренции за защелки. Придя в отчаяние, они потратили несколько тысяч долларов на новый про­цессорный блок, что привело к замедлению выполнения операции, ко­торую они пытались ускорить. Получив в свое распоряжение профиль ресурсов, администратор в течение десяти минут нашел решение, со­кращающее время отклика примерно на 50%. Более подробно эта про­блема и ее решение рассмотрены в третьей части книги.

Response Time Component	Duration		# Calls	Dur/Call
SQL*Net message from client	984.0s	49.6%	95,161	0.010340s
SQL*Net more data from client	418.8s	21.1%	3,345	0.125208s
db file sequential read	279.3s	14.1%	45,084	0.006196s
CPU service	248.7s	12.5%	222,760	0.001116s
unaccounted-for	27.9s	1.4%
latch free	23.7s	1.2%	34,695	0.000683s
log file sync	1.1s	0.1%	506	0.002154s
SQL*Net more data to client	0.8s	0.0%	15,982	0.000052s
log file switch completion	0.3s	0.0%	3	0.093333s
enqueue	0.3s	0.0%	106	0.002358s
SQL*Net message to client	0.2s	0.0%	95,161	0.000003s
buffer busy waits	0.2s	0.0%	67	0.003284s
db file scattered read	0.0s	0.0%	2	0.005000s
SQL*Net break/reset to client	0.0s	0.0%	2	0.000000s
Total	1,985.4s	100.0%

Пример 1.4 демонстрирует еще один профиль ресурсов, спасший про­ект от обескураживающего и дорогостоящего провала. До появления этого профиля предполагаемое решение проблемы формирования от­чета заключалось в увеличении объема памяти или модернизации под­системы ввода/вывода. Профиль ресурсов однозначно показал, что данные мероприятия если и улучшат время отклика, то не более чем на 2%. Практически все время уходило на выполнение единственной команды SQL, вызывавшей около миллиарда обращений к блокам бу­ферного кэша БД.

Подобные проблемы обычно бывают вызваны ошибками в обслужива­нии, например, случайным удалением статистики, используемой опти­мизатором по стоимости (Cost-Based Optimizer - CBO).

Время отклика Component	Duration		# Calls	Dur/Call
CPU service	48,946.7s	98.0%	192,072	0.254835s
db file sequential read	940.1s	2.0%	507,385	0.001853s
SQL*Net message from client	60.9s	0.0%	191,609	0.000318s
latch free	2.2s	0.0%	171	0.012690s
other	1.4s	0.0%
Total	49,951.3s	100.0%

П р имер 1.4 ясно показывает, как профиль ресурсов помогает не стать жертвой мифов. Здесь в качестве расхожего заблуждения, дезориенти­ровавшего аналитика относительно причин задержек в сеансе, высту­пает утверждение о том, что высокий коэффициент попаданий в кэш буферов базы данных свидетельствует об эффективности выполнения команд SQL. Команда, вызывавшая замедление работы, показывала исключительно высокий коэффициент попаданий в кэш буферов. При­чину легко понять, взглянув на формулу вычисления коэффициента попадания CHR (cache hit ratio) для данного случая:

В   этой формуле логический ввод/вывод LIO (logical I/O)- это количе­ство блоков, считанных из памяти Oracle (кэша буферов БД); физиче­ский ввод/вывод PIO (physical I/O) - количество блоков, считанных вызовами операционной системы.1 

Эта формула порождает и другие проблемы, помимо показанной в данном примере. Многие авторы, включая Адамса (Adams), Льюиса (Lewis), Кайта (Kyte) и меня самого, указывают на многочисленные и серьезные изъяны такого способа представления коэффициента попаданий в кэш буферов. Наиболее подробно это вопрос рассмотрен в работе [Lewis (2003)].

ния (LIO - PIO) равно количеству чтений блоков из кэша, не потребо­вавших обращений к операционной системе.1

Несмотря на то, что многие специалисты сочли бы значение коэффици­ента 0,9995 «хорошим», оно все же не может считаться «идеальным». В отсутствие данных, представленных в примере 1.4, большинство из­вестных мне аналитиков предположили бы, что низкая производитель­ность вызвана неидеальностью коэффициента попаданий в кэш. Но про­филь ресурсов ясно показывает, что даже если бы все 507385 операций физического чтения были обслужены кэшем буферов, экономия вре­мени составила бы только 940,1 секунды. Максимально возможное улучшение от решения этой «проблемы» составило бы лишь 16 минут при общей продолжительности выполнения 14 часов.

Применение профилей ресурсов для анализа пользовательских опера­ций радикально повысило эффективность работы специалистов по производительности. Прежде всего это превосходный инструмент для определения наиболее важной точки приложения усилий - в соответ­ствии с провозглашенной нами целью:

Пример 1.4 заставляет меня вспомнить первый пройденный мной курс по «настройке». Это было в 1989 г., когда я только пришел на работу в корпорацию Oracle. Наш преподаватель предложил простой способ оп­тимизации запросов к базе данных Oracle: просто исключить операции физического ввода/вывода. Я задал вопрос: «А как насчет доступа к па­мяти?», имея в виду большое значение в столбце query выходных дан­ных tkprof, которые мы в этот момент изучали. Инструктор ответил, что выборка из памяти выполняется настолько быстро, что ее влиянием на производительность можно пренебречь. Такой ответ меня разочаро­вал - до того, как начать карьеру в Oracle, я много занимался оптимиза­цией кода на C. Одним из наиболее важных моментов в этой работе было исключение избыточных обращений к памяти [Dowd (1993)].

Из примера 1.4 видно, почему и для вас устранение излишних обраще­ний к памяти должно стать приоритетным. Лишние обращения к памя­ти увеличивают время отклика. Если таких обращений много, то расхо­дуется много времени. При частоте процессора 2 ГГц выполнение кода, реализующего операцию логического ввода/вывода Oracle (LIO), зани­мает, как правило, несколько десятков микросекунд процессорного вре­мени в пользовательском режиме. Следовательно, миллион операций LIO увеличат время отклика на несколько десятков секунд. Чрезмерная интенсивность операций LIO, в силу ряда причин, затрудняет масшта­бируемость системы; причины рассмотрены во второй и третьей частях книги. Дополнительная информация имеется в работе [Millsap (2001c)].

В первую очередь стремиться к уменьшению самой значимой составляю­щей времени отклика в наиболее критичных для бизнеса операциях.

Другое важное преимущество использования профилей ресурсов за­ключается в том, что от них не может укрыться практически ни одна проблема производительности. Неформальное доказательство этой ги­потезы состоит из двух утверждений:

Доказательство: Если нечто представляет собой проблему со временем от­клика, это проявляется в профиле ресурсов. Если это не проблема со време­нем отклика, то это и не проблема производительности. ЧТД

О создании таких профилей ресурсов, от которых не укроется ни одна проблема производительности, рассказывается во второй части книги.