Как известно, в SQL Server версии 2008 компания Microsoft добавила новый инструмент – регулятор ресурсов SQL сервера – Resource Governor (далее RG).

Из официального описания — это компонент, предназначенный для управления рабочей нагрузкой SQL Server и использованием системных ресурсов. Регулятор ресурсов позволяет задать ограничения на загрузку ЦП, физических средств ввода-вывода и использование памяти, которые доступны для входящих запросов приложений. К слову, регулирование ограничениями в части IOPS (количество операций ввода/вывода) появилось только в версии SQL Server 2014.

Механизм интересный, но, к сожалению, методики, по которой можно настроить RG в той или иной системе как таковой нет. Обычно все настройки происходят эмпирическим путем и не всегда удачно. Хорошо, если администратор давно обслуживает ИС, в достаточной степени знаком со структурой метаданных и знает все болевые точки ИС. В противном случае без должной системы мониторинга производительности, анализа статистики за прошедшие периоды все настройки RG становятся некой лотереей, которая может дать позитивный эффект или может дать лишь кратковременный эффект, а может и навредить.

• Нужно ли вообще использовать RG для конкретной ИС?
• Как выбрать ресурсы, которыми нужно управлять?
• Как правильно настроить ограничения?
• Как поддерживать эти настройки для эффективной работы ИС?

На эти вопросы мы и попытаемся ответить в этой статье. В качестве метода анализа эффективности использования RG мы избрали нагрузочное тестирование, которое поможет эмпирически понять особенности его настройки и целесообразности подключения в том или ином случае.

Данная статья – это первая часть исследования и посвящена регулировке только одного ресурса — CPU. Почему именно CPU? Потому что этот ресурс наиболее показателен в части регулировки и демонстрации результатов. Остальные ресурсы, на самом деле, не так автономны с точки зрения регулировки, как хотелось бы, и требуют достаточно тщательной подготовки тестового стенда, но это уже тема для другого исследования.

2. Нагрузочное тестирование RG в SQL Server 2014

2.1. Методика тестирования

Основная идея нагрузочного тестирования заключается в разделении общего информационного потока к БД на два и последующим перераспределении ресурсов сервера MS SQL Server между ними. Потоков будет два – OLTP-поток и OLAP-поток. Под OLAP-потоком подразумеваются все нетранзакционные запросы к БД.

В результате этого разделения, используя технологию RG, мы попытаемся дать карт-бланш OLTP-потоку, т.к. простои бизнеса возникают чаще всего именно по причине замедления транзакционных потоков (например, не должен кассовый чек в магазине пробиваться 1,5 мин. и более, ожидая вычисления результатов какого-то отчета).

Поскольку в этом исследовании мы будем оперировать только CPU-ресурсом, то все тесты проводились на RAM-диске, дабы исключить дисковую подсистему как узкое место.

В тестировании будет использоваться множество сценариев, но всегда в каждом будет три этапа:

1. Снятие данных о производительности OLTP-потока сервера при наличии одновременно обоих видов нагрузки.
   Данный этап покажет типичную жизненную картину производительности сервера, испытывающего нагрузки (особенно пиковые) как от OLTP, так и от OLAP-составляющей (например, периоды распродаж, акций, получения регламентированной отчетности и т.п.). Регулируя объем потоков можно добиться практически полной остановки OLTP-потока, а, следовательно –  остановки бизнеса.
2. Снятие данных по производительности сервера только OLTP-потока.
   Данный этап покажет так называемое эталонное состояние сервера, когда никаких дополнительных нагрузок, «мешающих» работе ИС нет. Это идеальное состояние ИС, к которому мы будем стремиться при перераспределении ресурсов сервера после подключения RG.
3. Снятие данных о производительности сервера при наличии одновременно и OLTP-нагрузки, и OLAP-нагрузки и включенного RG c определенными параметрами, ограничивающими выделенные ресурсы для OLAP-нагрузки.
   Именно третий этап позволит оценить эффективность технологии RG в том или ином случае и сделать выводы.

