iXBT.com
T
Arial Georgia Tahoma Times New Roman Verdana
A- A+     Печать Почта В «мои закладки»
Сети и серверы » Аналитика и полезная информация

Методика тестирования серверов с использованием OSDL DBT, версия 0.5


В качестве средствтестирования производительности используется решение от OSDL (Open Source Development Lab) — набор тестов OSDL Database Test Suite. Все тесты распространяются на правах открытого кода и в качестве базы данных используют SAP DB, распространяемую на правах GPL/LGPL лицензии. Набор разрабатывается под Linux платформу и включает в себя три теста.

OSDL Database Test 1 (OSDL-DBT-1) представляет собой Интернет-тест производительности транзакций. Он имитирует активность пользователей, просматривающих и покупающих товары в интерактивном книжном магазине. OSDL-DBT-1 — реализация спецификаций теста TPC-W™. Результаты теста включают количество транзакций в секунду, степень загрузки ЦП, активности ввода-вывода и использования памяти. Основным является показатель BT — количество bogotransactions (синтетических транзакций) в секунду.

OSDL Database Test 2 — это тест производительности оперативной обработки транзакций. Он имитирует работу оптовой фирмы по продаже запасных деталей, в которой несколько пользователей работают с БД, обновляют информацию о клиентах и проверяют наличие товара на складе. OSDL-DBT-2 — реализация спецификаций теста TPC-C™. Результаты теста включают количество транзакций в секунду, степень загрузки ЦП, активности ввода-вывода и использования памяти.

OSDL Database Test 3 (OSDL-DBT-3) — этот тест имитирует средства поддержки принятия решений. Он включает нерегламентированные запросы и параллельное изменение данных. OSDL-DBT-3 — реализация спецификаций теста TPC-H™.

На данный момент для тестирования используются лишь первый и второй тесты из набора.

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

  • Уменьшить количество денег на счету первого клиента.
  • Записать результат.
  • Увеличить количество денег на счету второго клиента.
  • Записать результат.

Очевидно, что если на каком то этапе произойдет сбой, то первый клиент может потерять деньги, а второй — не получить их. Другими словами, деньги растворяться в киберпространстве. Будет еще интереснее, если мы поменяем шаги 3,4 местами с шагами 1,2. При сбое второй клиент может получить деньги неоткуда. Поэтому транзакции очень важны. В современном мире можно найти множество примеров, где они используются.

Рассмотрим подробнее каждый наборы тестов DBT-1 и DBT-2.

OSDL-DBT-1

Проект OSDL Database Test 1 (OSDL-DBT-1) нацелен на разработку легкого в использовании теста обработки транзакций для ОС Linux и ПО с открытым исходным кодом с возможностью удобного обмена результатами с другим разработчиками. Данный тест является упрощенной производной спецификации TPC-W™ от TPC. TPC-W используется в данном случае как шаблон, так как считается, что он имитирует нагрузку, достаточную для оптимизации производительности.

TPC-W имитирует активность пользователей, просматривающих веб-страницы и осуществляющих покупки в интерактивном книжном магазине. OSDL-DBT-1 использует характеристики нагрузки TPC-W для создания упрощенного инструмента исследования узких мест системы и измерения относительных повышений производительности, выполненных разработчиками.

Необходимо помнить, что результаты OSDL-DBT-1 нельзя сравнивать с результатами теста TPC-W. TPC требует, чтобы все опубликованные результаты удовлетворяли строгим правилам публикации и аудита, гарантирующих честное сравнение с конкурирующими тестами. Правила TPC также требуют указания стоимостей и доступности продуктов, использованных для тестирования. Следовать этим правилам в открытых разработках непрактично, поэтому результаты теста OSDL-DBT-1 не имеют никакого отношения к результатам теста TPC-W Benchmark.

Что такое TPC-W?

TPC-W определяет коммерческую деятельность интерактивного книжного магазина. Типичный комплект TPC-W включает эмуляторы удаленных браузеров (RBE), веб-серверы и базу данных. Подробное описание теста TPC-W есть на веб-сайте TPС.

Рабочая нагрузка создается RBE, которые эмулируют активность пользователей, открывающих в браузере множество интерактивных сессий для просмотра и заказа продуктов в магазине. Эмулируется 14 веб-страниц:

  • Главная;
  • Корзина;
  • Регистрация покупателей;
  • Заказ;
  • Подтверждение заказа;
  • Запрос о заказе;
  • Выведенные данные о заказе;
  • Поисковый запрос;
  • Результаты поиска;
  • Новые продукты;
  • Лидеры продаж;
  • Подробное описание продукта;
  • Запросы администратора;
  • Подтверждение запросов администратора;

