бласть данных
Хорошая методика сбора данных о производительности Oracle требует соответствующих методик принятия решений в двух измерениях. Необходимо получить данные в правильной временной области и в правильной области операций. Начнем с построения диаграммы, показывающей структуру времени отклика в виде последовательности временных промежутков, соответствующих потреблению различных ресурсов. Результат показан на рис. 3.2. Для простоты будем считать, что наша воображаемая система состоит из ресурсов трех видов, обозначенных C, D и S. Пусть это будут процессор, диск и некий ресурс с последовательным доступом (как, например, ядро Oracle, предоставляющее последовательный доступ блокировкам, защелками и определенным операциям с буферами памяти). На рис. 3.2 ось времени расположена горизонтально.
Рис. 3.2. Распределение времени между ресурсами в ходе выполнения пользовательской операции
Аналогично можно изобразить систему, выполняющую несколько пользовательских операций одновременно, поместив такие диаграммы одну под другой, как это показано на рис. 3.3. На этой диаграмме ось пользовательских операций расположена вертикально.
В следующих разделах данный способ представления помогает объяснить, почему методы сбора данных, практикуемые многими экспертами по Oracle с 1980-х годов, лишь губят проекты повышения производительности Oracle по всему миру.
Представьте, что в системе, изображенной на рис. 3.3, процесс выбора пользовательских операций, описанный в главе 2, показал следующее: наибольшая проблема производительности для бизнеса заключается в том, что для пользователя Уоллеса время отклика (между моментами t1 и t2) недопустимо велико (рис. 3.4).
В последующем обсуждении будем использовать математическое обозначение для закрытого интервала. Обозначение [a, b] соответствует множеству значений, заключенному между a и b
,
включая их:[a, b] = {все значения x, для которых a < x < b}
Из рис. 3.4 легко видеть, что на проблемном интервале большая часть времени потребляется ресурсом S, а оставшаяся - ресурсом C (табл. 3.1). Понятно, что решение проблемы производительности для Уоллеса требует уменьшения времени, потребляемого ресурсом S, или C, или ими обоими. Закон Амдала говорит, что эффект от сокращения потребления ресурса S будет в 1,5 раза выше, чем от ресурса C вследствие того, что доля S во времени отклика в 1,5 раза больше доли C.
Таблица 3.1. Профиль ресурсов для операции пользователя Уоллеса в интервале [t1, t2]
Ресурс
|
Время использования
|
Доля в общем времени
|
S C
Всего
|
3 2 5
|
60,0% 40,0% 100,0%
|
Пожалуй, самая распространенная ошибка в получении данных - это сбор данных, агрегированных по обоим измерениям. Рис. 3.5 иллюстрирует эту ошибку. Толстая черная линия, охватывающая все блоки диаграммы, показывает, что были получены общие данные по всем процессам (не только для Уоллеса) и во всем временном интервале [t0, t3] (не только для [t1, t2]). Подсчет составляющих времени для всей системы в интервале [t0, t3] дает профиль ресурсов, приведенный в табл. 3.2. Как видите, проблема пользователя Уоллеса, которая, как нам известно, заключается в слишком больших временных затратах на выполнение операции S, оказалась погребенной под кучей не относящихся к делу данных. Результатом небрежности, допущенной при сборе данных, будет задержка в выполнении проекта повышения производительности и, возможно, его меньшая результативность.
Рис. 3.5. Сбор данных в неверно определенной по обоим измерениям области полностью скрывает источник проблемы пользователя Уоллеса на интервале [tl,
На основании данных табл. 3.2 невозможно сделать вывод о том, что проблема пользователя Уоллеса связана с расходованием ресурса S. Более того, предположение о том, что проблема Уоллеса заключается в ресурсе S, было бы безответственным.
К сожалению, разобранный здесь порочный метод сбора данных применяется по умолчанию пакетом Statspack, парой сценариев utlbstat.sql и utlestat.sql, а также практически всеми инструментами исследования производительности Oracle, созданными между 1980 и 2000 годами. Во всех наиболее провальных проектах повышения производительности, в которых мне довелось участвовать, основной причиной неудачи чаще всего был именно такой способ сбора данных.
Решение описанной проблемы требует корректировки сбора данных по обоим измерениям. Недостаточно исправить ошибку в одном измерении. Посмотрите, например, на результаты сбора данных, показанные на рис. 3.6. Здесь временная область выбрана правильно, но область операций все еще слишком велика. Соответствующий профиль ресурсов приведен в табл. 3.3. Не забывайте, вам известна истинная причина проблем пользователя Уоллеса, и она заключается в ресурсах S и C. Но данные, полученные для системы в целом, недвусмысленно «свидетельствуют» об обратном, несмотря на то, что были собраны в правильном временном интервале.
Наконец, рассмотрим результаты сбора данных в правильной области операций, но в неправильной временной области, как показано на рис. 3.7. В табл. 3.4 приведен соответствующий профиль ресурсов. И здесь даже опытный специалист по производительности, основываясь на представленных данных, не справится с задачей диагностики. Проблема пользователя Уоллеса связана с ресурсами S и C, но данные табл. 3.4 не позволяют сделать такой вывод.
Таблица 3.3. Профиль ресурсов системы в целом на интервале [t1, t2]
Ресурс
|
Время использования
|
Доля в общем времени
|
D
C S
Всего
|
23 9
3
35
|
65,7%
25,7%
8,6% 100,0%
|
Таблица 3.4. Профиль ресурсов операции пользователя Уоллеса на интервале
[t0, t3]
Ресурс
|
Время использования
|
Доля в общем времени
|
D
C S
Всего
|
8 8
4
20
|
40,0%
40,0%
20,0% 100,0%
|
На основании этих простых примеров хорошо видно, почему правильная организация сбора диагностических данных жизненно важна для проекта повышения производительности. Примеры также раскрывают равнозначность двух измерений, на основании которых можно судить о применимости имеющихся диагностических данных:
Целесообразно ли накапливать диагностические данные производительности на всем протяжении пользовательской операции, которая выполняется действительно долго? К примеру, операция, выполнявшаяся на прошлой неделе за десять минут, сегодня висит уже четвертый час, и вы подумываете, не пора ли ее отменить. Надо ли перезапускать задание для получения диагностики? Мне приходилось слышать о пакетных заданиях, выполнявшихся по несколько дней, прежде чем потерявшие терпение пользователи снимали их.1 Действительно ли необходимо собирать диагностические данные для всего задания целиком?
Ответ - нет. Конечно, сбор диагностики лишь на части проблемного интервала представляется нарушением правила выбора временной области, но в некоторых обстоятельствах такие данные могут быть действительно полезными. Например:
Если пользовательская операция должна выполняться за n минут, то данные, собранные в течение n+m минут, будут содержать не относящуюся к делу информацию как минимум за m минут. Например, если предполагается, что задание выполнится за 10 минут, данные, собранные в течение 25 минут будут содержать не менее 15 минут не относящейся к рассматриваемой операции нагрузки.
Если пользовательская операция состоит из последовательности повторяющихся действий, диагностические данные, полученные только для нескольких из них, дадут представление о расходах ресурсов для всей операции благодаря ее однородности.2
В главе 6 обсуждаются некоторые ошибки, которые могут возникнуть в случае начала процесса сбора данных в середине операции над базой данных. Но во многих случаях сбор данных на частичных интервалах может оказаться весьма полезным.
В некоторых из этих случаев я мог бы представить доказательства того, что всей нашей жизни не хватило бы на то, чтобы дождаться окончания выполнения заданий.
Хотя в этом разделе речь идет о допустимости или недопустимости сужения временной области, первый пример возвращает нас к вопросу о расширении временной области. Он напоминает, что расширение временной области сбора диагностических данных - это явная ошибка, нарушение правила выбора временной области, последствия которого описаны выше. Второй же пример показывает, что сужение временной области вполне допустимо в некоторых случаях. По-видимому, эти примеры должны противопоставляться друг другу, хотя явно автор этого не делает. - Примеч. науч. ред.
Может показаться, что проблемы с данными, приведенными в табл. 3.2, 3.3 и 3.4, возникли из-за того, что было собрано «слишком много дан
ных». Однако дело не в том, какие данные были собраны, а в том, как они были агрегированы. Посмотрите еще раз на рис. 3.5. Здесь вполне достаточно информации для построения профиля ресурсов в правильной области. Проблема с данными в табл. 3.2 возникла вследствие неправильного обобщения данных из рис. 3.5. То же можно сказать и о рис. 3.6, 3.7 и соответствующих им профилях ресурсов. Дело не в избытке данных, а в том, что они некорректно агрегированы в профилях ресурсов.
Неправильное агрегирование данных особенно сильно сказывается на проектах, в которых в качестве источника диагностических данных выступают запросы к фиксированным представлениям Oracle V$. Эти представления по природе своей способны предоставить только совокупные данные либо для экземпляра с момента его запуска, либо для сеанса с момента установки соединения. Например, используя представления V$SYSSTAT или V$SYSTEM_EVENT, вы гарантированно получите ошибки в представлении данных, аналогичные показанным в табл. 3.2 и 3.3. Как бы аккуратно вы ни применяли V$SESSTAT и V$SESSION_EVENT, вы не избежите ошибок в определении временного интервала, проиллюстрированных данными в табл. 3.4 (в этом можно убедиться, поэкспериментировав с программой vproof из главы 8).
При должном внимании к временной области данных представления V$SESSTAT и V$SESSION_EVENT могут дать общее представление о причинах задержек при выполнении пользовательских операций. Однако в них отсутствуют данные, необходимые для более детального анализа. Как быть, если, к примеру, предварительный анализ показал, что рассматриваемая операция большую часть времени проводит в ожидании события освобождения блокировки latch free? Тут потребуются данные из V$LATCH (и возможно, V$LATCH_CHILDREN) за тот же период времени. Но, получив их, вы заметите, что ни в одном из представлений нет идентификатора сеанса, в силу чего сбор информации о защелках в корректной области операций оказывается невозможным.
Невозможность получения подробных данных из представлений V$ представляет собой серьезную проблему. И корень зла отнюдь не в представлении V$LATCH. Что, если бы большую часть времени занимало использование ЦПУ? Тогда вам понадобились бы данные, как минимум, из представления V$SQL для заданной операции в определенном интервале времени. А если бы время уходило на ожидание db file scattered read? Тогда потребовались бы аналогичные данные из V$FILESTAT. А если проблема в ожидании buffer busy waits? Тогда надо обратиться к V$WAITSTAT. В Oracle9i имеется около 300 событий, требующих для анализа подробных данных из нескольких десятков представлений V$. Даже если бы вам удалось получить из них данные для строго определенных моментов времени (в правильной временной области), вы все равно получите агрегированные значения, страдающие отсутствием детализации, которую можно получить из других источников.
К счастью, есть как минимум три пути получения нужных нам подробных данных. Первый не очень хорош. Второй обойдется дорого, но у вас, возможно, уже есть все необходимое. Третий доступен по цене книги, которую вы держите в руках. Подробности - в следующем разделе.
< Предыдущая | Следующая > |
---|