Первый шаг при работе с новыми вычислительными ресурсами, — неважно, строим ли мы их сами, или арендуем в облаке, — это оценка производительности. Для этого проводится ряд тестов, определяющих производительность нового стенда по отношению к существующему.
В идеальном мире такой тест проводится «по живому»: система копируется на новый стенд и проводится эмуляция реальной нагрузки. Но такой путь слишком трудоемкий, поэтому в реальном мире используются синтетические тесты.
Мне всегда было интересно измерить производительность наших систем и посмотреть на их место в мировых рейтингах. Кроме того, время от времени возникают задачи нагрузить сервер реальной нагрузкой и посмотреть, как ведет себя железо.
И сегодня я расскажу, как с помощью теста TPC-C измерить производительность стенда и получить результат в стандартных транзакциях в секунду.
Для начала вспомним, какие бывают синтетические тесты. Для процессоров подойдет 7-Zip Benchmark, для дисков — CrystalDiskMark. С их помощью мы можем очень быстро посмотреть, насколько быстро работает наш стенд на алгоритмах, заложенных в эти (!) тесты. Штука в том, что в нашей системе, для которой предназначен стенд, точно будут использоваться другие алгоритмы. И с этим приходится как-то жить.
Для более точных результатов тестирования дисков есть SQLIO или FIO. Обязательно прочитайте две исторические статьи amarao о тестировании дисков — раз и два, и свежую статью коллеги. По этим статьям вы научитесь правильно применять этот сложный тест.
Так почему же я выбрал TPC-тестирование для оценки производительности? TPC разрабатывает тесты, направленные на обработку данных, с 1988 года. Эти тесты давно стали индустриальным стандартом, их используют почти все вендоры оборудования и публикуют результаты, которых они достигают на различных образцах аппаратного и программного обеспечения.
Так как большинство бизнес-систем, для которых критична производительность, являются реляционными базами данных, то для нас наибольший интерес представляет тест TPC-C. Это комплексный тест, генерирующий многопользовательскую OLTP нагрузку из различных транзакций. Для его прохождения в базе данных генерируется набор данных, характерный для бизнес-систем, связанных с продажами или производством товаров и сервисов. TPC-C можно дополнить тестом TPC-H для эмуляции нагрузки OLAP системы.
Кто-то может сказать, что тестам более 10 лет. Но заложенный в них принцип обработки данных применяется практически в каждой бизнес-системе. И именно поэтому они подходят для симуляции реальной нагрузки.
Для проведения TPC-C теста мы будем использовать Open source проект HammerDB.
Параметры виртуальной машины для тестирования:
- 4 vCPU 3ГГц,
- 64 ГБ оперативной памяти,
- диск на общей СХД с SSD дисками.
Почему такие параметры? Меньшее число процессоров на серверах с СУБД бывает редко, памяти для СУБД много не бывает, ну а на жесткие диски ее класть — себе дороже.
Установленное на машину ПО:
- Microsoft Windows 2016 x64,
- Microsoft SQL Server 2017 (не Express edition; или же следим за максимальным объемом базы данных),
- SQL Server Management Studio,
- и собственно HammerDB.
Конечно, можно разнести HammerDB и SQL сервер на разные ВМ/сервера для изоляции нагрузки пользователей от нагрузки сервера, что довольно правильно. Но в другой раз.
А теперь начнем тест.
- Первым шагом с помощью SQL Server Management Studio создаем базу данных для тестов и размещаем ее на отдельном диске — так у вас будет выше карма.
- Далее запускаем HammerDB.
- Выбираем MS SQL, TPC-C.
- Заполняем параметры подключения к MS SQL:
- количество складов: можно начать с десяти, но для реальных тестов нужно, например, 2000,
- количество виртуальных пользователей: удвоенное количество наших процессоров.
- Жмем Ок и ждем.
- Наша база данных наполняется данными, растет. Для 2000 складов размер базы данных на диске — порядка 250 ГБ.
- После того, как база заполнилась (это может занять несколько часов), нам нужно сгенерировать Driver Script — сценарий тестирования.
- Задаем условия:
- ограничение теста во времени — 20 минут,
- время «разгона» теста — 5 минут. Это ограничение нужно, чтобы не «положить» систему резким стартом.
- Жмем Ok и переходим в Load.
Наш тестовый скрипт готов. - Задаем условия:
- Переходим в Virtual Users и задаем количество пользователей.
В нашем случае — 200 пользователей, но вообще рекомендуется выставлять в 10 раз меньше пользователей, чем складов.Здесь же выбираем Show Output, чтобы результаты теста были видны в момент его работы, и Log Output to Temp для генерации текстового файла с результатами теста.
Нажимаем Create, Run!
У наших Virtual Users изменился статус. - Переходим на Transaction Counter и смотрим, запустился ли наш тест.
Ура, все очень просто — и тест работает!
Вот так отображаются результаты теста после запуска. - Ждем 5 минут. Нагрузка приходит к плановой; показатели, в моем случае, улучшились.
- Теперь посмотрим на результаты со стороны виртуализации. И вот что мы видим.
- Процессоры ВМ во время теста были нагружены практически на 100%:
- Память использовалась довольно активно:
- В дисковых операциях преобладало чтение, задержки на ожидаемом уровне:
- Процессоры ВМ во время теста были нагружены практически на 100%:
Итак, все довольно просто и теперь у нас есть ВМ с эталонным тестом. Перемещая ее по различным стендам, мы можем оценить их относительную производительность.
И напоследок полезный совет. Во время теста постарайтесь снять все возможные графики производительности компонентов вашей системы. По ним вы увидите, что стало «узким местом» при прохождении теста. Достаточно ли вы нагрузили систему, или излишне. Может быть стоит вернуться на шаг настройки теста и поменять значения.
Кому-то этот текст может показаться очень простым. Но я еще не встречал на русском языке ответа на вопрос: «Как мне измерить производительность нашей системы в TPC-C?» Enjoy! :-)
Автор: Михаил Соловьев
