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 гигабайта)
Дисковая конфигурация практически не изменилась:
C:
ST3160815AS (160GB), SATA II
D: ST3200827AS (200GB), SATA II
E: HDS728080PLA380 (82GB), SATA I
то есть, диски D и E остались на месте.
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.
Несмотря на то, что на тест было потрачено около 8-ми часов, и для некоторых серверов тест повторялся по 3 и даже 4 раза, остались сомнения - уж больно результат неожиданный. Поэтому повторение теста на ваших системах, и опровержение и подтверждение - приветствуется. Пишите на support@ibase.ru.