DeepEdit!

Я начал предисловие так:

Задача оптимизации времени отклика в Oracle, по большей части, решена.

Это утверждение полностью противоречит мрачной картине, нарисо­ванной мною в начале этой главы: «Производительность Oracle для многих представляет серьезную проблему». Такое противоречие тре­бует логичного объяснения. Вот оно:

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

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

Концентрация на пользовательских операциях

Первое важное правило оптимизации Oracle следует из элементарного правила математики:

По агрегированным данным нельзя восстановить составляющие.

Поясню это на таком примере. Предположим, я говорю вам, что среди 1000 камней 999 серых и один особенный, покрашенный в красный цвет. Все камни весят 1000 фунтов. Теперь скажите, сколько весит красный камень? Сказав, что знаете, что красный камень весит один фунт», вы, осознавая это или нет, не дадите правильный ответ. Неиз­вестно, весит ли красный камень один фунт. Основываясь на предос­тавленной информации, нельзя это знать. Ответив: «Я предполагаю, что красный камень весит один фунт», вы сделаете слишком самона­деянное предположение, рискуя придти к ошибочным, возможно, ка­тастрофически ошибочным выводам.

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

Это одна из причин, по которым специалисты по Oracle так не любят диагностировать проблемы производительности, основываясь на дан­ных общесистемной статистики, вроде той, что предоставляет Stats-pack (или его ближайшие родственники, произошедшие от старых SQL-сценариев bstat и estat). Два аналитика, глядя на одни и те же ре­зультаты работы Statspack, могут сделать совершенно разные выводы, причем ни один из них полностью не подтверждается и не опроверга­ется представленными данными. Это не ошибка Statspack. Это прин­ципиальный недостаток метода, отправной точкой в котором служат данные по системе в целом (V$SYSSTAT, V$SYSTEM_EVENT и т. д.). На самом деле с помощью Statspack можно собрать данные с достаточной степе­нью детализации, но нигде в документации я не встретил ни малей­шей попытки объяснить, зачем это может быть необходимо.

Отличной иллюстрацией к сказанному будет случай с Oracle-систе-мой, в которой роль красного камня исполняла проблема формирова­ния платежной ведомости. Руководство компании обрисовало пробле­му медленного создания платежной ведомости, создающую сложности в ведении бизнеса. Администраторы базы данных обнаружили пробле­му с защелками, конкретно - с защелками цепочек буферов кэша. Обе точки зрения были хорошо аргументированы. Бизнес действительно страдал из-за медленной обработки ведомостей. Это было очевидно: система выводила чеки с большой задержкой. Сервер тоже страдал вследствие конкуренции за защелки. И это было очевидно: запросы к V$SYSTEM_EVENT ясно показывали, что система тратит массу времени на события ожидания освобождения защелки (latch free).

Системные администраторы и администраторы БД этой компании по­тратили три месяца на отчаянную борьбу с конкуренцией за защелки, но это нисколько не улучшило ситуацию с платежной ведомостью. Причина оказалась проста: ведомость не ожидала освобождения заще­лок. Как мы это узнали? Мы получили данные о распределении време­ни выполнения программы формирования ведомости. Результаты нас удивили. Да, множество других программ действительно проводили время в ожидании защелок цепочек буферов кэша. Но медленная про­грамма формирования ведомости из 1985,40 секунд общего времени выполнения потратила на ожидание защелок лишь 23,69. Это состав­ляет 1,2% от общего времени. Если бы компания полностью исключи­ла ожидания освобождения защелок в своей системе, скорость форми­рования платежной ведомости возросла бы всего на 1,2%.

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

Я и мои коллеги регулярно сталкиваемся с подобными проблемами. Для аналитика по производительности решение заключается в том, чтобы сосредоточиться на пользовательских операциях, требующих оптимизации. Бизнес может определить, какие операции самые важ­ные, система - нет. Если определены процедуры, требующие оптими­зации, то главной задачей становится сбор данных о выполнении именно этих процедур - не больше и не меньше.

Концентрация на времени отклика системы

Последние пару десятилетий специалисты по производительности Or­acle исходили из предположения, что объективное измерение времени отклика Oracle невозможно [Ault and Brinson (2000), 27]. В отсутствие путей достоверного измерения времени отклика они взяли следующий по важности показатель: счетчики событий (event counts). За счетчика­ми, естественно, последовали коэффициенты. А за коэффициентами -разного рода доводы о том, какие действия по «настройке» важны, акакие - нет.

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

Нельзя судить о длительности события по количеству его возникновений.

Пользователей волнует только время отклика. Занимаясь счетчиками событий, вы измеряете не то, что их действительно интересует. Если вам понравилась задача про красный камень, вот вам еще одна: что мешает выполняться программе, порождающей приведенные ниже данные?

В примере 1.2 показаны результаты того же прогона программы, но здесь они дополнены данными о распределении времени (в секундах) и отсортированы по убыванию своего вклада в общее время ответа. Ваш ответ изменился?

Разумеется, ответ изменился - время отклика имеет решающее значе­ние, по сравнению с ним счетчики событий малоинтересны. Для рас­сматриваемой программы критичной является составляющая SQL*Net

message from client, а вовсе не CPU service.

Если бы дело происходило в 1991 г., у нас возникли бы серьезные за­труднения, т. к. в то время ядро Oracle не могло предоставить данные, показанные во второй таблице. Но если обновить Oracle хотя бы до вер­сии 7, то счетчики событий перестанут быть «следующими по важно­сти» после времени отклика показателями. Начиная с Oracle 7.0.12 основополагающий тезис, утверждающий, что невозможно судить о времени выполнения операций ядром Oracle, больше не действует.

Закон Амдала

Последнее из упоминавшихся мною «великих достижений» в оптимиза­ции производительности Oracle основано на опубликованном в 1967 г. Джином Амдалом (Gene Amdahl) наблюдении, названном впоследст­вии законом Амдала [Amdahl (1967)]:

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

Другими словами, повышение производительности пропорционально доле, занимаемой улучшаемым компонентом в процессе выполнения программы. Закон Амдала объясняет, почему составляющие времени отклика следует рассматривать в порядке убывания. Именно поэтому в примере 1.2 не следует заниматься «проблемой» CPU service, не разо­бравшись предварительно с проблемой SQL*Net message from client. Если потребление процессорного времени уменьшится на 50%, то время от­клика улучшится всего на 2%. Но если удастся уменьшить на те же 50% составляющую SQL*Net message from client, то общее время отклика уменьшится на 46%. В примере 1.2 каждый процент уменьшения SQL*Net message from client дает эффект приблизительно в двадцать раз больший, чем один процент уменьшения CPU service.

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

Объединив три рассмотренных принципа технологии оптимизации Oracle в одном предложении, получим следующее простое правило:

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

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

А в том, что этот простой метод оптимизации Oracle-систем недоступен тому, кто не умеете измерять время отклика и интерпретировать полу­ченные результаты. Как раз этой теме и посвящена основная часть этой книги.