Тестирование разделено на две части.

В первой части в качестве OLTP-нагрузки используется запрос T-SQL, эмулирующий открытие транзакции, выполнение в ней достаточно тяжелого запроса и закрытие транзакции. Таблица для запроса выбрана произвольным образом из ТОР10 по количеству строк из приложения 1С:Предприятие Управление торговлей 11 (использовались таблицы «Остатки» регистра «Товары на складах» (AccumRgT4896), таблица «Остатки» регистра «Товары организаций» (AccumRgT16954)  и  таблица регистра сведений «Коды товаров подключаемого оборудования offline» (InfoRg8550). Нагрузка на ресурсы достигается путем создания необходимого количества сессий и кол-ва транзакций в них. Запросы использовались только на чтение с NOLOCK.

В качестве OLAP нагрузки используется синтетический запрос в SQL Management Studio к двум  произвольным таблицам 1C:Управление торговлей 11, выбранным также из ТОР10 таблиц по размеру с совпадающим измерением (таблица «Остатки» регистра «Расчеты с клиентами» (AccumRgT4762) и таблица «Остатки» регистра «Расчеты с клиентами по документам» (AccumRgT4777)). OLAP-нагрузка запускается в бесконечном цикле как фоновая нагрузка.

Индикаторами тестирования являются изменение нагрузки на ресурс CPU, а также изменение длительности транзакции в OLTP-потоке.

Скрипты по нагрузочным тестам первой части приведены ниже в разделе 2.4.1 Общая информация о тесте.

Во второй части тестирования используются аналогичный подход, но теперь в OLTP-нагрузку искусственно добавляются блокировки. Кол-во блокируемых элементов таблицы выбирается автоматически и произвольно. Цель второй части тестирования – проверка влияния RG на увеличение или уменьшение эскалации блокировок в OLTP-потоке. Именно дерево блокировок и будет являться важным индикатором данного нагрузочного теста.

Скрипты по нагрузочным тестам второй части приведены ниже в разделе 2.5.1. Общая информация о тесте.

2.2. Серверное оборудование и ПО

• CPU: 2,8 ГГц, 6 ядер;
• RAM: 40 Гб;
• ОС: Windows Server 2012 R2;
• СУБД: SQL Server 2014

Подробности серверного оборудования можно увидеть ниже на рисунке 1:

2.3. Инструменты тестирования

• В качестве инструментов для моделирования нагрузки и снятия показателей используются:
  SQL Management Studio – для создания скриптов T-SQL:
  o для эмуляции фоновой OLAP-нагрузки в БД 1С:Предприятие Управление торговлей 11;
  o для эмуляции OLTP-нагрузки как для контроля длительности транзакций, так и для контроля эскалации блокировок;
• Программа SOFTPOINT SQL Load Testing – для запуска скриптов T-SQL в необходимой последовательности и в необходимом кол-ве сессий;
• Программный комплекс SOFTPOINT PERFEXPERT для снятия показателей производительности и просмотра деревьев блокировок;
• MS Excel – для удобного представления и совмещения на диаграммах длительности транзакций в разных этапах сценария.

2.4. Тестирование — часть 1. RG и время отклика в OLTP-нагрузке

2.4.1. Общая информация о тесте

Для создания OLTP-нагрузки используется синтетический запрос на языке T-SQL к таблицам «Остатки» регистра «Товары на складах»  (AccumRgT4896), «Остатки» регистра «Товары организаций» (AccumRgT16954)  и  к регистру сведений «Коды товаров подключаемого оборудования offline» (InfoRg8550) из демонстрационной конфигурации «1С:Управление торговлей 11».

Итоговый запрос не имеет никакого практического смысла и его единственная цель — добиться определенной длительности транзакции на данном стенде (~3 сек). При этом в условиях соединения специально были использованы конструкции, препятствующие использованию индексов, чтобы увеличить время выполнения запроса.

Примерный текст запроса в терминах 1С приведен ниже. С точки зрения языка запросов 1С он не корректен, но позволяет понять структуру используемого запроса:

Все OLTP-сессии стартуют одновременно, но в каждой сессии перед началом транзакции выполняется случайная задержка в диапазоне от 1 до 90 секунд. Таким образом, модель приближается к реальной работе пользователей, когда транзакции начинаются не одновременно, а в разные моменты. Время задержки не учитывалось в замерах времени выполнения транзакции.

Полный текст скрипта, моделирующего OLTP-сессию приведён в разделе «Приложение 3. Скрипт, моделирующий OLTP-нагрузку».

Для создания OLAP-нагрузки, как уже говорилось выше, используется синтетический запрос на языке T-SQL к двум таблицам БД 1С:Управление торговлей 11 (остатки регистра «Расчеты с клиентами» и остатки регистра «расчеты с клиентами по документам» ). Таблицы были выбраны произвольным образом из TOP10 по количеству строк, соединение таблиц — по первой попавшейся паре полей одинакового типа («Заказ клиента» у обоих регистров).

Запрос выполняется в бесконечном цикле и генерирует фоновую нагрузку, забирающую ресурсы у OLTP-сессий.

Количество сессий и количество транзакций в каждой сессии управляется при помощи утилиты SOFTPOINT Load Test.

Настройка Resource Governor осуществляется путем создания двух разных Resource Pool’ов — отдельно для OLAP и отдельно для OLTP-нагрузки. Каждый вид нагрузки запускается от разных пользователей SQL сервера. Функция распределения принимала решение в зависимости от наименования пользователя.

Код создания пулов ресурсов выглядит так:

где Arg – аргумент функции, указывающий гарантированную, максимальную, среднюю или минимальную пропускную способность CPU, предоставляемую ресурсу (MIN_CPU_PERCENT, MAX_CPU_PERCENT, CAP_CPU_PERCENT), а N – выставляемое значение ограничения.

В ходе тестирования мы провели несколько сценариев, в которых «поигрались» порогами для распределения ресурса CPU между двумя пулами. В каждом сценарии мы меняли кол-во сессий OLTP, кол-во сессий OLAP, а также значения устанавливаемых порогов пропускной способности CPU.

В таблице 1 приведены параметры сценариев нагрузочного тестирования.

Ограничение максимального CPU, выделяемого OLAP-потоку	Ограничение CPU для OLTP	Ограничение CPU для OLAP	Кол-во потоков OLTP	Кол-во потоков OLAP
Сценарий 1.1	–	20%	20	6
Сценарий 1.2	–	20%	20	50
Сценарий 1.3	–	20%	50	20
Сценарий 1.4	–	20%	50	50
Сценарий 1.5	–	50%	20	6
Сценарий 1.6	–	50%	20	50
Сценарий 1.7	–	50%	50	20
Сценарий 1.8	–	50%	50	50

Таблица 1. Параметры сценариев для первой части нагрузочных тестов

2.4.2. Результаты тестирования

Результаты тестирования по каждому сценарию выведены на диаграммы:

Результаты тестирования по каждому сценарию выведены на диаграммы:

• Диаграмма 1: Длительность транзакций в OLTP- потоке в трех случаях: без OLAP-нагрузки, с OLAP-нагрузкой и OLAP- нагрузкой плюс включение RG.
• Диаграммы 2: Выведены ключевые счетчики производительности SQL сервера, иллюстрирующих корректность тестирования (заметно, что ресурсы системы загружены исключительно тестовой нагрузкой; влияние сторонних процессов исключено).

Все сценарии показали примерно одинаковую картину – где-то картина более выражена, где-то нет. Ниже на рисунках (Рисунок 3 и Рисунок 4) приведены результаты сценария 1.4, где кол-во OLTP потоков достаточно высокое для данной конфигурации сервера. Полный перечень диаграмм по сценариям приведен в разделе «Приложение 1. Диаграммы счетчиков производительности при изменении порогов пропускной способности CPU и количества сессий в OLTP- и OLAP-нагрузках».

На рисунке (Рисунок 3) хорошо видно, что на всем протяжении теста OLAP-нагрузка держится на уровне 20-25% процентов (выставлено ограничение MAX_CPU_PERCENT=20) и как только включилась OLTP-нагрузка, то CPU_OLAP выше 20% действительно не поднимался.

А вот уровень CPU_OLTP на максимальном уровне держался менее половины времени сценария, а потом RG начал снижать пропускную способность CPU для OLTP-нагрузки (см. Рисунок 3) и часть транзакций выполнялась дольше, чем хотелось бы. А часть выполнялась даже дольше, чем без RG (см. Рисунок 4, зеленый график). Хотя вначале, когда запросы только начали выполняться, эффект был очень хороший и длительность транзакций приближалась к эталонной (синий график на диаграмме). Т.е. чисто статистически положительный эффект при таких начальных условиях наблюдается в 30-50% случаев. Это очень неплохо для такого количества OLTP-сессий, выполнявшихся практически одновременно. Из нашей практики именно в высоконагруженных ИС наблюдается положительный эффект при анализе запросов на лету и их распределении, например по разным нодам кластера (технология DATA CLUSTER http://www.softpoint.ru/data-cluster-basi-dannih-sql-server).

Для сравнения, при меньшем количестве OLTP-сессий распределение кванта времени и вычислительной мощности происходит более эффективно. На рисунке (Рисунок 5) представлена диаграмма длительности транзакций для сценария 2, где количество сессий OLTP-нагрузки уменьшено до 20. Здесь картина совсем другая и видно, что RG очень хорошо справился со своей задачей и длительность транзакции уменьшилась в несколько раз, приблизившись к эталонной. На диаграмме все же имеется характерная горизонтальная «плашка», как и в остальных сценариях, где транзакции висят и выполняются дольше, чем хотелось бы (напомню, блокировок нет вообще), при этом пул ресурсов CPU для OLTP-нагрузки не нагружен на максимум и его пропускная способность даже продолжает падать.

Таким образом мы видим, что при моделировании нагрузки одними и теми же запросами к одним и тем же таблицам положительный эффект есть. Но местами он кратковременный, а местами даже обратный.

Поэтому, для чистоты эксперимента и проверки данного утверждения было принято решение изменить OLTP-нагрузку на более «жизненную». Мы провели дополнительный тест, в котором смоделировали OLTP-нагрузку в демоверсии БД 1С:Предприятие Управление торговлей 11 (подробно см. в разделе 2.6 Дополнительный нагрузочный тест).

2.5. Тестирование — часть 2. RG и дерево блокировок в OLTP-потоке.

2.5.1. Общая информация о тесте

Поскольку в реальных БД, как правило, именно блокировки оказывают существенное влияние на работу системы, то цель данной серии тестов проверить эффективность RG при снижении эскалации блокировок.
Для создания OLTP-нагрузки используется скрипт из первой части нашего тестирования, но с возможностью дополнительно накладывать блокировки внутри транзакции.
Для моделирования блокировок используется оператор sp_getapplock, создающий виртуальную блокировку по переданному ключу. Ключ блокировки генерируется при каждом вызове оператора как случайное целое число от 0 до 500. Если в двух разных сессиях выпадает одно и то же число, то сессия, обратившаяся к ключу позже, попадает на блокировку и вынуждена дожидаться завершения более ранней сессии. По сути, моделируемый механизм аналогичен, например, наложению строковых блокировок на таблицу из 500 записей.
Для каждой сессии устанавливается таймаут ожидания блокировки в 20 сек — именно такой таймаут по умолчанию установлен для пользовательских сессий в приложениях 1С:Предприятие.
Полный скрипт, моделирующий OLTP-нагрузку, приведён в разделе «Приложение 3. Скрипт, моделирующий OLTP-нагрузку».
Для создания OLAP-нагрузки запрос остался тем же, что и в первой части.
Количество сессий в обоих видах нагрузок устанавливается также при помощи утилиты SOFTPOINT Load Test.
При подключении RG пропускная способность CPU для OLAP-нагрузки была жестко ограничена величиной 20% (CAP_CPU_PERCENT = 20). Поэтому проверять эскалацию блокировок мы будем только в зависимости от числа сессий в потоках и количества блокируемых элементов в таблицах.
В таблице 2 приведены параметры сценариев нагрузочного тестирования.

Таблица 2. Параметры сценариев для второй части нагрузочных тестов с фиксированным порогом пропускной способности CPU для OLAP-нагрузки

Ограничение максимального CPU, выделяемого OLAP-потоку	Ограничение CPU для OLTP	Ограничение CPU для OLAP	Кол-во блокировок в одной сессии	Кол-во потоков OLTP	Кол-во потоков OLAP
Сценарий 2.1	–	20%	5	25	25
Сценарий 2.2	–	20%	10	25	25
Сценарий 2.3	–	20%	15	25	25
Сценарий 2.4	–	20%	5	50	50
Сценарий 2.5	–	20%	10	50	50
Сценарий 2.6	–	20%	15	50	50
Сценарий 2.7	–	20%	5	100	50
Сценарий 2.8	–	20%	10	100	50
Сценарий 2.9	–	20%	15	100	50

2.5.2. Результаты тестирования

Результаты тестирования по каждому сценарию выведены на следующие виды диаграмм:
• Диаграмма 1: Длительность транзакций в OLTP- потоке в трех случаях: без OLAP-нагрузки, с OLAP-нагрузкой и OLAP- нагрузкой плюс включение RG. Показывает основной эффект от включения RG к БД.
• Диаграммы 2: Выведены ключевые счетчики производительности SQL сервера, иллюстрирующих корректность тестирования и демонстрируется деревья блокировок.

Все сценарии показали примерно одинаковую картину с сильным положительным эффектом при подключении RG , и все графики имеют вид как на диаграммах ниже. Полный перечень диаграмм по сценариям приведен в разделе «Приложение 2. Диаграммы счетчиков производительности, деревьев блокировок и длительности транзакций при изменении количества блокировок в OLTP-нагрузке и количества сессий в OLTP- и OLAP-нагрузках»
В отличие от первой серии тестов здесь уже нет такого ярко выраженного спада производительности в виде увеличения времени транзакций. Нагрузка распределена достаточно равномерно, и производительность транзакционных сессий близка к идеальной (см. Рисунок 7, синий и зеленый графики). Помимо этого, во всех сценариях наблюдается снижение эскалации блокировок при подключении RG (см. Рисунок 8).

Рисунок 7. Длительность транзакции в OLTP-потоке (сценарий 2.4)
(а) – гистограмма сессий
(б) – огибающая, для удобства восприятия

Рисунок 8. Счетчики производительности SQL сервера и деревья блокировок (сценарий 2.4)
(а) счетчики производительности для трех этапов сценария
(б) дерево блокировок

Рассмотрим более подробно графики счетчиков производительности (Рисунок 8). Диаграмма условно разделена на три области – три этапа прохождения сценария: OLTP; OLTP+OLAP; OLTP+OLAP+RG. Нижние три графика отображают нагрузку на CPU в разрезе пулов ресурсов default, rp_oltp и rp_olap.

При отключённом RG все пользовательские подключения отражаются в пуле ресурсов default. На графиках хорошо видно, как после включения фоновой нагрузки в виде OLAP-сессий время выполнения второго этапа увеличилось в разы. Как раз на эту же величину в среднем увеличилось длительность каждой транзакции (Рисунок 7).

После включения RG загрузку CPU нужно наблюдать уже на двух других счетчиках, т.к. RG распределяет её между двумя пулами ресурсов rp_oltp и rp_olap.

Эффект виден невооружённым глазом – длительность прогона всех OLTP-сессий почти совпадает с той, что была на первом этапе (счётчик default, этап OLTP). Кол-во блокировок уменьшилось более чем в два раза по сравнению со вторым этапом, что можно наблюдать как по счетчику Блокировки (Рисунок 8-а, четвертый сверху график), так и по построенным деревьям блокировок в точках, отмеченных маркерами 1 и 2 (Рисунок 8-а). Сами деревья представлены на рисунке (Рисунок 8-б).

Отличительной чертой данной серии тестов является то, что все пространство блокировок ограничено числом 500 (читай, в таблице 500 строк). Если посмотреть, например, на последний сценарий 2.9, где кол-во OLTP-сессий равно 100, а в каждой сессии накладывается по 15 блокировок, в момент пиковой нагрузки создаётся 1500 блокировок, что в три раза больше чем само блокировочное пространство. И даже в такой экстремальной ситуации включение RG даёт положительный эффект: количество блокировок в секунду не уменьшается, но в то же время среднее время транзакции всё равно уменьшается за счёт того, что каждому потоку достаётся больше процессорных ресурсов (см. Рисунок 9).

Рисунок 9. Счетчики производительности для CPU (сценарий 2.9).
а) счетчики производительности для трех этапов сценария (только OLTP,
б) дерево блокировок

Основной вывод, который следует из тестов 2-й части – это то, что в ситуации, приближенной к реальной, когда в БД есть блокировки, их длительность и количество произвольные, эффективность RG заметно повышается и становится даже стабильной. Ниже в дополнительном нагрузочном тесте мы проверим это с помощью создания и проведения реальных документов в достаточно интенсивном потоке из 50 сессий по 20 документов в каждой (подробности ниже в разделе 2.6 Дополнительный нагрузочный тест).

2.6. Дополнительный нагрузочный тест

Идея данного теста возникла во время проведения серии сценариев из первой части, когда появилось подозрение, что одни и те же запросы к одним и тем же данным использовать не очень верно и нужно смоделировать более реалистичную нагрузку.
Итак, для моделирования OLTP-нагрузки была взята демонстрационная база 1С:Предприятие 8.3 Управление торговлей 11 и к ней написана обработка, которая запускает 50 пользовательских сессий, в каждой из которых с произвольной задержкой (до 60 сек) создает 20 новых документов «ПКО» и «ЧекККМ», и случайным образом выбирает в них контрагента из справочника.
OLAP-нагрузка осталась такой же, как и в предыдущей серии тестов, кол-во сессий ¬50. Ограничение CPU для OLAP-нагрузки выбрано 50%.
Тест состоял также из трех этапов: только OLTP; OLTP плюс дополнительная OLAP-нагрузка; OLTP плюс OLAP -нагрузка и плюс RG. Результаты представлены на рисунках (Рисунок 10 и Рисунок 11).
Как видно из рисунка (Рисунок 10) картина стала очень оптимистичной и длительность транзакций приблизилась к эталонной.
На рисунке (Рисунок 11) видно как после включения RG, он действительно эффективно отрегулировал пропускную способность CPU на всем протяжении теста. Хорошо наблюдается распределение пропускной способности CPU между двумя пулами (OLTP1C и OLAP). Графики распределения CPU для OLAP и OLTP нагрузки практически зеркальные – как только возрастает OLTP-нагрузка, RG-снижает пропускную способность CPU для OLAP-нагрузки. Блокировок в данном тесте не было, хотя были управляемые блокировки 1С, но их количество незначительно.

Рисунок 10. Длительность транзакций в 50-ти сессиях OLTP в 1C:УТ 11 (дополнительный тест)
(а) – гистограмма сессий
(б) – огибающая, для удобства восприятия

Рисунок 11 Счетчики производительности
(а) счетчики производительности для двух этапов сценария OLTP+OLAP и OLTP+OLAP+RG
(б) Увеличенный фрагмент (1)

3. Выводы и заключения

Основной вывод, который следует из тестов – это то, что технология перераспределения ресурса CPU работает. И даже при нашем однобоком подходе выигрыш есть более чем в 50% случаев, а при более реалистичном сценарии положительный эффект наблюдался на всем протяжении тестов. Говорить об абсолютной величине выигрыша производительности для какого-либо пула ресурсов (OLTP-поток, OLAP-поток или какой-нибудь специфический VIP-поток) сейчас не очень правильно. В наших тестах она варьировалась от десятков процентов до нескольких раз. Однозначно, выигрыш есть.
Вообще, если говорить о регулировке пропускной способности CPU, то получить 100% предсказание очень трудно, т.к. распределение вычислительной мощности происходит в зависимости от выделенного кванта времени ядру процессора и балансировка проходит не всегда эффективно.
В нашем тестовом стенде всего 6 ядер и когда мы давали синтетическую OLTP- нагрузку 50 и более сессий, наблюдался эффект увеличения времени отклика, особенно ближе к концу сценария, и RG не совсем корректно, на наш взгляд, выделял необходимое количество процессорной мощности. Вероятно, это связано с неверным выделением кванта времени тем или иным сессиям OLTP-нагрузки, в то время как им было нужно непрерывное использование процессора. В принципе, если экстраполировать картину на реальные высоконагруженные системы, где кол-во ядер серверов БД 80 и более, можно предположить, что положительный эффект будет достигнут, причем не маленький.
В то же время при более правдоподобной нагрузке (создание и проведение документов в 1С:УТ 11) картина достаточно ровная, и, самое главное, с ярко выраженным положительным эффектом, что не может не радовать.

Практический эффект от технологии Resource Governor, на наш взгляд, видится именно в оперативном (и даже динамическом) режиме регулировки ресурсов сервера БД, когда их необходимо очень быстро распределить в зависимости от нагрузки на информационную систему. Особенно это важно для пиковых нагрузок на информационную систему – подготовка регламентированной отчетности, распродажи, акции и т.д.
Т.е. с помощью правильного и своевременного перераспределения ресурсов сервера БД можно очень хорошо минимизировать риски, связанные с простоями бизнеса. Например, как уже упоминалось выше, не должен кассир в магазине пробивать чек более 1 мин. Да и это много, даже если идет распродажа и информационная система непрерывно подвергается повышенным нагрузкам.
Для этих целей компания SOFTPOINT разработала новый продукт RESOURCE MANAGER.
Основное назначение продукта — гибкое распределение ресурсов серверов БД информационной системы в моменты пиковых нагрузок для приоритетных информационных потоков.
Потоков должно быть как минимум два, например, как в нашем нагрузочном тесте – OLTP и OLAP. Естественно, если в ИС всегда доминирует только один поток, то использование RG в ней не эффективно, т.к. увеличение производительности происходит именно за счет перераспределения ресурсов. Например, в ИС может присутствовать только OLTP составляющая (какая-нибудь биллинговая система) и регулировать что-либо в ней почти бессмысленно – поток один и он сам по себе имеет высокий приоритет.
Таким образом, Resource Manager (далее RM) решает две важные задачи:
1) Разделяет общий информационный поток ИС на отдельные составляющие и расставляет им приоритеты;
2) Распределяет ресурсы серверов БД между потоками в соответствии с приоритетами и с помощью технологии MSSQL Resource Governor.
Архитектурно RM представляет собой прокси-сервер, который «на лету» перехватывает запросы, ранжирует их и динамически управляет пулами ресурсов в Resource Governor (см. Рисунок 12).
Рисунок 12. SOFTPOINT RESOURCE MANAGER: Архитектура.