Одна веб-страница представляет одно взаимодействие. Каждое взаимодействие может включать в себя один или более обмен между тестируемой системой и эмулированным браузером. Обмены могут включать в себя запросы и передачу файлов cookie, HTML-страниц, изображений и т.д. Эмулированные браузеры работают в соответствии с определенными правилами перехода между страницами, которые имитируют поведение реального пользователя и гарантируют, что доступ к 14 страницам удовлетворяет требованиям TPC-W «Web Interaction Mix», определяющим процентный диапазон каждой транзакции.

При получении запроса от RBE, веб-серверы обращаются к веб-страницам, динамически их обновляют и отсылают обратно. Серверы коммерческого веб-сайта обычно разделены на группы по назначению. Например, сервер изображений обслуживает файлы «.gif» и «.jpg», HTTP-сервер и сервер приложений исполняет бизнес-логику и работает с базой данных, а кэширующий сервер работает с кэшируемыми объектами. Для имитации поиска по сайту спецификация TPC-W предоставляет коммерчески доступную подсистему текстового поиска, которая создает и управляет статическими индексами вне базы данных. TPC-W также требует наличие эмулятора платежного шлюза, имитирующего работу с кредитными картами.

База данных состоит из множества таблиц различных размеров, имеющих сложные взаимосвязи. Транзакции базы данных должны поддерживать свойства ACID. В число свойств ACID входит атомарность, непротиворечивость, автономность и долговечность. Более подробное описание содержится в разделах спецификации TPC-W.

На Рис.1 приведена типичная архитектура TPC-W.

Что такое OSDL-DBT-1?

OSDL-DBT-1 представляет собой набор тестов на основе транзакций. Он нагружает базу данных в соответствии со спецификацией TPC-W. Тест включает в себя базу данных, сервер управления транзакциями и драйвер.

На Рис.2 показаны компоненты OSDL-DBT-1.

Драйвер OSDL-DBT-1 выполняет задачи, сходные с задачами RBE в TPC-W. Он создает и управляет эмулированными пользователями, которые следуют логике, сходной с логикой браузера в тесте TPC-W, но создают вместо HTTP-запросов структуры данных.

В отличие от теста TPC-WTM, использующего веб-серверы для сетевых объектов, тест OSDL-DBT-1 работает с сервером управления транзакциями, который упрощает тестирование и полностью исключает уровень веб-серверов.

Находясь на среднем уровне, сервер управления транзакциями соединяет драйвер с базой данных и осуществляет управление транзакциями. Взаимодействие с базой данных происходит через ODBC.

Базы данных в тестах OSDL-DBT-1 и TPC-W имеют, по существу, одинаковые таблицы с одинаковыми описаниями и следуют одним и тем же правилам заполнения. Хранимые процедуры исполняют одну и ту же бизнес-логику. Некоторые из хранимых процедур OSDL-DBT-1 возвращают меньше данных, чем определено для TPC-W.

Архитектура OSDL-DBT-1

Тест OSDL-DBT-1 состоит из трех компонентов: драйвер (driver), сервер управления транзакциями (transaction management server) и база данных. Первые два компонента написаны на языке C и используют интерфейс ODBC для работы. В качестве базы данных был взять сторонний продукт — SAP DB (версии 7.3). Тест разрабатывался под RedHat Linux 7.2, но может использоваться на всех стандартных Linux ОС.

Драйвер непосредственно нагружает базу данных. Он представляет собой многопоточную программу, в которой каждый поток выполняет действия одного пользователя. Драйвер скомпилирован в два отдельных двоичных файла. Первый из них (dbdriver_p1) связан с интерфейсом ODBC и взаимодействует с базой данных напрямую, в обход менеджера транзакций. Этот драйвер можно использовать для простого функционального тестирования хранимых процедур. Второй двоичный файл (dbdriver_p2) связан с сокет-интерфейсом и взаимодействует с сервером управления транзакциями. Данный драйвер играет главную роль в тестировании производительности.

Сервер управления транзакциями представляет собой ПО среднего уровня. Он получает от драйвера запросы на транзакции, доставляет запросы базе данных и возвращает их результаты драйверу. Сервер управления транзакциями настроен на создание определенного количества соединений с базой данных для работы с большим количеством отдельных эмулированных пользователей. Это обеспечивает большую реалистичность загрузки систем.

