В этой статье мы продолжаем знакомится с серверными тестами OSDL Database Test Suite. от Open Source Development Lab, начатое в первой статье цикла. Сегодня подробно остановимся на тесте OSDL-DBT-2.
Пакет тестов OSDL Database Test 2 (OSDL-DBT-2) имитирует оперативную обработку транзакций (OLTP) с помощью базы данных с открытым исходным кодом (SAP DB) и набора определенных транзакций. OSDL-DBT-2 является производной тестовых спецификаций TPC-C.
Краткое описание набора тестов TPC-C
TPC-C представляет активность базы данных любой компании, которая продает и распространяет продукты или услуги. Например, агентства аренды машин, развоза продуктов питания или поставщика запасных частей. Данная бизнес-модель имитирует оптового поставщика запасных деталей, имеющего ряд складов и соответствующих им районов продаж. Каждый склад имеет 10 районов продаж, а каждый район обслуживает 3000 покупателей. Пользователь, живущий в одном из районов продаж, может в любое время выбрать одну из пяти операций, предоставляемых системой заказов: ввести новые заказы, доставка заказов, отслеживание платежей, проверка состояния заказов или отслеживание количества товара на определенном складе.
Наиболее часто используемая транзакция состоит из ввода нового заказа, состоящего, в среднем, из 10 единиц товара. Каждый склад может хранить до 100,000 единиц, расходуемых на заказы. Для имитации реалистичных событий, например, отсутствия товара на складе, тест TPC-C требует поставок товара для 10% всех заказов с другого склада (т.е. для 10 процентов всех заказов товара на исходном складе нет).
Другой ресурсоемкой транзакцией является запись платежей покупателей. Доставка заказов, проверка наличия товара на складах и проверка состояния отдельных заказов используются реже.
Уровень пропускной способности зависит от активности пользователей, инициирующих транзакции. Для каждого склада имитируется работа 10 терминалов доступа к БД. Конечная пропускная способность теста напрямую связана с числом складов, указанных в БД. Для обеспечения необходимых транзакций в течение теста используется эмулятор удаленного терминала (RTE). Смесь транзакций представляет полную обработку заказа, включая ввод, оплату, проверку и доставку. Основной мерой теста TPC-C является количество транзакций ввода новых заказов в минуту - tpmC.
TPC-C поддерживает 5 транзакций различной сложности, которые испытывают способность БД поддерживать целостность данных, осуществляя доступ к информации различного объема и управляя конфликтами при доступе к ней и ее обновлении. Транзакции называются
- New-Order;
- Payment;
- Order-Status;
- Delivery;
- Stock-Level
Подробнее о TPC-C можно почитать на сайте компании.
OSDL-DBT-2
OSDL-DBT-2 является производной TPC-C для создания реалистичной нагрузки OLTP (сходной с той, что создает TPC-C) без сложностей и затрат, сопутствующих тестам TPC.
Основной мерой OSDL-DBT-2 является количество транзакций ввода новых заказов «New-Order», исполняемых в секунду, выражаемое в BT-2 («фиктивных транзакциях-2»). Однако BT-2 нельзя сравнивать со значениями tpmC, т.к. DBT-2 лишь похож на TPC-C, но не повторяет его полностью.
Архитектура OSDL DBT2
Данный пакет состоит из трех основных компонентов, изображенных на Рис.1:
- базы данных;
- эмуляторов удаленных терминалов;
- клиентов
На Рис.1 показаны компоненты OSDL-DBT-2.
При этом множество терминалов может быть соединено с множеством концентраторов, соединенных, в свою очередь, с единой БД. О каждом компоненте будет рассказано ниже.
База данных
База данных состоит из 9 таблиц с хранимыми процедурами (пока только для SAP DB) с поддержкой 5 транзакций. Данные представляют оптового поставщика запасных частей, работающего в ряде районов продаж, к которым прикреплены склады. БД можно масштабировать под любое число складов для имитации различных по величине компаний. По умолчанию, склад работает с 10 районами, каждый район обслуживает 3000 покупателей, запас деталей на складе составляет 100000 единиц. OSDL-DBT-2 позволяет масштабировать оставшуюся часть БД по усмотрению пользователя. Поддерживаются 5 транзакций:
- New-Order;
- Payment;
- Order-Status;
- Delivery;
- Stock-Level
Транзакция «New-Order» является средней по ресурсоемкости и включает операции чтения из и записи в одну БД. Она отражает интерактивную работу БД, типичную для производственных сред. Транзакция осуществляет от 7 до 17 выборок строк, от 6 до 16 выборок строк с обновлениями, от 7 до 17 вставок строк и исполняется 45 процентов времени.
Транзакция «Payment« используется нечасто, включая операции чтения из и записи в БД, обновляющие баланс покупателя и отражающая платежи в статистике по районам и скаладам. Транзакция осуществляет в среднем 2 выборки строк, 6 выборок строк с обновлениями, 2 вставки строк и исполняется 43 процента времени.
Транзакция «Order-Status» является средней по ресурсоемкости и включает операцию чтения из БД, запрашивающую состояние последнего заказа покупателя. Транзакция осуществляет 2 выборки строк, от 9 до 19 выборок строк с обновлениями и исполняется 4 процента времени.
Транзакция «Delivery» обрабатывает до 10 новых заказов. Она осуществляет 2 выборки строк, от 6 до 16 выборок строк с обновлениями, одно удаление строки и исполняется 4 процента времени.
Транзакция «Stock-Level» является ресурсоемкой, включает операцию чтения из БД, определяющую количество недавно проданных единиц товара, количество которых на складе ниже порогового. Транзакция осуществляет до 900 выборок строк и исполняется 4 процента времени.
Эмуляторы удаленных терминалов
Эмулятор удаленного терминала (RTE) имитирует активность человека, использующего терминал для инициирования 1 из 5 транзакций, поддерживаемых БД. RTE подсоединяется к клиентской системе для доступа к БД по трехуровневой модели. RTE также может контролироваться внешним процессом, т.е. отслеживающей программой, управляющей драйверами на множестве систем.
RTE является многопоточной программой, каждый поток которой представляет один терминал, осуществляющий доступ к БД. Для каждого склада имитируются 10 терминалов. Каждый терминал записывает каждую попытку взаимодействия и время с момента отсылки запроса до момента получения отклика.
Клиенты
Клиенты представляют собой концентраторы терминалов, позволяющие нескольким терминалам использовать одно соединение к БД. Клиентская программа запускает процесс-слушатель для обработки запросов терминалов и использует пул потоков для обработки запросов транзакций. Для каждого терминала, соединяющегося с клиентом, создается новый поток.
Методика тестирования тестом OSDL-DBT-2
В качестве тестового стенда был использован сервер, любезно предоставленный фирмой ISM Computers со следующими характеристиками:
- Dual Pentium 4 XEON 2.4 ГГц с технологией HT (HT включен);
- 2 Гб DDR266 ECC ОЗУ;
- Материнская плата — ASUS PP-DLW на чипсете Intel E7505;
- Dual Ultra160 SCSI RAID контроллер Intel SRC32U cо 128 МБ ECC SDRAM кеша;
- 74 Гб общий объем дискового пространства — 3× Cheetah 15K.3 (ST336753LC с интерфейсом Ultra320 SCSI объемом 37 Гб) в RAID5;
- Сетевой контроллер — Intel 82540 Gigabit Ethernet (интегрированный);
- ATI Radeon 9800Pro;
- TDK 440N DVD-R/RW для бекапов;
- Asus 52× CD-Rom
Вообще говоря, такой компьютер позицируется в качестве мощной графической станции, но мы его используем в качестве серверного стенда для отработки методики. В конце цикла статей этот компьютер будет рассмотрен более подробно уже на отработанной методике тестирования серверов.
Дисковое пространство делится на четыре раздела
- Linux SWAP размером 5 Гб;
- Два Linux раздела, каждый по 10 Гб
- Корневой раздел в формате EXT3 — все остальное доступное пространство
На сервер устанавливается RedHat Linux 7.3 (с версией 9.0 используемая версия SAP DB базы, рекомендуемая разработчиками OSDL тестов, работает некорректно).
Собирается ядро 2.4.21 (полный конфиг ядра) с активированными опциями в Processor type and features
- (Pentium-4) Processor family
- (4GB) High Memory Support
- [*] HIGHMEM I/O support
- [*] MTRR (Memory Type Range Register) support
- [*] Symmetric multi-processing support
Из RPM-пакетов устанавливается SAP DB версии 7.3.0.25, все ее настройки остаются по умолчанию.
Далее разархивируется и собирается DBT-2 тест (версии 0.15) с поддержкой SAP DB базы (под PostgreSQL тест портирован лишь частично).
Далее создается исходные базы для БД с параметрами
- Количество складов (warehouses) — 100;
Общий размер базы данных при вышезаданных параметрах получается около 7 гигабайт.
Так же задаются параметры для ядра SAP DB, такие как
- DATA_CACHE
Максимальный размер shared памяти в 8 Кб страницах, используемый при запросах к данной базе и для ядра SAP DB. Необходимо выделять как можно больший объем памяти, но не более, чем доступный размер ОЗУ на тестируемом компьютере. При тестировании были использованы значения 150000, 200000, 250000, 300000
- MAXUSERTASKS 32
Количество одновременных соединений с БД. Значение по умолчанию.
- MAXCPU
Максимальное количество процессоров, которое может задействовать ядро БД при обработке запросов. Были использованы значения 2 и 4
Для ускорения доступа, создаются два RAW устройства
/usr/bin/raw /dev/raw/rawX /dev/sdaX
Устройства используются для хранения данных базы и лог-файлов.
Строка запуска скрипта на генерацию базы:
./db_setup.sh 100 /home/sapdb/dbt2/tmp/
После окончания генерации, тест запускается на выполнение (на 45 минут) со следующими параметрами:
- WAREHOUSES=100
- DRIVERS=8
количество запускаемых RTE
- SPREAD=2
каждый RTE обращается к двум складам (warehouses)
В данном случае был использован кэшируемый вариант теста. Т.е. драйвера (RTE) обращаются только к части базы данных (каждый из 8 драйверов обращается к двум складам). Существует так же некешируемый вариант теста, запускающий 16 драйверов и использующий 96 складов из 100 (по 6 на каждый драйвер), но с его запуском возникли временные трудности. Второй вариант не помещается полностью в оперативную память, поэтому вырастает количество I/O операций к файлам данных, а количество транзакций в секунду не увеличивается, по сравнению с первой моделью.
После окончания теста и перед началом нового, база данных восстанавливается из бекапов.
Результаты
OSDL DBT-2 выдает довольно много результатов, но основным показателем является количество NOTPM (new-order transactions per minute). В данном случае наилучший результат получился при MAXCPU = 4 и DATA_CACHE = 250000. Transaction % Avg Response Time (s) Total Rollbacks % delivery 4.02 0.492 6871 0 0.00 new-order 44.76 0.270 76527 0 0.00 order-status 4.02 0.269 6870 0 0.00 payment 43.07 0.199 73648 0 0.00 stock-level 4.14 0.252 7072 0 0.00 1699.34 new-order transactions per minute (NOTPM) 45.0 minute duration 0 total unknown errors
Кроме NOTPM, существует довольно много отчетов по памяти, дисковой подсистеме, процессору.
Текстовые отчеты при MAXCPU = 2
Текстовые отчеты при MAXCPU = 4
Диаграммы
В данном случае процессоры опять таки были загружены не полностью (особенно загадочно выглядит спад производительности ~20 минуте). Видимо, параметры теста были подобраны не идеально.