С пользовательской стороны RM позволяет делать следующее:

• интерактивный выбор информационных потоков. При этом 2 потока всегда присутствуют по умолчанию: OLTP и OLAP (все остальное));
• Создавать неограниченное число потоков, которыми необходимо управлять;
• Ранжировать созданные потоки. Потоки верхнего уровня будут «забирать» ресурсы у потоков нижних уровней;
• Назначать каждому потоку пороги по ресурсам.
• Контролировать эффективность устанавливаемых порогов и в случае обратного эффекта информировать об этом и откатывать настройки обратно.

Тут нужно понимать, что все эти настройки должны, конечно, устанавливаться не наобум. Специалисты (администраторы БД, системные администраторы) должны обладать необходимой квалификацией, чтобы понимать какими ресурсами сервера можно управлять в данной БД. Нужно провести вдумчивый анализ инцидентов и просто статистики производительности за последние периоды и только на этом основании проводить настройки.

Дополнение:

Помимо технологии Resource Governor для оперативного перераспределения ресурсов сервера между потоками RESOURCE MANAGER может использовать NUMA-технологии. Поскольку все современные многопроцессорные серверы используют NUMA-архитектуру, то RESOURCE MANAGER имеет возможность распределить потоки как по отдельным NUMA-узлам (процессор + банк памяти) или даже по отдельным ядрам процессоров. Применительно к нашему нагрузочному тестированию для потока OLTP можно выделить отдельный NUMA-узел, при превышении нагрузки на CPU больше некоторого порога. Это позволит обеспечить гарантированное выполнение OLTP-запросов, независимо от каких-либо дополнительных нагрузок.

