Идентификация программ, конкурирующих с пользовательской операцией, чем-то похожа на обычную настройку производительности, во всяком случае, для этого применяются те же инструменты.
Существует множество инструментов для детального анализа различных ресурсов. Для начала отлично подойдут фиксированные представления Oracle, описанные в главе 8.
Детальное изучение подробностей функционирования вызывающего задержки устройства может напомнить старый способ настройки методом проб и ошибок (метод C из главы 1), однако здесь есть важное отличие. Оно связано с уникальной характеристикой метода R - детерминированным выбором цели. Не необходимости просеивать бесчисленное множество метрик, гадая, какая из них может оказать заметное влияние на производительность, а какая - нет. Точно известно, какой именно ресурс требует улучшения. И известно это из профиля ресурсов.
Самая сложная часть задачи поиска конкурентов пользовательской операции связана с проблемой сбора диагностических данных в правильной области. Это как раз тот случай, когда очень кстати подробная история всех событий в системе за время существования исследуемой проблемы производительности, аналогичная имеющейся в X$TRACE. Без такой подробной истории диагностических данных могут возникнуть трудности с определением программ, конкурирующих с пользовательской операцией, даже если с момента ее завершения прошло всего несколько минут. Есть несколько путей для достижения успеха, в частности:
Журналы выполнения пакетных заданий
Практически всегда наибольшую конкурирующую нагрузку в системе создают пакетные задания. В большинстве хороших программ управления пакетными заданиями предусмотрена возможность записи в журнал времени работы каждого из них. Отталкиваясь от этой информации, часто удается быстро определить, какие из программ конкурируют за определенный ресурс. Собрав при следующем плановом запуске этих программ необходимые диагностические данные, можно превратить предположения в точное знание.
Аудит уровня соединения
Экземпляр Oracle может быть легко сконфигурирован так, чтобы записывать в журнал статистику использования ресурсов сеансом. Эта статистика поможет определить, какие сеансы больше всего загружают систему в определенные периоды времени. Обладая такой информацией, можно, поговорив с пользователями, сделать достаточно достоверные предположения о том, какие программы создают конкуренцию за данное устройство. Как и в предыдущем случае, переход от предположений к точному знанию требует сбора диагностики в правильно определенной области для подозреваемых программ при следующем их запуске. Для начала изучите сведения о представлении DBA_AUDIT_SESSION в документации Oracle.
Учет использования ресурсов в операционной системе
Некоторые операционные системы предоставляют возможность сбора и хранения статистики производительности для отдельных программ. Это может оказаться очень важным, т. к. конкуренция за некоторый ресурс не обязательно может быть вызвана другим процессом Oracle.
Собственные измерительные средства
Для аналитика по производительности нет ничего лучше, чем код приложения, способный сам рассказать, чем он занят в каждый момент времени. Если можно встроить измерительные средства в медленно работающую программу (допустим, вы сами ее написали), сделайте это. Как это сделать, подробно описано в главе 7.
Отыскав программу, конкурирующую с пользовательской операцией за дефицитный ресурс, обратитесь к рекомендациям из предыдущего раздела «Исключение лишних вызовов». Теперь работа сводится к уже рассмотренным действиям, позволяющим выяснить, насколько в действительности оправданны требования к высокой загрузке ресурса.
Модернизация оборудования - последняя из возможностей, которую следует рассматривать при повышении производительности. Последнее место она занимает по вполне очевидным причинам:
• Дорогостоящая модернизация оборудования редко способна дать тот же эффект, что и недорогие мероприятия по исключению бесполезной нагрузки.
• Плохо спланированная модернизация оборудования может в действительности ухудшить производительность пользовательской операции, которую вы пытаетесь ускорить.
Любая модернизация оборудования связана с риском. С первого взгляда понятно, что отдача от инвестиций в более производительное оборудование может оказаться значительно ниже ожидаемой. Многие руководители считают модернизацию беспроигрышным вложением, считая, что «Разве может быть слишком много процессоров (памяти, дисков и т. д.)?». Расхожее мнение гласит, что даже если модернизация напрямую не решит имеющуюся проблему производительности, то как она сможет навредить? Ведь дополнительные мощности так или иначе будут использованы, разве нет? Увы, не всегда. Далеко не все осознают риск, связанный с принятием такого решения. Одну из возможных ситуаций я уже приводил в разделе «Почему правильный выбор так важен». Случай, описанный в разделе «Пример 1: Недостатки общесистемных данных» главы 12 - еще одна иллюстрация этой проблемы:
Модернизация оборудования направлена на повышение производительности некоторой части системы, но вопрос в том, поможет ли эта модернизация привести систему в соответствие с бизнес-целями ее владельца.
Первое формальное объяснение этого тезиса, противоречащего интуиции, я встретил в книге Нейла Гюнтера (Neil Gunther) «The Practical Performance Analyst» (Аналитик-практик производительности) [Gunther (1998) 117-122]. Когда я продемонстрировал пример Гюнтера участникам международной конференции Oracle, многие стали подходить к трибуне и рассказывать, что этот пример, наконец, помог им понять причину странных результатов, погубивших некоторые проекты. Я был польщен, но вместе с тем немного удивлен тем, что так много людей столкнулось с ухудшением производительности в результате модернизации оборудования. Более близкое знакомство с законом Амдала помогло мне понять, что любая модернизация может привести к снижению производительности какой-либо пользовательской операции вследствие возникновения конкуренции за ресурс, который не был модернизирован. Вопрос только в том, заметит ли кто-нибудь эти ухудшения.
Если модернизация оборудования не привела к росту производительности, то худший сценарий для проекта трудно себе вообразить. Вот как это происходит. Компания достаточно долго терпит недостаточную производительность, и, в конце концов, коллективные мучения достигают некоторого порога, за которым следует выделение денег на модернизацию. Размер ожиданий прямо пропорционален выделяемой сумме. В пятницу, перед Большой Модернизацией, вся компания нервничает в ожидании понедельника, ведь «Мы потратили на решение этой проблемы такие деньги, что все должно просто летать». И вот, в понедельник, все не только не летает, но и становится сильно хуже. Во вторник руководство обсуждает, стоит ли сотруднику, предложившему эту модернизацию, приходить на работу в среду.
Сотрудники, ответственные за принятие решений о модернизации, сталкиваются с интересными противоречиями:
Модернизация часто рассматривается как недорогая альтернатива дорогим аналитикам, хотя потенциальный выигрыш от нее не сравним с возможным выигрышем от уменьшения нагрузки.
Модернизация часто считается совершенно безопасной, хотя она связана со значительными рисками. Эти риски требуют проведения серьезного, тщательного и, возможно, дорогого предварительного анализа.
Успешная модернизация обычно не оправдывает возлагавшихся на нее надежд. Если модернизация не удалась, опасности подвергается карьера модернизатора. Провалы часто бывают столь оглушительными, что восстановить доверие спонсоров уже не удается.
Нужно ли вообще модернизировать оборудование? Разумеется, во многих случая это необходимо. Но я заклинаю вас не рассматривать модернизацию как первое средство от проблем производительности. Вам действительно не хватает мощности системы? Вполне возможно, что она загружена бесполезной работой. Так что, пожалуйста, исключите лишние обращения к ресурсам, прежде чем модернизировать их. А прежде чем приступать к модернизации, обязательно обдумайте следующие вопросы:
Не начинайте модернизацию до тех пор, пока не убедитесь, что модернизируемый ресурс (а) улучшит выполнение важных пользовательских операций и (б) повредит только второстепенным операциям.
И, разумеется, не упускайте из виду тот факт, что второстепенная пользовательская операция завтра может стать очень важной, если ее выполнение замедлится.
< Предыдущая | Следующая > |
---|