На Рис.3 показан сервер управления транзакциями и его связь с драйвером и базой данных:

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

Прослушивание выделенного порта на предмет входящих соединений выполняется одним потоком. При попытке эмулированного пользователя создать соединение прослушивающий поток создает поток DoConnection для обработки запроса.

DoConnection получает запрос от эмулированного пользователя, добавляет его к очереди транзакций, оповещает DoTxn о том, что очередь не пуста и ждет завершения транзакции.

DoTxn забирает запрос из очереди транзакций, обращается к базе данных и уведомляет DoConnection о выполнении транзакции. После этого DoConnection отсылает результаты эмулированному пользователю.

База данных

База данных состоит из таблиц, индексов и хранимых процедур. Таблицы содержат информацию о товарах интерактивного книжного магазина. Хранимые процедуры выполняют запросы. Индексы создаются для ускорения выполнения запросов. С помощью базы данных эмулированные пользователи могут создавать запросы о лидерах продаж, новых книгах, книгах конкретных авторов и т.д.

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 терминалов. Каждый терминал записывает каждую попытку взаимодействия и время с момента отсылки запроса до момента получения отклика.

Клиенты

Клиенты представляют собой концентраторы терминалов, позволяющие нескольким терминалам использовать одно соединение к БД. Клиентская программа запускает процесс-слушатель для обработки запросов терминалов и использует пул потоков для обработки запросов транзакций. Для каждого терминала, соединяющегося с клиентом, создается новый поток.

Методика тестирования

Дисковое пространство сервера делится на четыре раздела.

  • Linux SWAP размером ~5 Гб;
  • Linux раздел объемом 15-20 Гб в RAW режиме отводится под устройство данных для SAP DB;
  • Linux раздел объемом 5-10 Гб в RAW режиме отводится под устройство хранения логов для SAP DB;
  • Корневой раздел в формате 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-1

DBT-1 тест (последняя доступная версия — 1.2) стандартным образом собирается с поддержкой SAP DB базы.

Далее наполняется база данных с использованием следующих параметров

  • Количество эмулируемых пользователей (UEs, number of emulated users) — 500;
  • Количество вещей в базе (number of items) — 10000 (значение по умолчанию)

Общий размер базы данных при вышезаданных параметрах получается около 2,4 гигабайт.

Так же задаются параметры для ядра SAP DB, такие как

  • DATA_CACHE 235930

    Максимальный размер shared памяти в 8 Кб страницах, используемый при запросах к данной базе и для ядра SAP DB. Необходимо выделять как можно больший объем памяти, но не более, чем доступный размер ОЗУ на тестируемом компьютере. В данном случае использовано значение 90 процентов от объема ОЗУ.

  • MAXUSERTASKS 50

    Количество одновременных соединений с БД. Значение по умолчанию.

  • MAXCPU 8

    Максимальное количество процессоров, которое может задействовать ядро БД при обработке запросов.

Строка запуска скрипта на генерацию базы:
./build_db.sh -g -i 10000 -u 1000 -p /path/to/tmp_files

После создания исходных данных, модифицируется конфигурационный файл dbt1.config тестирующего скрипта. В нем устанавливается запуск всех частей теста на одном (тестируемом) компьютере, а так же задаются следующие параметры

  • [appServer]
    • dbconnection = 100
      количество соединений, открываемых к БД из программ appServer и appCache;
    • transaction_queue_size = 400 (по умолчанию)
      максимально количество транзакций в очереди AppServer;
    • transaction_array_size = 400 (по умолчанию)
      максимально количество транзакций в очереди на одного клиента;
    • items = 10000
      количество вещей в базе
  • [dbdriver]
    • items = 10000;
    • eu = 400
      количество эмулируемых пользователей;
    • eu/min = 50 (по умолчанию)
      количество пользователей, появляющихся за минуту;
    • mean think_time = 0.1
      среднее время ожидания между действиями пользователя (в сек);
    • run_duration = 4100 (по умолчанию)
      время выполнения теста (в сек);

После чего тест запускается на выполнение (примерно 68 минут). Строка запуска скрипта:
./run_dbt1.sh /path/to/results

После окончания теста и перед началом нового, база данных восстанавливается из бекапов.

Анализ результатов DBT-1

Результаты OSDL DBT-1 представлены в виде большого количества текстовых файлов. Основной показателем является количество BTs (боготранзакций в секунду). К примеру: 

