Вы уверены, что делаете backup правильно, или тест скорости backup

KDV, iBase.ru, 10.03.2007.

 

Цель теста

Проверить скорость backup различными способами и на разных версиях серверов InterBase и Firebird.
 

Тестовый стенд

Компьютер

• Windows XP Professional SP2
• AMD Athlon 64 3500+
• MB EPOX 9NPA3 Ultra (NForce 4)
• 2GB RAM
• Конфигурация логических дисков сложная, поэтому примем, что
  • Операционная система находится на физическом диске C: (IDE HDS728080PLAT20)
  • База данных находится на физическом диске D: (SATA II ST3200827AS)
  • Бэкап производится на физическом диск E: (SATA HDS728080PLA380) 
• Все 3 диска (C, D, E) – отдельные физические.

Участники теста

• Firebird 1.5.3, 2.1 (SuperServer), InterBase 7.5.1 sp1, 2007, Yaffil (892).
• Утилита gbak, для каждого сервера своя.
• Клиентская часть fbclient.dll и gds32.dll также соответствующая версии сервера.

База данных и конфигурация

В качестве тестовой базы данных взята БД размером 2.7 гигабайт, содержащая около 150 таблиц и 300 индексов, но в которой только одна таблица является самой большой (14 миллионов записей, 1.9 гигабайт), и 2 поменьше – по 1.5 и 1.1 миллионов записей. База данных не обновлялась после restore, записи на страницах данных расположены максимально плотно.

• Размер страницы БД – 16к.
• ODS – 10.1

Для каждого сервера в файле конфигурации прописан размер кэша 8192 страниц. В БД одна из таблиц имеет 14 миллионов записей. На всякий случай была проверена скорость backup базы "родного" формата для FB 2.0 и IB 7.5, скорость оказалась идентичной.

Серверы Firebird/InterBase и gbak выполнялись на одном компьютере. Результирующий бэкап имеет размер 2.2 гигабайта.

gbak выполнялся всегда с ключом -g, не смотря на однозначное отсутствие версий записей в базе данных. Аргументы по этому поводу см. в документе.
   

Особенности теста

По ходу теста был исключен Firebird 1.5.3 Classic, т. к. оказалось что он не поддерживает Services API и локальный протокол на уровне командной строки (проблема в утилите gbak). При этом, поскольку тест по tcp показал идентичность скорости SuperServer, можно сделать предположение что Классик в данном плане отличаться не будет.

Также, первоначально было проверено влияние ключа -v (полный вывод) на скорость backup. Разница на 6-ти минутах оказалась в 3-4 секунды (относительно gbak без ключа -v), что можно считать несущественным. Таким образом, ключ -v можно считать не влияющим на скорость backup.

Для исключения погрешностей и влияния посторонних факторов тест для каждого сервера проводился как минимум 2 раза, а в некоторых случаях и по 3 раза (при появлении явных отклонений от ожидаемого результата). Всего на тест потрачено примерно 15 часов.
 

Выполнение теста

Тест состоял из следующих команд:

1. localhost – бэкап по tcp/ip

2. local – бэкап по локальному протоколу, т. е. без указания имени сервера

3. Services API – бэкап через services api (по tcp/ip), т. е. непосредственно сервером

4. Services API – то же, только бэкап производился на тот же физический диск, где находилась БД

Сначала приведем результат только Firebird 1.5.3, т.к. он является наиболее показательным, и даже можно сказать "эталонным". По вертикали – время в минутах и секундах.


Итак, медленнее всех – tcp/ip. На 26% быстрее него – локальный протокол. Еще быстрее (примерно на 48%) – Services API. И, мы видим разницу в 41% между бэкапом через Services API на разных дисках и на одном. Действительно, при backup происходит чтение базы данных и запись файла backup. Разделение этих операций по физическим дискам дает существенную выгоду, даже когда чтением БД и записью бэкапа занимается один и тот же процесс – сервер.

Интересно, что теоретически можно было бы предположить ускорение backup на двухпроцессорных машинах, т. к. в первых двух случаях (localhost и локальный протокол) fbserver.exe и gbak.exe занимают примерно по 45% процессорного времени (см. графики загрузки процессора в конце статьи). Это стоит проверить отдельным тестом, но дальнейшие графики не дают уверенности в возможности подобного ускорения.

Теперь давайте посмотрим детализированный результат по всем версиям серверов, участвовавшим в тесте:

 

Предварительные выводы по тесту

