Производительность СУБД и тесты TPC

--> Дата: Фев 18, 2008 856

Михаил Елашкин,
директор компании Elashkin Research

Подробное исследование "Оценка производительности программно-аппаратных решений"
можно найти на сайте http://www.elashkin.com.

Вопросы тестирования и настройки производительности компьютерных систем всегда
находились в центре внимания разработчиков. Первые реляционные системы управления
базами данных не отличались высокой производительностью, поэтому практически
сразу встали вопросы их настройки и создания тестов, имитирующих нагрузку в
ходе реальной работы. Клиент-серверная революция только начиналась, персональные
компьютеры еще были игрушками, а СУБД разрабатывались для больших компьютеров
и мэйнфреймов. Созданием тестов занимались профессионалы, которым было прекрасно
известно, что максимальной производительности можно достичь только совместной
настройкой ПО и "железа". В результате сегодняшние системы тестирования производительности
СУБД впитали все лучшее, что было наработано компьютерным сообществом за годы
развития.

Естественно, первые системы тестирования производительности в значительной степени были ориентированы на одноуровневую архитектуру (мэйнфрейм — терминал), но, во-первых, это отражало состояние индустрии на тот момент, а во-вторых, эти недочеты были быстро исправлены.

К сожалению, существовавшая в СССР культура работы с "тяжелыми" системами была в значительной степени утрачена в России после массового и не всегда обоснованного увлечения персональными компьютерами. Многие современные программисты начинали свою карьеру именно с "персоналок", в то время как их коллеги на Западе сначала проходили хорошую школу университетских вычислительных центров и больших машин — может быть, не самую эффективную сегодня, но ставящую правильное ИТ-мышление. И не случайно — как показал опрос ведущих специалистов российских и западных компаний, поставляющих программное и аппаратное обеспечение для "тяжелых" решений, — осведомленность заказчиков о тестах производительности обработки транзакций составляет 2,7 балла по 5-балльной шкале. Данная статья ставит своей целью восполнить этот пробел и показать, как такие тесты могут быть использованы в процессе выбора решений для современных информационных систем.

Классификация тестов

Если обратиться к данным, которые предоставляют производители серверов, или к компьютерным журналам, легко запутаться в разнообразных тестах. Для лучшего понимания особенностей различных тестов введем их классификацию.

В первую очередь тесты делятся на компонентные и интегральные. Первые оценивают производительность одного или нескольких компонентов: процессоров, памяти, систем ввода-вывода, дисков, сетевых адаптеров и т. п. Наиболее известны из них тесты SPEC (Standard Performance Evaluation Corporation), такие, как CPU2000. Обычно производители ссылаются не на общее название CPU2000, а на метрики этого теста: SPECint2000, SPECfp2000 и SPECint_rate2000, SPECfp_rate2000. Разница между этими тестами в основном заключается в том, проводится ли оптимизация кода для всех тестов вместе (одинаковые параметры компиляции и т. п.) или для каждого теста в пакете в отдельности. Часто также встречаются обозначения CINT2000 и CFP2000 — это просто подмножества CPU2000 для операций с целыми числами и для чисел с плавающей точкой.

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

Таблица 1. Сравнение интегральных и компонентных тестов

Модель	Процессор	Число процессоров	CINT2000 Rate	TPC-C, tpmC
IBM eServer pSeries 660 Model 6M1	IBM RS64 IV 750MHz	8	36,9	105,025
Fujitsu PrimePower 850	Fujitsu SPARC64 GP 675MHz	16	82,5	112,286

Обратите внимание, что производительность этих систем по компонентным тестам
SPEC различается более чем в два раза, в то время как на задачах обработки транзакций
менее производительная по тестам SPEC система опережает более производительную.