Interaction                 %  Avg. Response Time (s)
Admin Confirm            0,09                   1,120
Admin Request            0,10                   1,024
Best Sellers             4,93                   2,151
Buy Confirm              1,11                   1,123
Buy Request              2,52                   1,081
Customer Registration    3,00                   0,000
Home                    16,60                   1,023
New Products             5,18                   2,148
Order Display            0,64                   1,055
Order Inquiry            0,72                   0,962
Product Detail          16,97                   0,982
Search Request          19,73                   1,021
Search Results          16,71                   1,412
Shopping Cart           11,70                   1,041

154,4 bogotransactions per second
7,0 minute duration
total bogotransactions 65007
total errors 9

Вторым важным показателем является загрузка процессоров во время исполнения теста.

Хорошо видно, что даже при уменьшении среднего времени ожидания «mean think_time» до 0.1 процессоры загружены не полностью. Видимо все узкие места в тесте еще не были устранены. Работы по тюнингу теста ведутся.

Кроме вышеописанных, существуют еще большое количество отчетов-статистик.

Использование DBT-2

DBT-2 тест (последняя доступная версии — 0.15) собирается с поддержкой SAP DB базы.

SAP DB база наполняется данными со следующими параметрами

  • Количество складов (warehouses) — 100;

Общий размер базы данных при вышезаданных параметрах получается около 7 гигабайт.

Так же задаются параметры для ядра SAP DB, такие как

  • DATA_CACHE 250000

    Максимальный размер shared памяти в 8 Кб страницах, используемый при запросах к данной базе и для ядра SAP DB. Необходимо выделять как можно больший объем памяти, но не более, чем доступный размер ОЗУ на тестируемом компьютере.

  • MAXUSERTASKS 32

    Количество одновременных соединений с БД. Значение по умолчанию.

  • MAXCPU 8

    Максимальное количество процессоров, которое может задействовать ядро БД при обработке запросов. Даже при 4х логических процессорах в системе, при установке MAXCPU=8 результаты получаются немного выше.

Строка запуска скрипта на генерацию базы:
./db_setup.sh 100 /path/to/tmp_files

После окончания генерации, тест запускается на выполнение (на 45 минут) со следующими параметрами:

  • WAREHOUSES=100
  • DRIVERS=8

    количество запускаемых RTE

  • SPREAD=2

    каждый RTE обращается к двум складам (warehouses)

В данном случае используется кэшируемый вариант теста. Т.е. драйвера (RTE) обращаются только к части базы данных (каждый из 8 драйверов обращается к двум складам).

После окончания теста и перед началом нового, база данных восстанавливается из бекапов.

Анализ результатов DBT-2

OSDL DBT-2 выдает довольно много результатов, но основным показателем является количество NOTPM (new-order transactions per minute). Нижеприведенные результаты были получены при некотором изменении стандартных переменных базы данных. 

Transaction       %  Avg Response Time (s)        Total  Rollbacks      %
delivery       3,96                  0,422        10117          0   0,00
new-order     45,04                  0,180       114982          0   0,00
order-status   4,00                  0,132        10213          0   0,00
payment       42,93                  0,119       109603          0   0,00
stock-level    4,06                  0,241        10362          0   0,00

2548,55 new-order transactions per minute (NOTPM)
45,1 minute duration
0 total unknown errors

Кроме NOTPM, существует довольно много отчетов по памяти, дисковой подсистеме, процессору.

Отмечу, что при тестировании были использованы как стандартные настройки SAP DB базы, так и их некоторые модификации. А именно: размеры очередей (io) доступа к устройствам хранения данных (_IOPROCS_PER_DEV, default 2) принимали значения 2, 4, 8. Это приходилось делать из-за аномально длинных значений очередей доступа к устройству данных (достигавших величин 33 и 36, судя по логу x_cons.out).

Время синхронизации (checkpoint) данных увеличивалось с 600 секунд (_RESTART_TIME, default) до 3000 секунд. Так как было замечено, что к середине теста синхронизация занимает не 1-2 минуты (как в начале теста), а 10-11 минут. Можно было бы грешить на переполнение кеша SCSI контроллера, но 128Мб памяти на нем более чем достаточно.

Отчеты при стандартных значениях _RESTART_TIME, меняем _IOPROCS_PER_DEV(2,4,8)

Отчеты при _RESTART_TIME=3000, так же меняем _IOPROCS_PER_DEV(2,4,8)

Диаграммы

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



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

 




2003 г. Автор Евгений Зайцев
Печать Почта В «мои закладки» < >
Дополнительно

