Почему нужно заботиться о методологии настройки?
Количество энергии, расходуемой на получение настроенной базы данных,
зависит от методологии настройки. Выбор методологии настройки связан со степенью удовлетворенности работой. АБД должен соблюдать баланс между многими ограничениями и поэтому не может тратить время и энергию на неоцененные поиски. Разработка хорошего подхода к управлению производительностью поможет избежать напрасных усилий. Именно методология должна помочь определить, когда сказать "стоп".
Приводившиеся в начале этой главы мифы внесли свой вклад в неудачу многих методологий настройки. Первый базировался на предположении, что настройка производительности системы сводится только к настройке базы данных. При этом не брались в расчет ограничения, налагаемые на базу данных операционной системой, системой массовой памяти, приложениями и даже сетью.
Второй миф основывался на значениях упоминавшихся ранее коэффициентов без рассмотрения того, каково в настоящий момент состояние базы данных Oracle и что именно она делает для приложения. Обе методологии пренебрегают базовым принципом: при хорошем управлении производительностью следует избегать неблагоприятных действий системы. Более существенным является
то, что вместо далеко идущих преобразований приходится настраивать компоненты, вызывающие появление узких мест.
Методология настройки — это не случайные действия по изменению систе-
мы в надежде достичь туманных целей по улучшению производитель-
ности. Долгое время люди, ступившие на стезю настройки, особенно
касающейся Oracle, не придерживались никаких основополагающих принци-
пов. Это приводило к попыткам работы вслепую. Первым номером в списке со-
вершенных правонарушений следует записать стиль настройки, действуя в
мы в надежде достичь туманных целей по улучшению производитель-
ности. Долгое время люди, ступившие на стезю настройки, особенно
касающейся Oracle, не придерживались никаких основополагающих принци-
пов. Это приводило к попыткам работы вслепую. Первым номером в списке со-
вершенных правонарушений следует записать стиль настройки, действуя в
соответствии с которым, память накачивается в системную глобальную область
Oracle (SGA, Oracle System Global Area) в надежде на то, что после этого проблемы с производительностью системы исчезнут сами по себе. Однако случайные изменения размеров памяти, выделяемой для основных компонентов SGA, в лучшем случае только слегка увеличивают производительность системы, а в худшем — могут привести к ее серьезной деградации.
Многие из этих видов усилий базируются на предположении, что процессом
настройки должны управлять именно коэффициенты попадания в кэш. При таком отношении легко угодить в засасывающий водоворот — больше памяти, больше ЦП, больше памяти, больше ЦП: Приведем типичный пример: однажды
при попытке достичь высокого процента попаданий в кэш (более 90%) для кэша
буфера базы данных было сконфигурировано значительное количество памяти.
В результате система начала испытывать существенное повышение уровня страничной подкачки и свопинга.
А вот и другой классический пример настройки по коэффициентам. В неко-
торых случаях при выделении для области коллективных пулов запредельного
размера памяти начинает зависать система синтаксического анализа. В резуль-
тате Oracle испытывает трудности при управлении напрасно выделенными
огромными сегментами памяти, связанными с областью коллективных пулов. В
некоторых средах в таких случаях увеличива-
торых случаях при выделении для области коллективных пулов запредельного
размера памяти начинает зависать система синтаксического анализа. В резуль-
тате Oracle испытывает трудности при управлении напрасно выделенными
огромными сегментами памяти, связанными с областью коллективных пулов. В
некоторых средах в таких случаях увеличива-
лось время синтаксического разбора, начинались зависания операторов SQL и даже имели место серьезные внутренние блокировки вследствие конкуренции
за библиотечный кэш (внутренний ресурс, используемый Oracle для управления библиотечным кэшем, являющимся компонентом области коллективного пула).
Итак, если действие было предпринято просто для достижения высоких значений коэффициента попаданий в кэш для области коллективного пула (мы- то хорошо знаем, что высокие значения этого замечательного показателя прекрасно влияют на физическое, эмоциональное и умственное состояние АБД!), то, к сожалению, возникает проблемная ситуация, когда для этого нет, казалось бы, никаких видимых причин.
Это сценарий, где все было хорошо, пока недуг по имени "коэффициент попадания в кэш должен быть 99,999%" не завладел всем. Вспомните болезнь принудительной настройки (CTD), речь о которой шла в главе 1! Усугубляя положение вещей, некоторые АБД прибегают к таким экстремальным мерам, как частое обновление коллективных пулов. Вместо чтобы стремиться стать набором управляемых усилий, операции по настройке превращаются в серию постоянных фиаско по методу проб и ошибок.
Методы настройки, описанные в этом разделе, можно выразить такими словами: безумие без всякой систематичности. Хорошее управление производительностью получается в том случае, если в безумие привносится метод.
< Предыдущая | Следующая > |
---|