Но это уже тема будущей статьи.

Подробнее о продукте SOFTPOINT RESOURCE MANAGER можно ознакомиться на сайте компании http://www.softpoint.ru/resource-manager.

В заключение хочется сказать, что технология Resource Governor очень интересная, и при правильном использовании позволяет добиться значительных результатов в увеличении производительности каких-то выбранных информационных потоков (читай пользователей). Основные недостатки технологии, которые обходятся с помощью SOFTPOINT RESOURCE MANAGER, как мы видим, следующие:

1. Для того что бы RG работал необходимо явное задание пользователей в SQL соединении, привязанных к группе. Большинство современных ИТ систем с трехзвенной архитектурой не поддерживают такой режим. То есть пул соединений от сервера приложений постоянно меняется. SOFTPOINT RESOURCE MANAGER позволяет на лету определять к какой группе относится запрос и передать на выполнение отдельному потоку с уже заданным пользователем. Соответственно результат выполнения будет передан обратно в изначальный поток (соединение).
2. В большинстве случаев пользователь может выполнять как OLTP-запросы так и OLAP. Получается, что явное определение такого пользователя в одну или иную группу будет неэффективным. SOFTPOINT RESOURCE MANAGER позволяет на лету определить по определенной сигнатуре тип запроса и выполнять под соединением оптимальной группы. К примеру, он умеет определять явное открытие и закрытие транзакций и по этом принципу все запросы, содержащиеся в рамках транзакции выполнять в OLTP-соединении. Это существенно снижает эскалацию блокировок в случае пиковых загрузок.
3. Выделение квот ресурсов для группы в RG необходимо задавать, обладая большим опытом DBA. В противном случае эффект может быть отрицательным. В SOFTPOINT RESOURCE MANAGER есть возможность подключения подсистемы мониторинга производительностью на основе продукта SOFTPOINT PERFEXPERT. Она позволяет на лету (в зависимости от возникновения пиковой нагрузки) менять квоты ресурсов для RG, а также на лету применять данный режим либо отказываться от него.

Авторы: А.Осипов, А.Денисов, В.Сердюк, П.Баркетов.