Методика тестирования серверов с использованием OSDL DBT, версия 0.5

Методика тестирования серверов с использованием OSDL DBT, версия 0.5

В качестве средствтестирования производительности используется решение от OSDL (Open Source Development Lab) — набор тестов OSDL Database Test Suite. Все тесты распространяются на правах открытого кода и в качестве базы данных используют SAP DB, распространяемую на правах GPL/LGPL лицензии. Набор разрабатывается под Linux платформу и включает в себя три теста.

OSDL Database Test 1 (OSDL-DBT-1) представляет собой Интернет-тест производительности транзакций. Он имитирует активность пользователей, просматривающих и покупающих товары в интерактивном книжном магазине. OSDL-DBT-1 — реализация спецификаций теста TPC-W™. Результаты теста включают количество транзакций в секунду, степень загрузки ЦП, активности ввода-вывода и использования памяти. Основным является показатель BT — количество bogotransactions (синтетических транзакций) в секунду.

OSDL Database Test 2 — это тест производительности оперативной обработки транзакций. Он имитирует работу оптовой фирмы по продаже запасных деталей, в которой несколько пользователей работают с БД, обновляют информацию о клиентах и проверяют наличие товара на складе. OSDL-DBT-2 — реализация спецификаций теста TPC-C™. Результаты теста включают количество транзакций в секунду, степень загрузки ЦП, активности ввода-вывода и использования памяти.

OSDL Database Test 3 (OSDL-DBT-3) — этот тест имитирует средства поддержки принятия решений. Он включает нерегламентированные запросы и параллельное изменение данных. OSDL-DBT-3 — реализация спецификаций теста TPC-H™.

На данный момент для тестирования используются лишь первый и второй тесты из набора.

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

  • Уменьшить количество денег на счету первого клиента.
  • Записать результат.
  • Увеличить количество денег на счету второго клиента.
  • Записать результат.

Очевидно, что если на каком то этапе произойдет сбой, то первый клиент может потерять деньги, а второй — не получить их. Другими словами, деньги растворяться в киберпространстве. Будет еще интереснее, если мы поменяем шаги 3,4 местами с шагами 1,2. При сбое второй клиент может получить деньги неоткуда. Поэтому транзакции очень важны. В современном мире можно найти множество примеров, где они используются.

Рассмотрим подробнее каждый наборы тестов DBT-1 и DBT-2.

OSDL-DBT-1

Проект OSDL Database Test 1 (OSDL-DBT-1) нацелен на разработку легкого в использовании теста обработки транзакций для ОС Linux и ПО с открытым исходным кодом с возможностью удобного обмена результатами с другим разработчиками. Данный тест является упрощенной производной спецификации TPC-W™ от TPC. TPC-W используется в данном случае как шаблон, так как считается, что он имитирует нагрузку, достаточную для оптимизации производительности.

TPC-W имитирует активность пользователей, просматривающих веб-страницы и осуществляющих покупки в интерактивном книжном магазине. OSDL-DBT-1 использует характеристики нагрузки TPC-W для создания упрощенного инструмента исследования узких мест системы и измерения относительных повышений производительности, выполненных разработчиками.

Необходимо помнить, что результаты OSDL-DBT-1 нельзя сравнивать с результатами теста TPC-W. TPC требует, чтобы все опубликованные результаты удовлетворяли строгим правилам публикации и аудита, гарантирующих честное сравнение с конкурирующими тестами. Правила TPC также требуют указания стоимостей и доступности продуктов, использованных для тестирования. Следовать этим правилам в открытых разработках непрактично, поэтому результаты теста OSDL-DBT-1 не имеют никакого отношения к результатам теста TPC-W Benchmark.

Что такое TPC-W?

TPC-W определяет коммерческую деятельность интерактивного книжного магазина. Типичный комплект TPC-W включает эмуляторы удаленных браузеров (RBE), веб-серверы и базу данных. Подробное описание теста TPC-W есть на веб-сайте TPС.

Рабочая нагрузка создается RBE, которые эмулируют активность пользователей, открывающих в браузере множество интерактивных сессий для просмотра и заказа продуктов в магазине. Эмулируется 14 веб-страниц:

  • Главная;
  • Корзина;
  • Регистрация покупателей;
  • Заказ;
  • Подтверждение заказа;
  • Запрос о заказе;
  • Выведенные данные о заказе;
  • Поисковый запрос;
  • Результаты поиска;
  • Новые продукты;
  • Лидеры продаж;
  • Подробное описание продукта;
  • Запросы администратора;
  • Подтверждение запросов администратора;

