Опросы
Активных опросов на данный момент нет.
Счетчики
Rambler's Top100





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


Rambler's Top100

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

Цель теста

Проверить скорость 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) - отдельные физические.

примечание: не смотря на то, что размещение резервной копии (backup) базы на том же физическом носителе где и база данных, грозит в случае повреждения диска потерей и базы и ее резервной копии, одной из целей теста было определить, действительно ли (и насколько) медленнее будет выполняться одна и та же работа на одном или раздельных дисках. Размещение резервной копии и БД на разных логических дисках одного и того же физического диска может дать кажущийся приемлемым результат, но только потому, что обычно скорость обмена с диском не является линейной по его радиусу (как минимум для дисков IDE и SATA).

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

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

примечание: первоначально в тесте не участвовал Firebird 2.0. По завершении был проверен Firebird 2.0 (release), результат оказался идентичен версии 2.1.0.15036. Yaffil проверялся в том числе и для сборки 884, показав идентичные результаты.

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

В качестве тестовой базы данных взята БД размером 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, не смотря на однозначное отсутствие версий записей в базе данных. 

примечание: дополнительно была попытка протестировать InterBase 6.0.1.0, которая оказалась неуспешной - сервер отказался открывать БД (то ли из-за ODS, то ли из-за размера страницы)

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

По ходу теста был исключен 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
    gbak -b -g localhost:d:db.db e:b.bk
  2. local - бэкап по локальному протоколу, т.е. без указания имени сервера
    gbak -b -g d:db.db e:b.bk
  3. Services API - бэкап через services api (по tcp/ip), т.е. непосредственно сервером
    gbak -b -g -se localhost:service_mgr d:db.db e:b.bk
  4. Services API - то же, только бэкап производился на тот же физический диск, где находилась БД
    gbak -b -g -se localhost:service_mgr d:db.db d:b.bk

Сначала приведем результат только 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 мегабайт в секунду (что и является максимумом по вводу-выводу для данного участка диска, где располагалась БД).

 

Страниц: 1
Опубликовано: 26.03.09 | Просмотров: 2280 | [ + ]   [ - ]   | Печать
 
 
© 2018