| Учат в школе, учат в школе, учат в школе… Концепция Resource Governor реконФигурное катание Фарш невозможно провернуть назад |  |
Уверен, что теме распределения аппаратных ресурсов и управления рабочей нагрузкой в SQL Server 2008 будет посвящено много заметок в блогах, статей и даже книг. Возможно, кто-то сочинит мюзикл, где Ларс Ульрих сыграет на барабанах. Возможно всё. Но сейчас, пока уважаемый читатель способен однозначно сказать, в каком ухе у него жужжит, я хочу поделиться своими впечатлениями от использования Resource Governor. Благо, что я участвовал в программе тестирования новой технологии.
О проблеме распределения ресурсов в условиях острой нехватки оных я впервые услышал от воспитательницы детского сада, который посещал по малолетству и принуждению. Проблема была озвучена приблизительно так:
Мы делили апельсин,
Много нас, а он один.
Эта долька – для ежа,
Эта долька – для стрижа,
Эта долька – для утят,
Эта долька – для котят,
Эта долька – для бобра,
А для волка – кожура.
Он сердит на нас – беда!!!
Разбегайтесь кто куда!
Обратите внимание, что «распил» апельсина происходит по схеме, встречающейся в жизни сплошь и рядом (кстати, исходя из первой фразы, мы вынуждены предположить, что автор является участником дележа и, следовательно, он либо одно из упомянутых животных, либо намеренно себя обделил). Ежик, стриж и бобёр получили по целой дольке, тогда как утята и котята сгруппированы по признаку биологического родства. При этом каждой группе приходится довольствоваться одной долькой на всех, а вот волка совсем обидели, не проявив к нему должной политкорректности — «серому» перепала лишь кожура.
Став старше, я сменил слюнявчик на галстук, и знаю, что если оставить бухгалтерию «с кожурой» в виде еле трепыхающегося SQL-сервера, да ещё в период сдачи отчётности, то убегать будет некуда. Главбух достанет даже в Гонолулу.
Причин, приводящих к таким ситуациям, может быть много. Одна из них — это конкурентная борьба за ресурсы сервера (те самые апельсиновые дольки!) между приложениями и даже отдельными пользователями. Наш малый и, чего греха таить, средний бизнес всё ещё скрепя сердце идёт на покупку выделенных серверов под каждое приложение. К тому же интуитивно понятно, что ёмкости этих ресурсов порой не хватает именно в считанные дни, тогда как в остальное время сервер превосходно справляется со своей задачей.
Что делать, когда менее значимое для компании SQL-приложение ведёт себя как саранча, поедая всю доступную серверу память и мешая нормальному функционированию намного более критичных систем? Искать причину в коде? Оптимизировать на коленке? А если это проприетарный продукт, рождённый в муках какой-нибудь софтверной компании, где у программистов руки растут для красоты?
Другими словами, в MS SQL Server давно не хватало инструмента, позволяющего регулировать потребление ресурсов и гибко управлять нагрузкой. И такой инструмент появился в Katmai (кодовое название SQL Server 2008) под названием Resource Governor.
На данный момент в поле зрения Resource Governor (RG) находятся два типа разделяемых ресурсов — оперативная память и CPU. При этом контроль осуществляется только над ресурсами, которые могут быть выделены процессу MS SQL Server операционной системой. Так, если у вас на той же самой машине установлен, к примеру, IIS, нагружающий процессор на 70%, то оставшиеся 30% — это максимум, на который может претендовать экземпляр SQL-сервера, и максимум того, чем может распоряжаться его Resource Governor. Исходя из этих соображений, легко понять, почему RG не умеет регулировать нагрузку на другие компоненты SQL-сервера, такие как Analysis Services, Integration Services или Reporting Services. Все перечисленные компоненты являются отдельными процессами ОС.
Коротко рассмотрим основные понятия Resource Governor.
Пулы позволяют разделить ресурсы сервера в соответствии с нашими требованиями к отказоустойчивости и быстродействию приложений.
Проведём аналогию с поэтическим зоопарком, описанным ранее.
Допустим, у нас есть апельсин, состоящий из 7 долек, и этот апельсин — ресурс возобновляемый. Мы создали один пул, в котором постановили, что бобёр должен получить не менее 3-х и не более 5 долей апельсина в условиях конкуренции за него. И ещё один пул для ежа, где тому полагается минимум 4 и максимум 6 долек (опять же если на него кто-то ещё претендует). Тем самым, мы задали гарантированный минимум продовольственного обеспечения, который получат бобёр и ёж.
Предположим, что пока ёж в командировке, апельсин находится в полном распоряжении бобра. Внимание, вопрос: сколько может съесть бобёр? Ответ — Resource Governor позволит ему покушаться на весь апельсин целиком до тех пор, пока из тумана не выйдет ёжик (безраздельное владение бобра ресурсами в отсутствие других потребителей повышает эффективность использования оных).
И тут начинается самое интересное. Если ёжик не очень голоден (с утра съел гамбургер) и претендует только на 2 дольки, то бобёр (неделю росинки маковой во рту не было) уже сможет посягнуть только на свой ограниченный паёк в 3-5 долек. А вот если ёж попался жадный и пытается у бобра отобрать его часть фруктового десерта, то Resource Governor не даст в обиду строителя плотин. Бобёр всегда может быть уверен, что при необходимости получит не меньше 3-х долек апельсина.
Теперь, когда вы имеете образное представление о пулах, можно обсудить, как они настраиваются в MS SQL Server 2008. Делается это с помощью пары параметров MIN% и MAX% для каждого типа ресурсов (одна пара для CPU, другая — для оперативной памяти). Собственно, мы уже обсудили их назначение. MIN% задаёт гарантированный минимум ресурса, который при необходимости будет предоставлен потребителям пула, а MAX% — верхнюю границу в условиях конкуренции за ресурс.
Очевидно, что сумма минимумов всех пулов не должна превышать 100%, в то время как MAX% может быть задан в диапазоне от MIN% до 100%.
В MS SQL Server 2008 есть два предопределённых пула — Internal Pool и Default Pool.
Internal Pool используется сервером для внутренних нужд. Естественно, что изменять настройки этого пула запрещено. От доступности ресурсов в Internal Pool зависит функционирование самого SQL Server, поэтому Resource Governor может позволить ему потеснить «коллег». Даже если такое перераспределение помешает остальным пулам получить свой гарантированный минимум. Для работы с Internal Pool предусмотрена одноимённая группа нагрузки (о понятии workload group см. ниже). Разумеется, что другие группы этот пул использовать не могут.
В отличие от internal, Default Pool допускает изменение настроек. По своему назначению он похож на любой другой пользовательский пул с тем лишь отличием, что его нельзя удалить. Правда, у Default Pool есть ещё одно назначение. Когда вы выключаете Resource Governor, настройки пулов сбрасываются (MIN%=0, MAX%=100), и все новые сессии начинают разделять пул Default. Таким образом, конкурентная борьба за ресурсы будет выглядеть приблизительно так, как это происходило в MS SQL Server 2005.
Когда речь заходит о пулах, вы можете столкнуться с понятиями Effective MAX% и Shared%.
Продолжение следует…
Версия для печати