Одна веб-страница представляет одно взаимодействие. Каждое взаимодействие может включать в себя один или более обмен между тестируемой системой и эмулированным браузером. Обмены могут включать в себя запросы и передачу файлов cookie, HTML-страниц, изображений и т.д. Эмулированные браузеры работают в соответствии с определенными правилами перехода между страницами, которые имитируют поведение реального пользователя и гарантируют, что доступ к 14 страницам удовлетворяет требованиям TPC-W «Web Interaction Mix», определяющим процентный диапазон каждой транзакции.

При получении запроса от RBE, веб-серверы обращаются к веб-страницам, динамически их обновляют и отсылают обратно. Серверы коммерческого веб-сайта обычно разделены на группы по назначению. Например, сервер изображений обслуживает файлы «.gif» и «.jpg», HTTP-сервер и сервер приложений исполняет бизнес-логику и работает с базой данных, а кэширующий сервер работает с кэшируемыми объектами. Для имитации поиска по сайту спецификация TPC-W предоставляет коммерчески доступную подсистему текстового поиска, которая создает и управляет статическими индексами вне базы данных. TPC-W также требует наличие эмулятора платежного шлюза, имитирующего работу с кредитными картами.

База данных состоит из множества таблиц различных размеров, имеющих сложные взаимосвязи. Транзакции базы данных должны поддерживать свойства ACID. В число свойств ACID входит атомарность, непротиворечивость, автономность и долговечность. Более подробное описание содержится в разделах спецификации TPC-W.

На Рис.1 приведена типичная архитектура TPC-W.

Что такое OSDL-DBT-1?

OSDL-DBT-1 представляет собой набор тестов на основе транзакций. Он нагружает базу данных в соответствии со спецификацией TPC-W. Тест включает в себя базу данных, сервер управления транзакциями и драйвер.

На Рис.2 показаны компоненты OSDL-DBT-1.

Драйвер OSDL-DBT-1 выполняет задачи, сходные с задачами RBE в TPC-W. Он создает и управляет эмулированными пользователями, которые следуют логике, сходной с логикой браузера в тесте TPC-W, но создают вместо HTTP-запросов структуры данных.

В отличие от теста TPC-WTM, использующего веб-серверы для сетевых объектов, тест OSDL-DBT-1 работает с сервером управления транзакциями, который упрощает тестирование и полностью исключает уровень веб-серверов.

Находясь на среднем уровне, сервер управления транзакциями соединяет драйвер с базой данных и осуществляет управление транзакциями. Взаимодействие с базой данных происходит через ODBC.

Базы данных в тестах OSDL-DBT-1 и TPC-W имеют, по существу, одинаковые таблицы с одинаковыми описаниями и следуют одним и тем же правилам заполнения. Хранимые процедуры исполняют одну и ту же бизнес-логику. Некоторые из хранимых процедур OSDL-DBT-1 возвращают меньше данных, чем определено для TPC-W.

Архитектура OSDL-DBT-1

Тест OSDL-DBT-1 состоит из трех компонентов: драйвер (driver), сервер управления транзакциями (transaction management server) и база данных. Первые два компонента написаны на языке C и используют интерфейс ODBC для работы. В качестве базы данных был взять сторонний продукт — SAP DB (версии 7.3). Тест разрабатывался под RedHat Linux 7.2, но может использоваться на всех стандартных Linux ОС.

Драйвер непосредственно нагружает базу данных. Он представляет собой многопоточную программу, в которой каждый поток выполняет действия одного пользователя. Драйвер скомпилирован в два отдельных двоичных файла. Первый из них (dbdriver_p1) связан с интерфейсом ODBC и взаимодействует с базой данных напрямую, в обход менеджера транзакций. Этот драйвер можно использовать для простого функционального тестирования хранимых процедур. Второй двоичный файл (dbdriver_p2) связан с сокет-интерфейсом и взаимодействует с сервером управления транзакциями. Данный драйвер играет главную роль в тестировании производительности.

Сервер управления транзакциями представляет собой ПО среднего уровня. Он получает от драйвера запросы на транзакции, доставляет запросы базе данных и возвращает их результаты драйверу. Сервер управления транзакциями настроен на создание определенного количества соединений с базой данных для работы с большим количеством отдельных эмулированных пользователей. Это обеспечивает большую реалистичность загрузки систем.

