Оценка ресурсов сервера промышленной базы - Петер

IT-ПАРК
Оценка ресурсов сервера промышленной
базы данных биллинговой системы
А.Е. КИСЕЛЕВ, главный специалист ЗАО “ПЕТЕР-СЕРВИС”
R t = St + Q t .
На рисунке показано, что с некоторого уровня интенсивности
поступления запросов начинается
резкий рост времени отклика за
счет увеличения времени ожидания. Будем считать, что система
справляется с нагрузкой, если способна обеспечить требуемое время отклика. При этом используют
три подхода:
“Вестник связи” № 6 '2011
тестовые нагрузочные модели;
сайзинги поставщика системы
(расчет требуемого оборудования
на основе данных нагрузочного тестирования);
математические модели, использующие накопленную статистику работы существующей системы.
Для тестовой нагрузочной
модели создается стенд, являющийся копией предполагаемого
оборудования и ИС, на который
подают тестовую нагрузку. Такая
модель обладает достаточной
точностью, но требует больших
затрат на покупку или аренду
оборудования, причем в разных
конфигурациях. Сайзинговые модели — дешевле, но базируются
на среднестатистических характеристиках используемых систем
и могут не достаточно корректно
отображать их работу.
Рассмотрим математическую
модель прогноза производительности системы, которая не требует существенных затрат, позво-
Время отклика
10
9
8
7
6
5
4
3
2
1
0
0,0
0,2
0,5
0,7
1,0
Интенсивность поступления заявок
ляет легко менять параметры и
рассматривать разные целевые
конфигурации.
Моделирование подсистем
CPU и IO
Основными дефицитными ресурсами сервера баз данных являются
обычно подсистемы CPU и вводавывода (IO), которые можно представить в виде модели из набора
обслуживающих серверов и очередей заявок к ним.
В наиболее распространенных
компьютерных системах с массовым параллельным обслуживанием (SMP) одна подсистема CPU может обслуживать любое задание,
поэтому ее можно рассматривать
как набор серверов, разделяющих
одну общую очередь заданий.
В подсистеме IO каждое задание (операция чтения или записи) выполняется на конкретном
устройстве (физическом или логическом), которое должно иметь
свою очередь заданий. То есть
ms/trx
ри эксплуатации информационных систем (ИС), в том числе
биллинговых, часто возникают вопросы:
ожидается ли рост бизнеса на х %;
справится ли существующая
система с увеличением нагрузки;
хватит ли ее мощности для обслуживания абонентской базы, которая увеличится в два раза в результате присоединения филиала,
а если нет, то сколько и каких ресурсов потребуется добавить?
Для получения ответа следует
перейти от терминологии управления бизнесом к техническим
параметрам, которые можно использовать в расчетах, и прежде
всего определиться, что несет в
себе фраза “система справляется с нагрузкой”. Для IT-систем —
это поддержание уровня сервиса
(Service Level), оговоренного в соглашении об уровне обслуживания (SLA, Service Level Agreement).
Например, способность системы
обслужить определенный объем
запросов со временем отклика при
этом — не хуже некоторой установленной границы.
Ключевым понятием здесь является время отклика (R t), которое
состоит из времени ожидания в
очереди на обслуживание (Qt) и
времени обслуживания (St) запроса (задания):
П
Ожидание
Время
обслуживания
1,2
1,5
(trx/ms)
1,7
1,9
Время
отклика
2,2
2,4
Классическая зависимость времени отклика от интенсивности заявок
47
IT-ПАРК
Таблица 1
Статистические показатели ошибки для разных метрик
Статистика, используемая
в качестве метрики
Среднеквадратичное Стандартная
отклонение ошибки, % ошибка, %
Logical Reads Per Sec
±9,7
0,52
Executions Per Sec
±7,9
0,43
User Calls Per Sec
±7,8
0,42
IO можно рассматривать как набор систем из пар устройство —
очередь. Подобного рода модели
описывает теория массового обслуживания, в частности M/M/m,
которая подходит для рассматриваемых компьютерных систем.
В нашей модели среднее время обслуживания запроса S t будем считать постоянным. Когда
интенсивность запросов мала,
время
отклика
практически
равно времени обслуживания.
Если в систему начинает поступать больше запросов, образуется очередь на обслуживание,
и время отклика возрастает. С
определенного уровня интенсивности поступления запросов
время ожидания в очереди, а с
ним и время отклика, начинают
стремительно расти, а производительность системы — падать.
Для современных компьютерных
систем с процессорной SMPархитектурой такой точкой считается уровень утилизации их
ресурса в 70 — 80 %. Для подсистемы IO он будет примерно 60
— 65 %, а для старых IO-систем
— вдвое меньше (35 %). Разница между подсистемами вызвана тем, что у IO задание (или его
часть) должно обрабатываться
конкретным устройством, очередь к которому может стать
узким местом при неравномерном распределении запросов.
Пример расчета ресурсов CPU
При планировании необходимых
аппаратных ресурсов не обязательно рассчитывать время отклика, достаточно обеспечить
48
нужный уровень утилизации (загрузки) системы.
Пусть биллинговая система
функционирует на СУБД Oracle и
32-ядерном сервере. В ней ожидается запуск дополнительного,
постоянно работающего процесса, например, расчет скидочных
и бонусных баллов. Требуется
определить: способна ли система
справиться с увеличением нагрузки с учетом ожидаемого роста абонентской базы (на 200 тыс.), а если
нет, то сколько CPU (ядер) надо
установить дополнительно.
Для применения теории массового обслуживания, прежде
всего, следует выбрать единицу работы (ранее — “заявка” или “запрос” в систему).
Для простых случаев это может
быть
бизнес-транзакция,
например “оформление заказа”
для Интернет-магазина или “обращение
пользователя”
для
CRM-системы. Для сложной системы выделить одну “бизнестранзакцию” трудно. Например,
в биллинговой системе одновременно функционирует много
подсистем, которые выполняют
бизнес-транзакции
абсолютно
разного объема и затратности
по ресурсам (тарификация вызовов, расчет абонентской платы, бонусов, прием платежей и
т. п.). Если выделить определенный
проблемный промежуток времени и конкретный процесс, то для
расчетов можно взять его основную бизнес-транзакцию.
В случае сложных систем для
определения единицы нагрузки
можно опуститься на уровень сервера баз данных и использовать
его статистику (например, для
Oracle это могут быть user calls,
user transactions). К. Миллсап в
работе “Оптимизация производительности” рекомендует, как весьма подходящую, статистику logical
reads.
Использование в качестве метрики рабочей нагрузки подобных
статистик потребует собрать множество отсчетов статистик базы
данных и соответствующих им
величин утилизации CPU со стороны операционной системы за
некоторый промежуток времени
(такие СУБД, как Oracle, c версии
10g собирают и хранят нужную
информацию в Automatic Worklod
Repositary).
Чтобы выбрать наиболее подходящую статистику, характеризующую нагрузку и точность
прогноза, требуется провести
валидацию модели. Для этого
оценим статистические показатели величины ошибки (разность
между предсказанным и фактическим значением утилизации
CPU) при использовании разных
метрик базы данных Oracle 10g
(табл. 1). Прогноз выглядит грубоватым, хотя для оценки необходимых аппаратных ресурсов
точности в 8 — 10 % вполне достаточно. Для уточнения расчета в качестве метрики рабочей
нагрузки (число условных транзакций в секунду, trx/sec) можно
построить комплексную метрику,
включив в нее все три типа метрик: Trx/sес = k1 х (Logical Reads
Per Sес) + k2 х (User Calls Per Sес) +
+ k3 х (Executions Per Sес).
Лучшая точность прогноза (±6 %)
была получена при коэффициентах: k1=1; k2=250; k3=20.
Для выполнения расчетов нам
надо получить опорную точку для
модели, в данном случае пару
Trx/sес и Host CPU Utilization (%).
При этом важно правильно выбрать период усреднения, обычно это время ЧНН, поскольку мы
прогнозируем ресурсы, которые
должны обеспечить эффективную работу при максимальной
нагрузке. В исследуемом случае
период наибольшей нагрузки —
с 10:00 до 20:00.
“Вестник связи” № 6 '2011
IT-ПАРК
Таблица 2
Прогноз на основе средней нагрузки в дневное время
Абонентская база,
создающая среднюю нагрузку
Прогнозируемая утилизация CPU, %
Средняя нагрузка
в дневное время,
условных trx/sес
32 ядра
40 ядер
48 ядер
При текущей
При увеличении
интенсивности 514 trx/sес
интенсивности на 5 %
на 1 тыс. абонентов
2268688
62,2
49,7
41,4
4416000
4205000
2495556,8
68,4
54,7
45,6
4857000
4626000
2722425,6
74,6
59,7
49,7
5299000
5046000
2949294,4
80,8
64,6
53,9
5740000
5467000
3176163,2
87
69,6
58
6182000
5887000
3403032
93,2
74,6
62,2
6623000
6308000
3629900,8
99,4
79,6
66,3
7065000
6728000
3856769,6
105,7
84,5
70,4
7506000
7149000
Используя агрегирование в отношении имеющегося у нас набора
статистик, характеризующих нагрузку применительно к исследуемому периоду, получим следующую опорную точку:
среднее число условных транзакций — λq= 2268868;
средневзвешенная утилизация
CPU — U= 62,2 %;
среднеквадратичное отклонение для утилизации CPU — R 2=7,8.
Исходя из этих данных, утилизация CPU составляет 61±13 % в
течение 90 % дневного времени
(принято, что утилизация имеет
нормальное распределение, тогда
90 % отсчетов находятся в интервале ±R 2×1,645).
Время
обслуживания
(St)
определим, используя формулу
St = U×m/λq, где число CPU — m=32.
St = 0,622×32/2268868=0,000008766 с
на одну условную транзакцию.
Теперь можно рассчитать утилизацию (U) для разного количества CPU и различных величин рабочей нагрузки (λq) или, например,
число CPU при использовании более быстрых процессоров и соответствующем сокращении времени обслуживания (St).
После расчета прогноза CPU на
основании искусственной метри-
“Вестник связи” № 6 '2011
ки рабочей нагрузки (табл. 2) можем оценить область комфортной
зоны (выделена зеленым), некомфортной зоны, где загрузка CPU
в течение 90 % дневного времени
составляет 75 — 90 % (желтая), розовую зону (перегрузки CPU выше
90 %) и красную зону.
Согласно условиям задачи в
связи с введением новой функциональности и увеличением числа
абонентов на 200 тыс. появится
дополнительная нагрузка. Предположим, что при тестировании
новой функциональности было
выявлено, что при текущей абонентской базе она создает дополнительную нагрузку в 154560
условных транзакций в секунду
(примерно 35 trx/sес на одну тысячу активных абонентов). Считая,
что соотношение числа условных
транзакций к величине абонентской базы сохранится, рассчитаем уровень нагрузки после увеличения абонентской базы:
λq ожид. = (4416+200 тыс.)
х(514+35 trx/sес) = 2534184 trx/sес.
Как видим, чтобы остаться в зеленой зоне, при увеличении абонентской базы на 200 тыс. пользователей и нагрузки на 5 %, нам
придется перейти на систему с
40 ядрами, и утилизация CPU не
будет превышать 75 % (в течение
90 % дневного времени).
Заключение
В данной статье мы рассмотрели
метод оценки ресурсов сервера
базы данных на основе математической модели теории массового
обслуживания. При наличии готовых наработок он позволяет очень
быстро и с небольшими затратами
сделать прогноз о необходимых
ресурсах оборудования. Следует
иметь в виду, что модель M/M/m
является оптимистической, в том
смысле, что не учитывает ограничения на масштабируемость, за
исключением эффекта очередей.
Но никакие реальные многопроцессорные системы не являются
линейно масштабируемыми. Для
учета этого и повышения качества
прогноза можно перейти в расчетах от “физических” к “эффективным CPU”, принимая во внимание
коэффициент масштабирования
реальной системы.
Надеюсь, приведенный материал поможет снизить риски, возникающие при эксплуатации и развитии сложных систем на базе СУБД
Oracle.
49