Pull to refresh
0
TrueVDS
Виртуальные серверы с гарантированными ресурсами

Мифические тормоза диска на Xen

Reading time 3 min
Views 2.7K
Часто при обсуждении различных способов виртуализации, сторонники Virtuozzo (обычно, хостеры на OpenVZ) вспоминают про услышенное когда-то и где-то утверждение типа «Xen тормозит при работе с диском». Заблуждение это имеет корни, связанные с радикально отличающимися механизмами кэширования диска у виртуальных машин Xen и контейнеров Виртуоззо. Как следствие, сильно отличаются при различных условиях характеристики производительности дисковой системы. Но заблуждение оседает в сознании крепко и надолго.

Чтобы закрыть тему «тормозов диска у Xen» и показать с цифрами, что тормозов нет, вот результаты unixbench, bonnie++ и упаковки исходников линуксовского ядра на одной и той же машине, на одном и том же разделе диска.


Процессор: Intel® Core(TM)2 Quad CPU Q6600 @ 2.40GHz. Диск — какой-то SATA Samsung.

Native — замер на физической машине: 1 CPU, 256 Mb RAM. Kernel: 2.6.18-164.6.1.el5
Xen PV — замер на виртуальной машине Xen в режиме паравиртуализации: 1 CPU, 256 Mb RAM. DomU kernel: 2.6.18-164.el5xen. Dom0 kernel: 2.6.18-164.el5xen. Диск в виртуальную машину отдается как phy.

Unixbench.


Очень синтетический тест, особенно для диска, но его часто любят использовать в аргументах. Вырезка того, что относится к диску:

Native

File Copy 1024 bufsize 2000 maxblocks 3960.0 529094.5 1336.1
File Copy 256 bufsize 500 maxblocks 1655.0 153098.5 925.1
File Copy 4096 bufsize 8000 maxblocks 5800.0 1208281.0 2083.2


Xen PV

File Copy 1024 bufsize 2000 maxblocks 3960.0 542862.3 1370.9
File Copy 256 bufsize 500 maxblocks 1655.0 153684.5 928.6
File Copy 4096 bufsize 8000 maxblocks 5800.0 1212533.2 2090.6


Жирным текстом выделены итоговые числа — чем больше, тем лучше. Видно, что на физическом железе, и в виртуальной машине, числа почти равны, в виртуальной машине даже немного больше. Казалось бы, нарушение закона сохранения энергии, но объясняется просто — небольшую часть нагрузки (около процента) принимает на себя подсистема ввода-вывода, которая находится снаружи виртуальной машины, в dom0 и выполняется на другом ядре.

bonnie++


Native

Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
dev.home 1G 575 99 64203 13 29238 5 1726 96 68316 6 144.5 1
Latency 14923us 1197ms 483ms 60674us 16858us 541ms
Version 1.96 ------Sequential Create------ --------Random Create--------
dev.home -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
256 47219 67 304464 100 23795 31 51813 73 378017 100 6970 9
Latency 575ms 846us 673ms 416ms 22us 1408ms


Xen PV

Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
CentOS_5_4 1G 815 99 65675 4 29532 0 1739 92 68298 0 134.1 0
Latency 10028us 200ms 242ms 122ms 15356us 627ms
Version 1.96 ------Sequential Create------ --------Random Create--------
CentOS_5_4 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
256 53015 61 325596 99 25157 23 58020 68 404162 99 6050 5
Latency 605ms 771us 686ms 406ms 49us 2121ms


Более разносторонняя оценка, но опять же, немного странный результат — в некоторых случаях опять Xen PV быстрее.

Архивирование

А можно посмотреть на результат нормальной, реальной задачи. Упаковка в архив* исходников ядра линукса — задача с интенсивным чтением диска. Суммарный размер — около 320 Мб, почти 24 тыс. файлов. Перед упаковкой дисковый кэш очищался через vm.drop_caches.

Native
$ time (find linux-2.6.26 | cpio -o > /dev/null)
530862 blocks

real 0m30.247s
user 0m0.605s
sys 0m2.411s


Xen PV
$ time (find linux-2.6.26 | cpio -o > /dev/null)
530862 blocks

real 0m32.396s
user 0m0.052s
sys 0m0.120s


Разница во времени — чуть меньше 7%, достаточно обычный оверхед на виртуализацию. Это и есть та потеря производительности, которая распространяется на большинство паттернов работы с диском. Если у вас задача уперлась в диск, плюс или минус 7% существенно ситуацию не изменят.

* Использовать cpio вместо tar приходится из-за того, что tar настолько хитроумен, что обнаружив вывод в /dev/null, он включает dry run и ничего не архивирует.
Tags:
Hubs:
+10
Comments 33
Comments Comments 33

Articles

Information

Website
www.truevds.ru
Registered
Founded
Employees
2–10 employees
Location
Россия