Тест скорости backup 2

KDV, iBase.ru, 01.12.2008.

Как и было обещано в первой статье по тесту скорости backup, наконец-то тест повторен на компьютере с двухъядерным процессором. И если бы практически никаких отличий не было, то всего-лишь была бы обновлена оригинальная статья.

Начну с изменения конфигурации.

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

Windows XP Professional SP3
AMD Athlon 64 x2 5200
MB MSI K9N Platinum
4GB RAM (в 32-разрядной Windows видно только 3.1 гигабайта)
Дисковая конфигурация практически не изменилась, то есть, диски D и E остались на месте:
- C: ST3160815AS (160GB), SATA II
- D: ST3200827AS (200GB), SATA II
- E: HDS728080PLA380 (82GB), SATA I

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

InterBase 7.5 за ненадобностью был выкинут, вместо него был протестирован Firebird 2.5 Alpha (сборки 21381 и 21487, показали одинаковый результат).

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

Опять та же база данных размером 2.7 гигабайт, в общем, все идентично предыдущему тесту.

Тест

Идентичный, т. е. проверка резервного копирования БД через локальный протокол, tcp, и Services API. Цель теста – сравнить поведение серверов при бэкапе на однопроцессорной и "двухпроцессорной" машине.

Результаты

Для наглядности приведу сначала картинку предыдущих результатов, на однопроцессорной машине:

А теперь – на двухъядерной:

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

Здесь можно заметить серьезное отличие: на двухъядерном процессоре локальный протокол медленнее, чем tcp у Firebird 1.5 и InterBase 2007, причем локальный протокол не просто медленнее tcp, а почти на 20-30% хуже "самого себя" на однопроцессорной машине.

Этому феномену, буквально "среднему пальцу" на графиках, я пока объяснения не нахожу. Вернее, объяснить можно только то, что замедление одинаковое у FB 1.5 и IB 2007 – они оба используют "классический старый локальный протокол", в то время как локальный протокол в Yaffil и Firebird 2.x реализован по другому.

С Yaffil тоже случилась странность. Он, конечно, опять всех жестоко побил – процессор-то более быстрый, но вот локальный протокол у него сработал на двухъядерной машине лучше, чем собственный Services API.

У Firebird 2.1 и 2.5 паритет. В 2.5 относительно 2.1 локальный протокол стал лучше, а tcp – хуже, и они как бы словно поменялись местами.

В целом тест на двухъядерной машине однозначно опровергает тест на одноядерной – backup по tcp происходит практически в 2 раза быстрее и почти не уступает скорости локального протокола (кроме FB 1.5 и IB 2007, у которых tcp тоже получается в 2 раза быстрее локального протокола на той же двухъядерной машине).

Чтобы попытаться понять, где проблема, я снял несколько скриншотов с PerfMon.

	TCP (localhost) Firebird 1.5 График кажется мешаниной, поэтому пояснения: синий – gbak.exe зеленый – fbserver.exe красный – общая загрузка обоих ядер "морской" – загрузка ядра 1 "черный" – загрузка ядра 2 коричневый и ярко-синий внизу экрана – скорость записи и чтения с двух физ. дисков. Для упрощения в тесте под диском D: имеется в виду физический диск 1, а под диском E: – физический диск 2. Операционная система находится на физическом диске 0 (C:).
	Локальный протокол, Firebird 1.5 Казалось бы, та же самая мешанина, но при этом средняя загрузка процессора на уровне 40%, а не 80%, как у tcp.
	Services API, Firebird 1.5 Тут все ясно и нормально. Сервер сам делает бэкап, поэтому gbak никак не загружает никакое ядро. А fbserver сам почти полностью загружает одно из ядер. Правда, не удалось понять в TaskManager чем же загружено второе ядро на уровне 17-20%. Никакие другие процессы в это время не работали.
	TCP (localhost), Firebird 2.1 (примерно то же самое и у Firebird 2.5) Такой мешанины как у FB 1.5 нет. Явно видно что fbserver и gbak "более четко" грузят ядра. Причем если у FB 1.5 нагрузка на второе ядро gbak-ом была выше, то здесь она явно ниже (размещение синих и черных линий)
	Локальный протокол, Firebird 2.5 (примерно то же самое и у FB 2.1) Не то чтобы "никакой мешанины как в FB 1.5", но даже по сравнению с предыдущим графиком совершенно четкая загрузка ядер gbak и fbserver.

Резюме

На многоядерных машинах backup по локальному протоколу хуже, чем tcp.
Backup через Services API остается самым быстрым в любой ситуации. Кстати, никакой разницы в скорости backup через Services API без -v через tcp или локальный протокол нет. И понятно, почему – протокол в случае gbak -se определяет способ соединения с сервером и передачи ему команды. Дальше протокол в процессе backup не участвует.
Старый локальный протокол, в Firebird 1.5 и InterBase 2007 – совсем ужасен.
Замена процессора в данном случае дает мало выгоды, т. к. диски остались те же самые. Как в среднем шел бэкап около 3.5-4 минут, так он и идет.

Несмотря на то, что на тест было потрачено около 8-ми часов, и для некоторых серверов тест повторялся по 3 и даже 4 раза, остались сомнения – уж больно результат неожиданный. Поэтому повторение теста на ваших системах, и опровержение и подтверждение – приветствуется. Пишите на support@ibase.ru.