Таким образом, компонентные тесты не могут служить ориентиром для оценки производительности всей системы, особенно при работе реального приложения. Такую оценку можно получить только при помощи интегральных тестов, обеспечивающих адекватную нагрузку на все компоненты системы. Кроме того, разные задачи по-разному нагружают тестируемую систему, и из множества тестов (TPC, SPECjAppServer2001, SPECweb99, DirectoryMark, AuthMark и многих других) необходимо выбрать тот, который в наибольшей степени соответствует задаче тестирования.

Тесты, оценивающие производительность систем обработки транзакций, появились в середине 80-х годов прошлого века, когда начался новый этап развития компьютерных технологий и их применения в бизнесе. Этот этап характеризовался значительным ростом транзакций в режиме on-line, таких, как транзакции, проводимые кассиром банка или продавцом авиабилетов. Такие вычисления заметно отличались от пакетной обработки данных, характерной для бизнеса 60-х и 70-х годов, и для их обработки был предложен термин On-Line Transactions Processing, или OLTP. Для оценки производительности этих систем первоначально использовался тест TP1, предложенный корпорацией IBM, и его модификации.

В процессе развития СУБД появилось еще несколько различных тестов их производительности, но фактически стандартом индустрии сегодня считаются универсальные интегральные тесты TPC.

Тесты TPC

