В нашей конференции недавно открылся раздел «Серверы», посвященный аппаратному обеспечению серверов, а так же программному и аппаратному обеспечению систем хранения и резервного копирования данных. Полагаю, в этом разделе часто будет возникать вопрос — «а какой же из А, В, С, D лучше?». В последующей серии статей я предлагаю к обсуждению методику тестирования производительности серверов для баз данных.
Что же представляет собой сервер баз данных? Это высокопроизводительная машина, которой всегда мало (немного утрируя):
- Процессоров
- Памяти
- Дискового пространства
То есть сервер баз данных (учитываем, что эта машина обслуживает не пару десятков человек) — это многопроцессорная (2, 4, 8 процессоров) машина, обслуживающая несколько сотен человек и хранящая довольно большой объем информации в своей базе. Поэтому дисковая подсистема является тоже критичным местом. К тому же от нее требуется безотказность работы и часто возможность горячей замены поврежденных винчестеров. Поэтому в подобных серверах обычно используются дисковые массивы RAID пятого уровня и жесткие диски на SCSI шине. Оперативная память тоже никогда не бывает лишней (она используется и операционной системой и самой базой данных). Используется память с коррекцией ошибок и ее объем начинается от полутора гигабайт и выше.
В общем, вы уже поняли, что это далеко не домашняя машина на p4 3 ГГц, 160 Гб SATA HDD, 512 Мб DDR памяти и GeForce FX 5900. Кстати говоря, вышеописанному серверу видеокарта не нужна совсем.
Если с методикой тестирования производительности дисковой подсистемы вопрос пока остается открытым, то обсуждение методики тестирование скорости обработки данных (а точнее говоря — количество транзакций в секунду) можно начинать.
Что же такое транзакция? Это неделимая последовательность операций, которые могут быть либо полностью выполнены, либо отменены совсем. Другими словами — идея транзакции состоит в ее завершенности. Рассмотрим простой пример перевода денег со счета одного клиента на другой. Это действие разбивается на некую последовательность операций.
- Уменьшить количество денег на счету первого клиента.
- Записать результат.
- Увеличить количество денег на счету второго клиента.
- Записать результат.
Очевидно, что если на каком то этапе произойдет сбой, то первый клиент может потерять деньги, а второй — не получить их. Другими словами, деньги растворяться в киберпространстве. Будет еще интереснее, если мы поменяем шаги 3,4 местами с шагами 1,2. При сбое второй клиент может получить деньги неоткуда. Поэтому транзакции очень важны. В современном мире можно найти множество примеров, где они используются.
В качестве тестирования производительности 
было выбрано решение от 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 (tm). Результаты теста включают количество транзакций в секунду, степень загрузки ЦП, активности ввода-вывода и использования памяти. Основным является показатель BT — количество bogotransactions (синтетических транзакций) в секунду.
OSDL Database Test 2 — это тест производительности оперативной обработки транзакций. Он имитирует работу оптовой фирмы по продаже запасных деталей, в которой несколько пользователей работают с БД, обновляют информацию о клиентах и проверяют наличие товара на складе. OSDL-DBT-2 — реализация спецификаций теста TPC-C (tm). Результаты теста включают количество транзакций в секунду, степень загрузки ЦП, активности ввода-вывода и использования памяти.
OSDL Database Test 3 (OSDL-DBT-3) — этот тест имитирует средства поддержки принятия решений. Он включает нерегламентированные запросы и параллельное изменение данных. OSDL-DBT-3 — реализация спецификаций теста TPC-H (tm).
В этой статье подробно остановлюсь на тесте OSDL-DBT-1.
Проект OSDL Database Test 1 (OSDL-DBT-1) нацелен на разработку легкого в использовании теста обработки транзакций для ОС Linux и ПО с открытым исходным кодом с возможностью удобного обмена результатами с другим разработчиками. Данный тест является упрощенной производной спецификации TPC-W (tm) от 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-1
В качестве тестового стенда был использован сервер, любезно предоставленный фирмой ISM Computers со следующими характеристиками:
- Dual Pentium 4 XEON 2,4 ГГц с технологией 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-1 тест (версии 1.2) с поддержкой SAP DB базы (тест уже умеет работать с PostgreSQL, но вышла лишь единственная его версия 0.1).
Далее создается исходные базы для БД с параметрами
- Количество эмулируемых пользователей (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 4
Максимальное количество процессоров, которое может задействовать ядро БД при обработке запросов.
Для ускорения доступа, создаются два RAW устройства
/usr/bin/raw /dev/raw/rawX /dev/sdaX
Устройства используются для хранения логов и данных текущей базы.
Строка запуска скрипта на генерацию базы:
./build_db.sh -g -i 10000 -u 1000 -p /home/sapdb/dbt1/tmp/
После создания исходных данных, модифицируется конфигурационный файл dbt1.config тестирующего скрипта. В нем устанавливается запуск всех частей теста на одном (тестируемом) компьютере, а так же задаются следующие параметры
- [appServer]
- dbconnection = 100
количество соединений, открываемых к БД из программ appServer и appCache; - transaction_queue_size = 400 (по умолчанию)
максимально количество транзакций в очереди AppServer; - transaction_array_size = 400 (по умолчанию)
максимально количество транзакций в очереди на одного клиента; - items = 10000
количество вещей в базе
- dbconnection = 100
- [dbdriver]
- items = 10000;
- eu = 400
количество эмулируемых пользователей; - eu/min = 50 (по умолчанию)
количество пользователей, появляющихся за минуту; - mean think_time = 7.2 (по умолчанию)
время ожидания между действиями пользователя (в сек); - run_duration = 4100 (по умолчанию)
время выполнения теста (в сек);
После чего тест запускается на выполнение (примерно на час). Строка запуска скрипта:
./run_dbt1.sh /home/sapdb/dbt1/tmp/res
После окончания теста и перед началом нового, база данных восстанавливается из бекапов, а сервер перегружается для чистоты эксперимента.
Результаты
Результаты OSDL DBT-1 представлены в виде большого количества текстовых файлов. Основной показателем является количество BTs (боготранзакций в секунду). Interaction % Avg. Response Time (s) Admin Confirm 0.09 0.274 Admin Request 0.10 0.259 Best Sellers 4.95 1.103 Buy Confirm 1.18 0.565 Buy Request 2.55 0.586 Customer Registration 2.94 0.000 Home 16.69 0.505 New Products 4.98 1.125 Order Display 0.65 0.554 Order Inquiry 0.74 0.470 Product Detail 16.92 0.467 Search Request 19.88 0.478 Search Results 16.92 0.684 Shopping Cart 11.41 0.510 59.3 bogotransactions per second 68.5 minute duration total bogotransactions 243754 total errors 0
Вторым важным показателем является загрузка процессоров во время исполнения теста. Cpu Statistics (sar -u ) Linux s1 2.4.21-2421-ism2 #4 SMP Mon Jul 14 20:08:52 MSD 2003 i686 unknown Linux 2.4.21-2421-ism2 (s1) 07/16/03 17:34:35 CPU %user %nice %system %iowait %idle […] Average: all 50.46 0.00 6.38 0.00 43.16
Хорошо видно, что в данном случае процессоры были загружены лишь наполовину. Для полной загрузки возможно потребуется увеличить количество EU (эмулируемых пользователей), а так же размер самой базы данных (items). При увеличении количества пользователей мы сталкиваемся с ограничением glibc и библиотеки pthread, которое не позволяет эмулировать больше, чем примерно 900 EU с одной машины. В этом случае придется запускать несколько программ dbdriver и appServer на разных машинах.
Кроме вышеописанных, существуют еще большое количество отчетов-статистик.
- индивидуальная по процессорам 1, 2 (это результаты в тесте без HT);
- по datadev БД;
- по logdev БД;
- по операциям ввода/вывода;
- по памяти;
- по файлу подкачки (sar -W);
- по страницам памяти (sar -B);
- по очередям (sar -q);
- по использованию памяти (sar -r);
- данные, выдаваемые top; 2, 3, 4,
Выводы
Был рассмотрен первый тест из пакета OSDL-DBT. В следующих статьях будет рассмотрены остальные два, а так же завершен тюнинг их параметров. Полагаю, подобные тесты заслуживают внимания и годятся для тестирования мощных рабочих станций и серверов.
P.S. Вторая часть методики рассмотрена в следующей статье.