На Рис.3 показан сервер управления транзакциями и его связь с драйвером и базой данных:

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

Прослушивание выделенного порта на предмет входящих соединений выполняется одним потоком. При попытке эмулированного пользователя создать соединение прослушивающий поток создает поток DoConnection для обработки запроса.

DoConnection получает запрос от эмулированного пользователя, добавляет его к очереди транзакций, оповещает DoTxn о том, что очередь не пуста и ждет завершения транзакции.

DoTxn забирает запрос из очереди транзакций, обращается к базе данных и уведомляет DoConnection о выполнении транзакции. После этого DoConnection отсылает результаты эмулированному пользователю.

База данных

База данных состоит из таблиц, индексов и хранимых процедур. Таблицы содержат информацию о товарах интерактивного книжного магазина. Хранимые процедуры выполняют запросы. Индексы создаются для ускорения выполнения запросов. С помощью базы данных эмулированные пользователи могут создавать запросы о лидерах продаж, новых книгах, книгах конкретных авторов и т.д.

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 терминалов. Каждый терминал записывает каждую попытку взаимодействия и время с момента отсылки запроса до момента получения отклика.

Клиенты

Клиенты представляют собой концентраторы терминалов, позволяющие нескольким терминалам использовать одно соединение к БД. Клиентская программа запускает процесс-слушатель для обработки запросов терминалов и использует пул потоков для обработки запросов транзакций. Для каждого терминала, соединяющегося с клиентом, создается новый поток.

Методика тестирования

Дисковое пространство сервера делится на четыре раздела.

  • Linux SWAP размером ~5 Гб;
  • Linux раздел объемом 15-20 Гб в RAW режиме отводится под устройство данных для SAP DB;
  • Linux раздел объемом 5-10 Гб в RAW режиме отводится под устройство хранения логов для SAP DB;
  • Корневой раздел в формате 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-1

DBT-1 тест (последняя доступная версия — 1.2) стандартным образом собирается с поддержкой SAP DB базы.

Далее наполняется база данных с использованием следующих параметров

  • Количество эмулируемых пользователей (UEs, number of emulated users) — 500;
  • Количество вещей в базе (number of items) — 10000 (значение по умолчанию)

Общий размер базы данных при вышезаданных параметрах получается около 2,4 гигабайт.

Так же задаются параметры для ядра SAP DB, такие как

  • DATA_CACHE 235930

    Максимальный размер shared памяти в 8 Кб страницах, используемый при запросах к данной базе и для ядра SAP DB. Необходимо выделять как можно больший объем памяти, но не более, чем доступный размер ОЗУ на тестируемом компьютере. В данном случае использовано значение 90 процентов от объема ОЗУ.

  • MAXUSERTASKS 50

    Количество одновременных соединений с БД. Значение по умолчанию.

  • MAXCPU 8

    Максимальное количество процессоров, которое может задействовать ядро БД при обработке запросов.

Строка запуска скрипта на генерацию базы:
./build_db.sh -g -i 10000 -u 1000 -p /path/to/tmp_files

После создания исходных данных, модифицируется конфигурационный файл dbt1.config тестирующего скрипта. В нем устанавливается запуск всех частей теста на одном (тестируемом) компьютере, а так же задаются следующие параметры

  • [appServer]
    • dbconnection = 100
      количество соединений, открываемых к БД из программ appServer и appCache;
    • transaction_queue_size = 400 (по умолчанию)
      максимально количество транзакций в очереди AppServer;
    • transaction_array_size = 400 (по умолчанию)
      максимально количество транзакций в очереди на одного клиента;
    • items = 10000
      количество вещей в базе
  • [dbdriver]
    • items = 10000;
    • eu = 400
      количество эмулируемых пользователей;
    • eu/min = 50 (по умолчанию)
      количество пользователей, появляющихся за минуту;
    • mean think_time = 0.1
      среднее время ожидания между действиями пользователя (в сек);
    • run_duration = 4100 (по умолчанию)
      время выполнения теста (в сек);

После чего тест запускается на выполнение (примерно 68 минут). Строка запуска скрипта:
./run_dbt1.sh /path/to/results

После окончания теста и перед началом нового, база данных восстанавливается из бекапов.

Анализ результатов DBT-1

Результаты OSDL DBT-1 представлены в виде большого количества текстовых файлов. Основной показателем является количество BTs (боготранзакций в секунду). К примеру: 