Transaction Processing Performance Council, TPC (Совет по обработке транзакций,
http://www.tpc.org) — независимая некоммерческая
организация, созданная для исследования обработки транзакций и производительности
СУБД и распространения объективной и воспроизводимой информации о производительности
в тестах TPC для компьютерной индустрии. Кроме оценки производительности, в
рамках тестов TPC рассчитывается относительный критерий производительность/стоимость,
позволяющий оценить стоимость программного и аппаратного обеспечения и стоимость
владения системой в ходе ее эксплуатации.

В настоящее время TPC — это наиболее авторитетная организация в мире, проводящая
тестирование производительности бизнес-систем. Первоначально Совет по обработке
транзакций фокусировался на компьютерном аспекте создания тестов оценки производительности
OLTP-систем, но вскоре был вынужден начать работу по стандартизации процедуры
представления результатов и участия в тестах. Сегодня тесты TPC — это не только
техническая спецификация, но и формализованная процедура проведения тестов,
представления результатов, а также обязательный аудит результатов независимой
аудиторской компанией. Можно не соглашаться с техническими аспектами тестов
и их соответствием реальным условиям эксплуатации бизнес-приложений, но TPC
пользуется авторитетом в мире, и ее результаты действительно независимы и воспроизводимы.
Членство в Совете практически всех основных игроков на этом рынке, политика
аудита и одобрения представленных результатов всеми членами Совета исключает
ситуацию, при которой кто-либо из производителей аппаратного или программного
обеспечения мог бы использовать авторитет Совета в своих целях. В настоящее
время в TPC входят большинство производителей аппаратного и программного обеспечения,
имеющих отношение к системам управления базами данных (Fujitsu, HP, IBM, Microsoft,
Oracle, Sun и т. д.). Полностью с составом Совета, спецификацией тестов и последними
результатами можно ознакомиться на официальном сайте TPC (http://www.tpc.org).

В разные периоды развития индустрии существовали различные модификации тестов TPC. Список официально утвержденных тестов приведен в табл. 2. Были предложены еще тесты TPC-S, TPC-E и TPC-C/S, но они не были приняты на заседании Совета. Рассмотрим подробнее актуальные на сегодня тесты TPC.

Таблица 2. Список тестов TPC

Тест	Краткое описание	Текущая версия
TPC-A	Выполнение одиночных транзакций в архитектуре клиент-сервер	Поддержка прекращена с июня 1995 г. Последняя версия 2.0
TPC-B	Выполнение транзакций "внутри" СУБД, отсутствуют клиентские сессии. Может рассматриваться как stress test СУБД	Поддержка прекращена с июня 1995 г. Последняя версия 2.0
TPC-C	Индустриальный стандарт де-факто в области OLTP-систем	Текущая версия 5.1. Версия 5.2 действует с февраля 2004 г.
TPC-D	Системы поддержки принятия решений, усложненные, требующие времени запросы к большим сложным структурам данных	Поддержка прекращена с июня 1999 г. Последняя версия 2.1
TPC-H	Запросы ad hoc, системы поддержки принятия решений	Пришел на смену TPC-D. Текущая версия 2.1.0
TPC-R	Системы поддержки принятия решений, подготовка отчетов. Отличается от TPC-H тем, что разрешена оптимизация структуры СУБД на основе информации о возможных типах запросов	Текущая версия 2.1.0
TPC-W	Тесты производительности систем электронной коммерции для Web	Текущая версия 1.8. Версия 2.0 — в стадии обсуждения

TPC-C

TPC-C — один из наиболее удачных тестов TPC, ставший де-факто отраслевым стандартом. Первая версия этого теста была принята в июле 1992 г. TPC-C — это более комплексный тест, чем существовавшие ранее, такие, как TPC-A. В него входит набор параллельно выполняемых транзакций различных типов и сложности. База данных в тесте TPC-C состоит из девяти типов таблиц большого размера, содержащих широкий диапазон значений. Результаты теста даются в числе транзакций в такой системе в минуту (tpmC). Соотношение цена/производительность измеряется как стоимость одной транзакции в данном тесте. Каждый принятый TPC результат содержит подробную информацию об использованном оборудовании, ПО и стоимости владения. Если необходимо, можно пересчитать этот параметр, используя свои данные с учетом скидок, предоставляемых именно вашей компании производителями, и получить собственные данные.

С точки зрения бизнес-процессов TPC-C симулирует компьютерную среду, в которой множество пользователей выполняют транзакции с использованием данных, хранящихся в СУБД. Подобная бизнес-активность характерна для систем ввода заказов, вне зависимости от области деятельности, будь то система управления предприятием или заказ авиабилетов. Этот тест включает симуляцию ввода заказов, выдачи накладных, внесения информации о платежах, проверки состояния заказов и отслеживания состояния склада. Нагрузка на систему и структура базы данных выбраны таким образом, чтобы они не несли в себе специфики какой-то конкретной отрасли, но отражали усредненный бизнес, связанный с управлением, продажами или дистрибуцией неких товаров или услуг.

TPC-H

Тест TPC-H оценивает производительность систем поддержки принятия решений (СППР). Он состоит из набора сложных, бизнес-ориентированных запросов ad hoc* . Как и в остальных тестах, симулируется поступление запросов от большого числа пользователей. Данные в таблицах и запросы подобраны так, чтобы отражать некоторую усредненную по индустрии бизнес-активность. Типичные запросы составлены так, чтобы соответствовать основным типам запросов в СППР: ценообразование и скидки, управление прибылью, исследование предпочтений покупателей, исследования рынка и т. п.

*Ad hoc (лат.) — "к этому, для данного случая, для этой цели", т. е. запросы,
возникшие в текущий момент, которые нельзя было предусмотреть заранее. — Прим.
авт.

Важное отличие TPC-H от его предшественника, TPC-D, — возможность продолжать обработку транзакций с тестовой базой данных. Таким образом, выполнение запросов TPC-H не требует отключения СУБД от других операций.

С тестами TPC-H практически полностью совпадают тесты TPC-R (по сути одна и та же спецификация, в которой часто путают тесты TPC-R и TPC-H). Основное различие между ними заключается в том, что характер запросов в TPC-R считается известным и разрешается связанная с этим оптимизация.

TPC-W

Тесты TPC-W определяют производительность транзакций системы для задач электронной коммерции. В этом тесте нагрузка ложится не только на сервер базы данных, но и на Web-сервер, кэш-сервер, систему хранения изображений и СУБД. В тесте симулируются нагрузки, для которых характерно следующее:

множественные соединения с клиентами (браузерами);
создание, обновление и доступ к динамическим Web-страницам;
использование consistent Web-объектов;
одновременное исполнение множества разнородных транзакций;
OLTP-модель;
сложная структура СУБД;
целостность транзакций;
конкурентный доступ к данным и изменение данных.

Тест поддерживает три различных профиля взаимодействия с пользователями:

WIPS — покупки (интегральный параметр);
WIPSb — просмотр (дополнительная метрика);
WIPSo — ввод заказов (дополнительная метрика).

Профиль WIPSb соответствует ситуации, когда большая часть посетителей (95%) просто просматривает содержание сайта, а оставшиеся 5% выполняют ввод заказов. Профиль WIPSo подразумевает преимущественный (50%) ввод заказов. Этот профиль дает значительно большую нагрузку в связанной с СУБД части теста. Производительность измеряется в единицах WIPS (Web Interactions per Second).

Тесты TPC-W — одни из самых комплексных, проводимых TPC. В этом тесте симулируется доступ к 14 типичным страницам в типичных Интернет-задачах (базовая страница, поиск, новые продукты, лучшие покупки и т. п.). При этом выбор страниц осуществляется не по случайному механизму, а в соответствии с элементами навигации на них. Поведение покупателя тоже воссоздается в соответствии с типичными моделями поведения, полученными в реальных системах и усредненными.

Плюсы и минусы

Самым престижным из всех тестов TPC считается TPC-C, именно его результаты чаще всего приводят в своих презентациях производители серверов и СУБД. В целом это весьма удачный и хорошо проработанный тест, но его популярность сыграла с ним дурную шутку. Соревнование брэндов в области производительности привело к тому, что на достижение высоких результатов были брошены значительные силы лучших производителей. Как следствие, быстро были обнаружены слабые места теста. Дело в том, что схема СУБД и использованные транзакции очень просты и их легко распараллелить для использования в кластере. В результате долгое время верхнюю позицию в таблице рекордов занимала СУБД Microsoft SQL Server в кластерной конфигурации. Федеративная архитектура (shared nothing), не эффективная в большинстве реальных приложений, в условиях тестов TPC-C показывает очень высокие результаты. В результате Совету TPC пришлось вводить специальные номинации для результатов, полученных на кластерах и на отдельных машинах.

Другая потенциальная уязвимость тестов связана с особенностью современных процессоров: объем кэш-памяти в них настолько велик, что большая часть задачи помещается в кэш процессора, так что вместо тестирования производительности всей системы задача сводится к тестированию производительности обмена процессор — память.

Можно также отметить, что тесты TPC-C проводятся только в двухуровневой архитектуре клиент-сервер, в то время как большая часть современных систем разрабатывается в трехуровневой (клиент — сервер приложений — сервер) или распределенной архитектурах. Модель данных слишком проста и содержит только пять типов транзакций, в то время как реальные системы используют гораздо больше типов транзакций, причем некоторые из них встречаются заметно реже других, но требуют существенно больше ресурсов.

Еще одна, внешне не самая важная, особенность тестов заключается в том, что само тестирование проходит в течение 20 мин, а никаких критериев, оценивающих надежность системы в тестах, не предусмотрено. В результате многие производители устанавливают в тестовых системах недорогие дисковые массивы, заведомо менее надежные, чем требуется для эксплуатации в реальных условиях. В результате такой важный критерий, как стоимость в расчете на транзакцию, становится малоинформативным. Вообще, тестовая конфигурация серверов обычно максимально настроена именно на производительность в тестах TPC: файлы журналов и данные стараются разнести не только на разные диски, но и на RAID-массивы и контроллеры. Точно такая же конфигурация никогда не будет использована в реальных проектах.

В результате тесты в значительной степени выродились в некий аналог "Формулы-1" для ИТ-индустрии, где могут соревноваться только команды, обладающие миллионными бюджетами. Соответственно популярность тестов среди экспертов не очень высока. Так, технические сотрудники ведущих компаний-производителей оценили значимость TPC-тестов для оценки производительности в 3,7 балла по 5-балльной шкале.

Однако такое критическое отношение к тестам TPC не означает, что их результаты не могут быть использованы в процессе выбора и сравнения различных систем. В качестве примера корректного анализа данных тестов рассмотрим одну из популярных сегодня тем: использование Linux и сравнение этой ОС с Windows и Unix. В табл. 3 приведены результаты тестов TPC-C различного ПО на идентичных компьютерах (использовался сервер HP Integrity rx5670).

Таблица 3. Показатели различных операционных систем и СУБД при работе на HP
Integrity rx5670

ОС	Red Hat Enterprise Linux AS 3	Microsoft Windows Server 2003 Enterprise Edition	HP UX 11.i, v2 64-bit base
СУБД	Oracle 10g Database Standard Edition	Microsoft SQL Server 2000 Enterprise Edition 64-bit	Oracle 10g Database Standard Edition
Процессоры	4xItanium 2	4xItanium 2	4xItanium 2
Память, Гбайт	96	64	96
Жесткие диски, Гбайт	6844	8272	4634
TPC-C, tpmC	136111	121065	131640
Стоимость, долл./tpmC	3,94	4,49	7,25

Это сырые данные, которые приведены в сводной таблице на сайте TPC. На первый
взгляд можно показаться, что Unix-системы почти в два раза проигрывают по критерию
стоимости транзакции (долл./tpmC). Для понимания реальной ситуации необходимо
проанализировать данные более подробно, прочитав полное описание тестов (на
сайте TPC для каждого теста, кроме сводной таблицы, размещены еще два файла:
краткое описание и полный протокол испытаний). Анализ этой информации показывает,
что высокая стоимость Unix-системы обусловлена использованием гораздо более
дорогой системы хранения. Вопрос о том, почему была выбрана именно такая система,
остается открытым, но в остальном стоимость Unix-системы сопоставима со стоимостью
систем под управлением Linux и Windows. Сравнивая между собой Linux и Windows,
можно отметить, что "бесплатность" Linux не играет здесь особой роли. При общей
стоимости таких систем более 500 тыс. долл. разница в стоимости Windows и Linux
(с технической поддержкой на 3 года) составляет менее 7 тыс. долл.

Вопрос сравнения производительности более сложен, так как разница в этих показателях очень невелика. При этом производительность Oracle в среде Linux и Unix практически одинакова, а для платформы Microsoft не ясно, что вносит основной вклад — операционная система или СУБД. Для корректного сравнения не хватает данных о работе Oracle в среде Windows и SQL Server в среде Linux, появление которых маловероятно или невозможно. В любом случае, разница в производительности в 10% невелика и для тестов TPC лежит в пределах колебаний, зависящих от настроек системы.

Это только один пример того, как можно использовать результаты тестов TPC. Существует еще много задач, связанных с выбором серверов и ПО, где можно использовать эти общедоступные данные: сравнение серверов различных производителей, сравнение различных линеек серверов одного производителя, коэффициент масштабируемости производительности при увеличении числа узлов в кластерах или числа процессоров в SMP-машинах (вопреки довольно распространенному мнению, при удвоении числа узлов или процессоров производительность растет на 70-75%) и т. д. С другой стороны, тесты TPC не подходят для выбора конкретной спецификации сервера (сайзинга) в силу того, что в основе тестов лежат модельные задачи, возможно, весьма далекие от реального приложения, которое будет работать у заказчика.

Основная польза от тестов TPC на этапе выбора программно-аппаратного решения заключается в сравнительном анализе технологий различных производителей. Данные о стоимости, полученные в тестах TPC, позволяют оценить соотношение стоимость/эффективность для тех или иных технологий и развеять некоторые мифы относительно "дорогих" или "дешевых" решений. Но при этом недостаточно просто сравнить цифры между собой — необходимо тщательно проанализировать все данные, предоставленные Совету TPC. И наконец, следует четко понимать, что тесты TPC применимы для оценки производительности OLTP-задач и хранилищ данных в двухуровневой архитектуре клиент-сервер. Для оценки производительности Web-систем и серверов приложений на базе J2EE следует применять тесты SPEC или соответствующие тесты других разработчиков.