• Yaffil обогнал всех, минимум разницы составил только при бэкапе через Services API.
• Firebird 1.5/2.1 выполняют backup на данном процессоре быстрее, чем InterBase 7.5/2007 (по поводу процессора см. далее).
• backup по Services API – самый быстрый способ backup (от 20% до 40% быстрее чем tcp или локальный).
• Локальный протокол в InterBase 7.5/2007 работает медленнее, чем tcp.
• backup в Firebird 2.1 любым способом медленнее, чем в Firebird 1.5 (примерно на 8%).
• При нехватке мощности процессора разница в разделении физических носителей по чтению/записи становится незаметной.

 

Комментарии

В данном тесте для InterBase 7.5/2007 разницы при backup на разные или один диск не обнаруживается из-за медленного менеджера памяти. Это отнюдь не вывод по результатам теста – наиболее характерно "неспешность" используемого в InterBase менеджера памяти проявляется в других вещах (возможно, об этом будет отдельный тест). Но, как результат, "медленность" менеджера памяти приводит к более высокой загрузке процессора, что ощутимо даже при попытке переключения на другие приложения в момент теста, а также явно видно по PerfMon – загрузка памяти у InterBase в этом тесте всегда 100% без провалов, в то время как у Firebird – на уровне ~95% или меньше.

Давайте посмотрим на графики PerfMon по трем серверам (InterBase 7.5 и 2007 в этом плане идентичны, как вы уже убедились выше. Графики по Yaffil не приведены т.к. идентичны Firebird 1.5, за исключением более высокого disk transfer rate):

	Firebird 1.5	Firebird 2.1	InterBase 2007
localhost
local
se
se 1 hdd

Здесь пурпурным цветом обозначена загрузка процессора процессом fbserver/ibserver (в случае Firebird общая загрузка процессора кроме Services API составляет ~97%, для InterBase – 100% во всех случаях), в % от 100, зеленым цветом – загрузка процессора утилитой gbak, а внизу графика синие, черные и коричневые линии – скорость записи-чтения дисков в мегабайтах. Для локального протокола и tcp это в среднем 5.3 мб/сек, а для Services API – 7.3 мб/сек. У InterBase для Services API скорость дискового ввода-вывода для localhost идентична, для локального протокола и Services API – чуть ниже).

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

У Firebird, наоборот, видно (на нижних графиках) что процессора вполне хватает (график загрузки процесора fbserver.exe идентичен общему графику загрузки процессора), однако чтение/запись на одном диске явно ухудшает общий ввод-вывод (относительно графика se). При этом, не смотря на "борьбу" за процессор fbserver и gbak при использовании localhost или локального протокола, на двухпроцессорном компьютере не стоит ожидать прироста в производительности, т. к. процессор все равно "недогружен", например, при использовании Services API.

Замечание по Services API

При выполнении backup через Services API gbak или приложение только дает команду на выполнение backup, а дальше сохранением резервной копии занимается только сервер. Таким образом, в отличие от выполнения backup самим gbak (tcp или локальный протокол), в Firebird прекратить выполнение backup можно только путем остановки сервера (в InterBase 7.x/2007 это можно сделать через временные системные таблицы).

В качестве иллюстрации "проблемы" можно привести маловероятный случай, когда вы запускаете backup одновременно 2 или более раз: без -se вы можете снять gbak нажатием Ctrl-C, а при -se – только остановить сервер.

Эту особенность необходимо учитывать, если вас волнует подобный вопрос.
 

Послесловие

Из теста видно, что в Yaffil существует дополнительная оптимизация (или еще более быстрый менеджер памяти, чем в Firebird), что позволило ему буквально "дать дрозда" остальным участникам. Можно сказать, что для Firebird и InterBase еще есть перспективы ускорения в отношении данного теста.

Следует напомнить, что данный тест – только тест скорости backup, и ничего более. Победа Yaffil в данном тесте не позволяет утверждать, что в интегральном тесте общей производительности он выиграет – как минимум потому, что в Firebird 2.0/2.1 произведены существенные изменения оптимизатора, а общая производительность сервера на реальных системах определяется, по большому счету, именно оптимизатором, а иногда и не зависит от версии сервера.

Например, для оценки производительности на всех серверах к базе был выполнен запрос select count(*) по самой большой таблице в БД. Все серверы показали один и тот же результат – 42 секунды, 50% загрузки процессора во время выполнения запроса, и disk transfer rate ~45 мегабайт в секунду (что и является максимумом по вводу-выводу для данного участка диска, где располагалась БД).