Отработка методики тестирования серверов, часть вторая

Тест OSDL-DBT-2


В этой статье мы продолжаем знакомится с серверными тестами 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 минуте). Видимо, параметры теста были подобраны не идеально.

 

Особая благодарность Cormac за помощь с переводом спецификаций.

 

Сервер для тестирования предоставлен компанией «ISM»

 




Дополнительно

iXBT BRAND 2016

«iXBT Brand 2016» — Выбор читателей в номинации «Процессоры (CPU)»:
Подробнее с условиями участия в розыгрыше можно ознакомиться здесь. Текущие результаты опроса доступны тут.

Нашли ошибку на сайте? Выделите текст и нажмите Shift+Enter

Код для блога бета

Выделите HTML-код в поле, скопируйте его в буфер и вставьте в свой блог.