Interaction                 %  Avg. Response Time (s)
Admin Confirm            0,09                   1,120
Admin Request            0,10                   1,024
Best Sellers             4,93                   2,151
Buy Confirm              1,11                   1,123
Buy Request              2,52                   1,081
Customer Registration    3,00                   0,000
Home                    16,60                   1,023
New Products             5,18                   2,148
Order Display            0,64                   1,055
Order Inquiry            0,72                   0,962
Product Detail          16,97                   0,982
Search Request          19,73                   1,021
Search Results          16,71                   1,412
Shopping Cart           11,70                   1,041

154,4 bogotransactions per second
7,0 minute duration
total bogotransactions 65007
total errors 9

Вторым важным показателем является загрузка процессоров во время исполнения теста.

Хорошо видно, что даже при уменьшении среднего времени ожидания «mean think_time» до 0.1 процессоры загружены не полностью. Видимо все узкие места в тесте еще не были устранены. Работы по тюнингу теста ведутся.

Кроме вышеописанных, существуют еще большое количество отчетов-статистик.

Использование DBT-2

DBT-2 тест (последняя доступная версии — 0.15) собирается с поддержкой SAP DB базы.

SAP DB база наполняется данными со следующими параметрами

  • Количество складов (warehouses) — 100;

Общий размер базы данных при вышезаданных параметрах получается около 7 гигабайт.

Так же задаются параметры для ядра SAP DB, такие как

  • DATA_CACHE 250000

    Максимальный размер shared памяти в 8 Кб страницах, используемый при запросах к данной базе и для ядра SAP DB. Необходимо выделять как можно больший объем памяти, но не более, чем доступный размер ОЗУ на тестируемом компьютере.

  • MAXUSERTASKS 32

    Количество одновременных соединений с БД. Значение по умолчанию.

  • MAXCPU 8

    Максимальное количество процессоров, которое может задействовать ядро БД при обработке запросов. Даже при 4х логических процессорах в системе, при установке MAXCPU=8 результаты получаются немного выше.

Строка запуска скрипта на генерацию базы:
./db_setup.sh 100 /path/to/tmp_files

После окончания генерации, тест запускается на выполнение (на 45 минут) со следующими параметрами:

  • WAREHOUSES=100
  • DRIVERS=8

    количество запускаемых RTE

  • SPREAD=2

    каждый RTE обращается к двум складам (warehouses)

В данном случае используется кэшируемый вариант теста. Т.е. драйвера (RTE) обращаются только к части базы данных (каждый из 8 драйверов обращается к двум складам).

После окончания теста и перед началом нового, база данных восстанавливается из бекапов.

Анализ результатов DBT-2

OSDL DBT-2 выдает довольно много результатов, но основным показателем является количество NOTPM (new-order transactions per minute). Нижеприведенные результаты были получены при некотором изменении стандартных переменных базы данных. 

Transaction       %  Avg Response Time (s)        Total  Rollbacks      %
delivery       3,96                  0,422        10117          0   0,00
new-order     45,04                  0,180       114982          0   0,00
order-status   4,00                  0,132        10213          0   0,00
payment       42,93                  0,119       109603          0   0,00
stock-level    4,06                  0,241        10362          0   0,00

2548,55 new-order transactions per minute (NOTPM)
45,1 minute duration
0 total unknown errors

Кроме NOTPM, существует довольно много отчетов по памяти, дисковой подсистеме, процессору.

Отмечу, что при тестировании были использованы как стандартные настройки SAP DB базы, так и их некоторые модификации. А именно: размеры очередей (io) доступа к устройствам хранения данных (_IOPROCS_PER_DEV, default 2) принимали значения 2, 4, 8. Это приходилось делать из-за аномально длинных значений очередей доступа к устройству данных (достигавших величин 33 и 36, судя по логу x_cons.out).

Время синхронизации (checkpoint) данных увеличивалось с 600 секунд (_RESTART_TIME, default) до 3000 секунд. Так как было замечено, что к середине теста синхронизация занимает не 1-2 минуты (как в начале теста), а 10-11 минут. Можно было бы грешить на переполнение кеша SCSI контроллера, но 128Мб памяти на нем более чем достаточно.

Отчеты при стандартных значениях _RESTART_TIME, меняем _IOPROCS_PER_DEV(2,4,8)

Отчеты при _RESTART_TIME=3000, так же меняем _IOPROCS_PER_DEV(2,4,8)

Диаграммы

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



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

 

2003 г. Автор Евгений Зайцев

Copyright © 1997-2017, iXBT.com.
Статистика / Поиск / О сайте / Реклама / RSS /