 |
|
|
|
Виртуальные войны, или Сравнительное тестирование VMware Workstation и Cooperative Linux
Виртуальные войны Сравнительное тестирование VMware Workstation и Cooperative Linux There are three kinds of lies: lies, damned lies and benchmarks В рассмотрении работы любых систем, в том числе и виртуальных машин, значительную роль играет производительность. Ведь для любой системы, работающей в реальных условиях, важна не только ее функциональность, но и общая скорость работы, в том числе и в сравнении с другими решениями, присутствующими на рынке. Для оценки производительности, как правило, используются пакеты, состоящие из различных тестов, измеряющих производительность всех основных компонентов системы. Тесты могут измерять как абсолютную производительность того или иного компонента (синтетические тесты), так и скорость работы определенной программы (тесты-приложения). Тесты первой категории позволяют измерить пиковую производительность системы, которая, скорее всего, никогда не будет достигнута при работе реальных программ. Тесты-приложения, напротив, показывают, насколько полно та или иная программа использует потенциал рассматриваемой системы. В данной статье эти и другие «азы тестирования» будут применены на практике. Речь пойдет о сравнительном тестировании VMWare и Cooperative Linux. Кроме того, их результаты будут также соотнесены с производительностью обычного Linux, работающего в монопольном режиме. Методика тестирования Идея тестирования, в том числе и Linux, не нова. За все время своего существования Linux обзавелся огромным количеством тестов, измеряющих производительность не только различных компонентов системы, но и работающих в нем приложений. Некоторые из этих тестов уже де-факто стали стандартами тестирования, в то время как другие лишь завоевывают себе место под солнцем. Поэтому для того, чтобы в n-й раз не изобретать велосипед, разрабатывая пакеты тестов, специфичные для виртуальных машин, было принято решение использовать уже существующие и «проверенные» тестовые пакеты. В качестве основы для методики проведения тестов использовались Linux Benchmarking Toolkit (LBT) и Scalable Test Platform (STP), которые по необходимости дополнялись специфичными тестами. В итоге тестируемые системы были изучены при помощи следующих тестовых пакетов:
Этот набор включает как синтетические тесты, измеряющие производительность основных подсистем (целочисленная и плавающая арифметика, производительность подсистемы памяти и жесткого диска, операции ввода-вывода и т. д.), так и тесты приложений (компиляция ядра). Более подробно с методикой тестирования в рамках LBT можно ознакомиться на странице http://www.tldp.org/HOWTO/Benchmarking-HOWTO-3.html. Тесты выполнялись на компьютере следующей конфигурации:
Следует отметить, что ввиду архитектурных особенностей при тестах coLinux использовалось ядро Linux, модифицированное патчами coLinux (описание архитектуры coLinux можно найти в статье [1]). Для VMWare и «чистой» системы использовалось ядро 2.4.27, собранное в конфигурации по умолчанию. При проведении тестов основной акцент делался не на измерении производительности систем в абстрактных «попугаях», а на определении того, какая из них выполняет тот или иной тест наиболее эффективно. Теоретическое отступление Прежде чем приступить к рассмотрению реальных тестов и их результатов посмотрим более подробно на сегодняшних претендентов. Итак:
У каждого из этих подходов есть свои «за» и «против». Так, для того чтобы запустить ОС в VMWare, не требуется прикладывать практически никаких усилий. С другой стороны, для запуска существующего Linux из coLinux, при прочих равных, придется как минимум пересобрать ядро с патчами coLinux. Кроме того, coLinux не поддерживает таких вещей, как «прямая работа с USB-устройствами», видеокарты и оборудование вообще. И если с USB-устройствами все-таки можно работать (через интерфейс блочных устройств), то о запуске X-сервера непосредственно на coLinux можно забыть. Конечно, в качестве X-cервера можно использовать какой-нибудь Cygwin/X, XWin-PRO, Mi-X или HumningBird Exceed, установленный на Windows. Однако мой опыт работы с Windows X-серверами показал, что такое решение на данный момент слабо пригодно для ежедневного использования – уж очень низка производительность X-приложений. Справедливости ради нужно сказать, что субъективная скорость работы X-сервера в VMWare тоже далека от совершенства. Однако, безусловно, этот вопрос требует дальнейшего изучения, которое выходит за рамки данной статьи. С точки зрения производительности остальных компонентов ситуация неоднозначна. С одной стороны, VMWare – типичная виртуальная машина (к тому же работающая на большом количестве платформ), поэтому ей должны быть присущи некоторые накладные расходы, вызванные необходимостью эмуляции «слоя виртуализации», обеспечивающего интерфейс «известного» оборудования. Ситуация с coLinux несколько иная. Компьютер эмулируется не полностью (в отличие от VMWare). Ядро содержит минимум функциональности для работы с оборудованием, поэтому скорость работы системы во многом зависит от эффективности используемых драйверов и скорости работы самой ОС Windows. В случае VMWare производительность, конечно, тоже зависит от производительности Windows, однако она также во многом зависит и от скорости работы самого ядра «гостевой» системы. Поэтому для достижения наибольшей производительности в VMWare, необходимо скомпилировать ядро с поддержкой «виртуального» оборудования. Теоретически подход, используемый coLinux, может обеспечить большую производительность (за счет отсутствия слоя виртуализации). Так это или нет, проверим на тестах. Производительность процессора Многие пользователи Linux-систем для определения производительности процессора используют BogoMIPS – внутреннюю переменную ядра, косвенно отражающую скорость работы процессора. Сами разработчики ядра утверждают, что BogoMIPS не является показателем производительности процессора и относиться к нему как тесту сколь-нибудь серьезно нельзя. Тесты рассматриваемых сегодня систем это только подтверждают: на всех виртуальных машинах число BogoMIPS абсолютно одинаково – 3696. Ну что же, давайте посмотрим, что скажут тестовые пакеты. nbench – данный пакет измеряет, во сколько раз показатели производительности данной системы превосходят эталонную (Pentium-90 и K6-233). Результатом его работы является набор индексов производительности подсистемы памяти, целочисленных операций и операций с плавающей точкой. Тест запускался с параметрами по умолчанию. В целях экономии места приведены данные относительно эталона K6-233 (для Pentium-90 ситуация выглядит аналогично).
Рисунок 1 Что же, процессор, он и есть процессор. Все три рассматриваемые системы идут практически вровень. Подсистема памяти Для измерения производительности подсистемы памяти использовался низкоуровневый пакет синтетических тестов lm_bench. В состав данного пакета входит несколько утилит, измеряющих производительность базовых операций (чтение, запись, копирование, произвольное чтение и т. д.) применительно к различным компонентам ОС (подсистема памяти, tcp, pipes, sockets и т. д.).
Рисунок 2 Для тестирования подсистемы памяти использовалась утилита bw_mem. При запуске ей передавались следующие параметры: # bw_mem -P 1 -W 1 1024K rd|wr|cp Для каждой машины измерялась скорость чтения (rd), записи (wr) и копирования (cp). Для тестирования в условиях многопоточности тест на каждой машине запускался для трех параметров P – 1, 10 и 50. (Так как расхождение результатов для 1 и 50 потоков составило менее 1%, на диаграмме приводится усредненное значение всех трех экспериментов). Итак, все рассматриваемые «виртуальные» машины одинаково эффективно работают с памятью. При чтении coLinux оказался несколько быстрее VMWare, однако выигрыш является настолько несущественным, что вполне может быть списан на погрешности измерения. Дисковая подсистема Для тестирования дисковой подсистемы использовался второй жесткий диск, разбитый на два раздела. Первый раздел был отформатирован в файловую систему ext2 (3 Гб), на которую был записан Gentoo-Linux из образа, взятого с сайта coLinux. Этот раздел использовался при тестировании Linux, VMWare и coLinux (в тестах обозначена как «*_part»). Второй раздел был отформатирован в ntfs (10 Гб) и использовался для измерения производительности дисковой подсистемы coLinux и VMWare в случае, если образ файловой системы хранится в виде файла. При проведении тестов в Linux добавлялась поддержка чипсета SIS5513, в VMWare – чипсета PIIX. В обоих случаях при тестировании были включены режим DMA и 32-битный режим работы с диском. Виртуальный диск в файл-образе в тесте с VMWare подключался к интерфейсу IDE. В организации дисковых подсистем наших подопытных есть некоторые отличия. Как было отмечено выше, VMWare – типичный представитель виртуальных машин, и дисковая подсистема в ней реализована соответствующим образом, а именно эмуляцией контроллера IDE чипсета Intel i440BX. С coLinux же ситуация обстоит несколько иначе: он не работает с устройствами напрямую (ядро собирается без поддержки шины PCI и соответственно без контроллера IDE). Диск эмулируется специальным драйвером блочных устройств, работающих с Windows-демоном coLinux. По этой причине было принято решение в пользу измерения производительности диска не низкоуровневыми утилитами (например, hdparm), а измерением скорости работы с файловой системой. Однако для того, чтобы уменьшить влияние файловой системы на результаты тестов, использовалась нежурналируемая (и соответственно более быстрая) файловая система ext2fs. При построении «виртуальной» системы можно использовать два основных подхода:
В первом случае на производительность дисковых операций в Linux накладывается дополнительное влияние файловой системы (скорость доступа, фрагментация и т. д.) и ее драйвера. Второй случай этих проблем лишен, поэтому производительность «виртуальных» систем на отдельном разделе должна быть выше. Итак, перейдем к первому тесту – последовательное чтение блока данных. В данном тесте с диска последовательно считывается файл размером 256 Мб (блоками по 4 Кб). Для имитирования ситуации многозадачности тест проводится для 1, 2, 4 и 8 потоков.
Рисунок 3 Быстрее всех с диском работает «чистый» Linux, затем идут VMWare и coLinux, работающие с выделенным разделом. В случае одного потока производительность vmware выше coLinux, однако с увеличением количества потоков coLinux несколько вырывается вперед. Медленнее всего работают VMWare и coLinux, использующие образ root-файловой системы на существующем разделе, хотя VMWare все же показывает чуть более высокую производительность.
Рисунок 4 При произвольном чтении ситуация несколько меняется. Явно лидирует «чистый» Linux, все виртуальные машины показывают примерно одинаковую и достаточно низкую скорость. В следующем тесте измеряется скорость последовательной записи на диск.
Рисунок 5 «Чистый» Linux, как всегда, впереди. За ним идут coLinux и VMWare в различных конфигурациях дисковой подсистемы. С увеличением количества потоков производительность всех систем сравнивается. Тест произвольной записи:
Рисунок 6 А вот и первая неожиданность: скорость записи у coLinux и VMWare оказалась больше, чем у «чистого» Linux. Причиной этому, скорее всего, является кэширование обращений к диску, производимое ОС Windows. Для проверки этой гипотезы проведем тест с помощью другой утилиты – bonnie++ (sequential output, per block, size 300 Мб).
Рисунок 7 Ситуация в целом такая же, хотя и имеются некие расхождения, причина которых, скорее всего, кроется в высокоуровневой природе тестов. Производительность TCP/IP Как VMWare, так и coLinux поддерживают различные типы организации взаимодействия между реальной и виртуальной машинами. Основными являются bridged и NAT (более подробное описание можно найти в статье [1]). Для получения более полного представления об обоих исследуемых виртуальных системах тестирование каждой их них проводилось как в режиме bridged, так и NAT. Отличительной особенностью «сетевых» тестов является то, что для измерения производительности всегда требуется «вторая сторона», выступающая при передаче в качестве партнера. Причем крайне желательно, чтобы такой партнер был заведомо быстрее, при этом он не будет являться узким местом и его производительность не окажет существенного влияния на производительность измеряемой системы. В роли такого партнера в данном тесте использовался заведомо более быстрый компьютер – Pentium-4 – 2.4 ГГц (сетевой интерфейс Intel PRO 100), также работающий под управлением Linux (дистрибутив Gentoo). В тестах использовался пакет ttcp, измеряющий производительность TCP- и UDP-передач. Тест запускался 5 раз, в качестве результата приводится среднее значение.
Рисунок 8 Первыми в данном тесте пришли Linux и VMWare в режиме bridged. Их скорость (91 Мбит/с) оказалась близка к максимальной теоретически достижимой. На третьем месте оказался coLinux в режиме NAT (скорость составила около 42 Мбит/с). Самыми медленными оказались coLinux в режиме bridged и VMWare в режиме NAT. Производительность каналов (pipes) Канал (Pipe) – способ межпроцессного взаимодействия, реализованный во всех популярных системах (Windows, Linux и др.), активно используемый многими приложениями. Для тестирования производительности каналов использовался тест bw_pipe, входящий в пакет lmbench. Данный тест создавал канал между двумя процессами и блоками 64 Кб передавал по нему 32 Мб данных: # bw_pipe -P 1 -W1 -M 32768K Результаты теста отражены в таблице:
Рисунок 9 Linux, как ему и положено, держится впереди. coLinux в данном тесте опережает VMWare более чем в 2 раза. Компиляция ядра Для оценки общей производительности системы выполнялась привычная многим операция – компиляция ядра Linux. Этот тест ценен не только достаточно показательным практическим результатом (в процессе компиляции активно используются процессор, память и дисковая подсистема), но и тем, что практически все люди, активно работающие с Linux, время от времени пересобирают ядро. В качестве «подопытного» использовалось ядро версии 2.4.27 со стандартными опциями конфигурации ядра (make oldconfig). При тестировании в VMWare и coLinux root-файловая система находилась на ext2-разделе второго жесткого диска. Время компиляции ядра измерялось с помощью утилиты time (время выполнения make dep не учитывалось): # time make vmlinux Тест в каждой системе выполнялся 3 раза, на диаграмме приводится усредненное время компиляции (чем меньше, тем лучше):
Рисунок 10 Быстрее всех с задачей справился «чистый» Linux – 6 минут и 5 секунд. Вторым финишировал coLinux – 6 минут 32 секунды. На последнем месте (с достаточно большим отрывом) оказалась VMWare Workstation– 9 минут 13 секунд. Выводы Итак, несколько слов о результатах. В тестах процессора и подсистемы памяти все тестируемые сегодня системы показали практически равные результаты, так что если главной для вас задачей, решаемой Linux, является задача вычислительная, то можете смело использовать любую из систем. В качестве дисковой подсистемы для виртуальной машины можно использовать как выделенный Linux-раздел, так и файл-образ на уже существующем fat или ntfs-разделе (хотя первый вариант все-таки выглядит более привлекательно). Ethernet. Если же вам необходим полноценный 100 Мбит сетевой интерфейс в виртуальном Linux, то следует обратить внимание на VMWare Workstation. Разработчики bridged-драйвера VMWare действительно поработали на славу, обеспечив производительность, практически не уступающую «чистой» Linux-системе. Производительность сетевой подсистемы coLinux можно назвать приемлемой только в режиме NAT. В режимах coLinux-bridged и VMWare-NAT «серьезно» использовать сеть, скорее всего, не получится – уж больно низка производительность. И напоследок позвольте сказать еще несколько слов. Решение о том, использовать ту или иную систему или нет, всегда должно приниматься с учетом условий и реалий решаемой задачи, главное при этом не забывать, что «There are three kinds of lies: lies, damned lies and benchmarks». Литература, ссылки:
|
МИХАИЛ ПЛАТОВ
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
