форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Открытые системы на сервере (Виртуализация / Linux)
Изначальное сообщение		[ Отслеживать ]

"что быстрее(>iops) raw vs qcow2 vs block lvm dev для гостя kvm"	+/–
Сообщение от netc (ok) on 30-Май-11, 10:08
Есть сервер с kvm. Развертывается виртуальная машина с W2K3 - Сервер Терминалов для сети из 20 пользователей. Для гостя будет использоваться mdadm raid 10 из обычных 7200k винтов. Гость будет работать на устройстве virtio. Интересует какая из систем хранения для гостя будет более производительна ? Блочное устройство LVM, qcow2 образ, raw образ ? Остальное(фишки) не интересуют. Интересует именно производительность.
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "что быстрее(>iops) raw vs qcow2 vs block lvm dev для гостя kvm"	+/–
Сообщение от PavelR (??) on 30-Май-11, 18:42
> Есть сервер с kvm. > Развертывается виртуальная машина с W2K3 - Сервер Терминалов для сети из 20 > пользователей. > Для гостя будет использоваться mdadm raid 10 из обычных 7200k винтов. > Гость будет работать на устройстве virtio. > Интересует какая из систем хранения для гостя будет более производительна ? > Блочное устройство LVM, qcow2 образ, raw образ ? > Остальное(фишки) не интересуют. Интересует именно производительность. исходя из принципов размещения образов - в файловой системе, которая потом хранится в некоем блочном устройстве - чистое блочное устройство должно быть быстрее, чем образ, размещенный в файловой системе. Хотя, могу высказать предположение, что образы в виде файлов могут быть еще и закешированными в память хост-системы - так что на чтение может быть и некий выигрыш, но точно не на запись.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "что быстрее(>iops) raw vs qcow2 vs block lvm dev для гостя kvm"	+/–
	Сообщение от netc (ok) on 31-Май-11, 08:40
	>[оверквотинг удален] >> Гость будет работать на устройстве virtio. >> Интересует какая из систем хранения для гостя будет более производительна ? >> Блочное устройство LVM, qcow2 образ, raw образ ? >> Остальное(фишки) не интересуют. Интересует именно производительность. > исходя из принципов размещения образов - в файловой системе, которая потом хранится > в некоем блочном устройстве - чистое блочное устройство должно быть быстрее, > чем образ, размещенный в файловой системе. > Хотя, могу высказать предположение, что образы в виде файлов могут быть еще > и закешированными в память хост-системы - так что на чтение может > быть и некий выигрыш, но точно не на запись. я тут за это время проверил, оказалось, использование lvm практически без проигрышное. а вот тесты hd tune под hyper-v врут - и очень сильно врут. в 10 раз больше показывают, хотя это невозможно превысить показания железа в 10 раз - это аномально
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "что быстрее(>iops) raw vs qcow2 vs block lvm dev для гостя kvm"	+/–
Сообщение от Zl0 (ok) on 01-Июн-11, 19:44
> Есть сервер с kvm. > Развертывается виртуальная машина с W2K3 - Сервер Терминалов для сети из 20 > пользователей. > Для гостя будет использоваться mdadm raid 10 из обычных 7200k винтов. > Гость будет работать на устройстве virtio. > Интересует какая из систем хранения для гостя будет более производительна ? > Блочное устройство LVM, qcow2 образ, raw образ ? > Остальное(фишки) не интересуют. Интересует именно производительность. Хостовая система  #1 /dev/sda1: Timing cached reads:   14340 MB in  2.00 seconds = 7178.48 MB/sec Timing buffered disk reads: 176 MB in  3.00 seconds =  58.67 MB/sec KVM запущенный на raw образе #1 /dev/hda1: Timing cached reads:   13328 MB in  2.00 seconds = 6677.88 MB/sec Timing buffered disk reads:  164 MB in  3.01 seconds =  54.47 MB/sec Хостовая система #2 /dev/sda1: Timing cached reads:   7064 MB in  2.00 seconds = 3535.48 MB/sec Timing buffered disk reads: 222 MB in  3.01 seconds =  73.72 MB/sec KVM использует том LVM,  iface=virtio /dev/vda1: Timing cached reads:   6396 MB in  2.00 seconds = 3202.84 MB/sec Timing buffered disk reads: 140 MB in  3.04 seconds =  46.01 MB/sec Не знаю даже чем объяснить, но KVM которые использует LVM том напрямую, не очень то выигрывает в скоросте при работе с диском чем хостовая система, напротив KVM использующий raw образ почти не испытывает оверхед при работе с диском. Вобщем возьмите да померьте все варианты, заодно и нам раскажите.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "что быстрее(>iops) raw vs qcow2 vs block lvm dev для гостя kvm"	+/–
	Сообщение от PavelR (??) on 01-Июн-11, 20:13
	----------- > Не знаю даже чем объяснить, но KVM которые использует LVM том напрямую, > не очень то выигрывает в скоросте при работе с диском чем > хостовая система, напротив KVM использующий raw образ почти не испытывает оверхед > при работе с диском. ---- > Вобщем возьмите да померьте все варианты, заодно и нам раскажите. Я там выше писал: >Хотя, могу высказать предположение, что образы в виде файлов могут быть еще и >закешированными в память хост-системы - так что на чтение может быть даже и некий выигрыш, но точно не на запись.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	7. "что быстрее(>iops) raw vs qcow2 vs block lvm dev для гостя kvm"	+/–
	Сообщение от netc (??) on 02-Июн-11, 14:59
	> Не знаю даже чем объяснить, но KVM которые использует LVM том напрямую, > не очень то выигрывает в скоросте при работе с диском чем > хостовая система, напротив KVM использующий raw образ почти не испытывает оверхед > при работе с диском. А что такое оверхед ? Можете объяснить простыми словами. Чем он плох и каков должен быть ? > Вобщем возьмите да померьте все варианты, заодно и нам раскажите. Да вот померил, Только мерил я hdtune pro. Первое из того, что попалось. К моему сожалению: 1. выбрал именно её 2. она shareware ;(. Ранее эту программу постоянно встречал в обзорах, поэтому и выбрал без особых изысканий. В тему: нашел на просторах сети вот такое сравнение ide vs virtio в программе hd tune: http://openadmins.ru/blog/virtio-ide-benchmark-windows2008srvr2 У них virtio побеждает ide disk с двойным отрывом. Облизался, цифры показались интересными и пошел тестить этой HD TUNE PRO, дабы убедится лично. Тестил только на чтение, просто решил что этого будет достаточно. Результаты в Мегабайтах в секунду! Ведь dd выдает результаты скорости в Мегабитах ???? Гость везде - win2k3. 1-я Хост система, Core 2 Quad 8400: том md0 - raid10 на нем lvm И тут я выявил некоторую проблему самого hd tune. Если ФС гостя располагается в блочном устройстве lvm - то hd tune показывает нормальные, т.е. очень близкие результаты к реальным результатам работы ввода/вывода моих винтов в режиме raid10. Если поместить фс в файл, например qcow или тот же vhd(vpc) то результаты выходят за рамки разумного. LVM: benchmark read, ide device (lvm block device over md-raid10) - average speed 119 Mb/sec benchmark read, virtio device (lvm block device over md-raid10) - average speed 127 Mb/sec QCOW2 File over ext4, ext4 over LVM: benchmark read, ide device (qcow2 in ext4 over lvm block device over md-raid10) - average speed 456 Mb/sec benchmark read, virtio device (qcow2 in ext4 over lvm block device over md-raid10) - average speed 543 Mb/sec Странные результате во втором забеге, не правда ли ? А ведь практически ни чего не менялось ;) выводы: 1. hd tune - зло, которое показывает реальную скорость чтения диска только если гость работает с блочным устройством; почему реальную ? ОТВЕТ: я посмотрел результаты тестов этих винтов с сайта hd tune: примерно 60-70 Мегабайт/сек. Скорость массива уровня 10 должна быть примерно в два раза больше. Мы видим это из теста С LVM, эти скорости равны 119 и 127 мегабайт в секунду. Это примерно! примерно! больше в два раза скорости работы винта в одиночку. И примерно должно быть равно скорости работы подсистемы IO в хостовой системе. По крайней мере быть намного больше скорость не может, из-за физических ограничений накопителей. 2. virtio disk немного (по сравнению с обзором с сайта openadmins), но все таки обгоняет ide disk по скорости чтения 3. по ощущениям - разницы при работе с гостем незаметно. 2-я Хостсистема. (переделанный десктоп Core 2 Duo 6600) Пройдем дальше. У меня есть еще один сервер . Что дают на том и работаю. ;). Планировался как хранилище, и запас на случай выхода из строя основного виртуального. Сервер с md0 raid5 (4 диска wd1000ears - 5400 rpm). Результаты не много интереснее. Разница почти в два раза по скорости при использовании ide vs virtio. да и сами скорости уже другие - есть подозрение что это 5-й рейд работает быстрее 1-го из 4-х 7.2к винтов. ;) benchmark read, ide device (lvm block device over md-raid5) - average speed 374 Mb/sec benchmark read, virtio device (lvm block device over md-raid5) - average speed 735 Mb/sec Опять же результаты странные, скорее всего из за работы в файле а не с блочным устройством. raid5 получается быстрее raid10 ;( в теории именно так и есть, но увы для продакшен сервера не совсем подходит, а вот для подменного на время - очень даже ни чего. 3-я хост система (hyperv) Пройдем дальше: для сравнения этот же гость на сервере w2k8 с hyperv (система и раздел ntfs с гостями в *.vhd формате (диск D:) на аппаратном raid1 от контроллера в HP ML150G6, винты обычные 7200 seagate 500gb) benchmark read, hyperv guest additions installed (disk d:(ntfs) vhd image) - average speed 886 Mb/sec Результат конечно далек от справедливости(из за hd tune). Но все же заставляет задуматься о странных различиях в тестах;) По ощущениям - на hyper-v винда грузится гораздо медленнее. Разницы в работе с vhd или qcow2 практически нет для kvm. Отсюда вывод не обязательно делать kvm-img convert -O qcow2 /mybook/temp/vt.vhd /mybook/temp/vt.vhd.qcow2 По крайней мере я для себя сделал такой вывод исходя из результатов тестов на хост системе № 1 с рейдом 10. Смотрите ниже: benchmark read, virtio device (vhd in ext4 over lvm block device over md-raid10) - average speed 549 Mb/sec benchmark read, virtio device (qcow2 in ext4 over lvm block device over md-raid10) - average speed 543 Mb/sec Тем более, что мне всегда может понадобится перенос гостей с kvm сервера на hyper-v сервер и обратно. Ох устал я уже от этих тестов ;( Ну а продолжим. По хорошему конечно надо еще на lvm 2-й и 3-й вариант проверить. Сказано - сделано! Берем хост систему №2 с 5 рейдом и все того же гостя, накатываю акронисом образ с разделами С и D винды на lvm block device и вперед: benchmark read, ide device (lvm block device over md-raid5) - average speed 158 Mb/sec benchmark read, virtio device (lvm block device over md-raid5) - average speed 156 Mb/sec И видим мы реальные результаты с точки зрения работы железа и 5 рейда. Но увы разницы между использованием virtio и ide диска - практически НЕТ. Странно. Очень странно. Если сравнить их с самым первым замером, т.е. с benchmark read, ide device (lvm block device over md-raid10) - average speed 119 Mb/sec benchmark read, virtio device (lvm block device over md-raid10) - average speed 127 Mb/sec То все вполне объяснимо 5 рейд работает быстрее на чтение, даже чем 10. Но почему нет разницы между virtio и ide дисками ???? Не понимаю. Теперь давайте, все же попытаемся сравним работу сервера hyper-v с kvm если оба используют файл в качестве жесткого диска (результаты берем из тестов выше): benchmark read, HYPERV SERVER server hyperv guest additions installed (disk d:(ntfs) vhd image) - average speed 886 Mb/sec benchmark read, virtio device (qcow2 in ext4 over lvm block device over md-raid10) - average speed 543 Mb/sec benchmark read, virtio device (lvm block device over md-raid5) - average speed 735 Mb/sec Если цифры не врут - то вывод подсистема ввода-вывода kvm - не дотягивает до hyper-v Если врут, значит врёт hd tune. Вот так. Жду ваших комментариев. Пока писал ответ, получил новые комментарии в свой пост. Отвечу на них позже. Есть вопросы ;)
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "что быстрее(>iops) raw vs qcow2 vs block lvm dev для гостя kvm"	+/–
Сообщение от миха228 on 02-Июн-11, 13:52
на блочном уст-ве и на LVM2 скорость будет примерно одинакова - чуть выше raw на ФС и довольно значительно выше qcow2 (назначение у последнего несколько иное) обязательно нужно включать aio=native можно так же поиграться с параметром cache, вплоть до =nosafe если бекапы под рукой всегда))
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "что быстрее(>iops) raw vs qcow2 vs block lvm dev для гостя kvm"	+/–
	Сообщение от миха228 on 02-Июн-11, 14:00
	> на блочном уст-ве и на LVM2 скорость будет примерно одинакова - чуть > выше raw на ФС и довольно значительно выше qcow2 (назначение у > последнего несколько иное) > обязательно нужно включать aio=native > можно так же поиграться с параметром cache, вплоть до =nosafe если бекапы > под рукой всегда)) все это справедливо для cache=none, что как-бы стандартно для продакшн (по очевидным причинам). с включенным же кешированием и закешированными данными скорость raw-образа на ФС может значительно выше быть...
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	8. "что быстрее(>iops) raw vs qcow2 vs block lvm dev для гостя kvm"	+/–
	Сообщение от netc (??) on 02-Июн-11, 16:06
	> на блочном уст-ве и на LVM2 скорость будет примерно одинакова - чуть > выше raw на ФС и довольно значительно выше qcow2 (назначение у > последнего несколько иное) > обязательно нужно включать aio=native > можно так же поиграться с параметром cache, вплоть до =nosafe если бекапы > под рукой всегда)) а вот здесь пишут: https://access.redhat.com/kb/docs/DOC-41298 что не в коем случае не включать на файлах-образах, к тому же на не выровненных файлах образах относительно блоков данных. там написано что относительно файловой системы. а как же может быть относительно физического устройства ? раз я и не только я используем несколько уровней абстракции, сначала обычный разделы на винте, потом mdadm разделы, потом lvm разделы, у уже поверх этих lvm работаем с информацией. это ведь тоже может влиять на скорость работы, например вместо одного блока всегда считываются два, потому, что размер блока файловой системы не выровнен относительно  блоков жесткого диска и всех там mdadm-ов, lvm-ов. жуть какая-то, сколько всего нужна знать, учитывать, понимать - а ведь только с опытом узнаешь - не где не учат такому ;) спасает ли нас блочное устройство(mdadm device или lvm) в этом случае ? как проверить выравненность блочного устройства относительно блоков на физическом устройстве ? aio по умолчанию включается, и если да то для каких устройств хранения ? какая разница в приросте с ним и без него ? По поводу cache я везде тестировал с writeback. Он дает ощутимый прирост в скорости. Отказывается я от него не хотел бы. Можно ли использовать cache=writeback на образе qcow2 ? Можно ли использовать cache=writeback на lvm или блочном устройстве ? Когда можно использовать aio=native ?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	9. "что быстрее(>iops) raw vs qcow2 vs block lvm dev для гостя kvm"	+/–
	Сообщение от миха228 on 03-Июн-11, 17:56
	> что не в коем случае не включать на файлах-образах, к тому же там пишут не включать aio=native совместно с cache=none на ФС ext4 и XFS ну так не включайте...  к тому же там описано как избежать потерь данных (порчи), если таки нужно включать. я себе слабо представляю когда оно нужно, все же в серьезных системах образы гостей хранить поверх ФС никакого смысла нет > спасает ли нас блочное устройство(mdadm device или lvm) в этом случае ? это обычная практика для хранения образов. в т.ч. и сетевое блочное уст-во > как проверить выравненность блочного устройства относительно блоков на физическом устройстве ? http://www.linux.org.ru/wiki/en/Special:Print?topic=%D0... > aio по умолчанию включается, и если да то для каких устройств хранения ? по умолчанию там "безопасное" aio=threads > какая разница в приросте с ним и без него ? при aio=native скорость приближается к скорости уст-ва, при threads раза в 2 медленней > По поводу cache я везде тестировал с writeback. Он дает ощутимый прирост > в скорости. > Отказывается я от него не хотел бы. > Можно ли использовать cache=writeback на образе qcow2 ? > Можно ли использовать cache=writeback на lvm или блочном устройстве ? да, да, да > Когда можно использовать aio=native ? если не используется ФС (ext4/xfs) и не используется cache=none
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	10. "что быстрее(>iops) raw vs qcow2 vs block lvm dev для гостя kvm"	+/–
	Сообщение от netc (??) on 06-Июн-11, 09:14
	спасибо за ссылку про выравнивание! - то что надо, сохранил. >если не используется ФС (ext4/xfs) и не используется cache=none и ТО(fs ext4/xfs) и без включенного кэша ? т.е. с включенным кэшем, например writeback и образом на фс ext3/xfs можно смело использовать aio=native, что позволит добиться скорости работы устройства ввода-вывода в виртуальной машине в два раза быстрее ??? или с блочным устройством и отключенным кэшем - тоже ведь по идее можно безопасно включать этот aio=native ? или же имеется в виду логическое ИЛИ ? извините, но хочу раз и навсегда понять. если да то это более чем интересно ;) а что нибудь можете сказать по поводу разницы в тестах на hyper-v и kvm описанных мной в этом посте ? может что нибудь подобное aio=native используется и в hyper-v. просто откуда такие скорости там получаются более 800 Мб/сек ? еще вопрос: А Async IO в линуксе по умолчанию включён ?
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	11. "что быстрее(>iops) raw vs qcow2 vs block lvm dev для гостя kvm"	+/–
	Сообщение от миха228 on 14-Июн-11, 21:23
	> и ТО(fs ext4/xfs) и без включенного кэша ? не совсем понял вашего вопроса... дело в том, что в режиме aio и без кеширования данные будут писаться в обход fs. отсюда и глюки на некоторых ФС при некоторых условиях > т.е. с включенным кэшем, например writeback и образом на фс ext3/xfs можно > смело использовать aio=native, что позволит добиться скорости работы устройства ввода-вывода > в виртуальной машине в два раза быстрее ??? да просто aio=native будет однозначно быстрей, чем "умолчательное" =threads > или с блочным устройством и отключенным кэшем - тоже ведь по идее > можно безопасно включать этот aio=native ? можно и нужно > а что нибудь можете сказать по поводу разницы в тестах на hyper-v > и kvm описанных мной в этом посте ? может что нибудь > подобное aio=native используется и в hyper-v. просто откуда такие скорости там > получаются более 800 Мб/сек ? там объективны, имхо, только первые два результата. в остальных случаях вы мерили эффективность кэша ФС)) > еще вопрос: А Async IO в линуксе по умолчанию включён ? вы по всей видимости не совсем понимаете значение этого термина. http://www.opennet.ru/opennews/art.shtml?num=3408 это лиши интерфейс для программиста. реализаций которого есть много... в линуксе доступен с 2.6, в 2.4 бекпортирован достаточно того, что в этом режиме qemu-kvm работает с io быстрей
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	12. "что быстрее(>iops) raw vs qcow2 vs block lvm dev для гостя kvm"	+/–
	Сообщение от netc (ok) on 16-Июн-11, 11:11
	>> и ТО(fs ext4/xfs) и без включенного кэша ? > не совсем понял вашего вопроса... > дело в том, что в режиме aio и без кеширования данные будут > писаться в обход fs. отсюда и глюки на некоторых ФС при > некоторых условиях Извиняюсь, за то что не ясно выразился! Т.е. если хочешь запускать qemu с aio=native при этом образ диска будет лежать на фс  ext4/xfs не отключай кэш? >> еще вопрос: А Async IO в линуксе по умолчанию включён ? > вы по всей видимости не совсем понимаете значение этого термина. http://www.opennet.ru/opennews/art.shtml?num=3408 Согласен! Я - не понимаю. Но оставим это уже для другой темы. Спасибо Вам и всем кто помогал разобраться.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	13. "что быстрее(>iops) raw vs qcow2 vs block lvm dev для гостя kvm"	+/–
	Сообщение от netc (ok) on 16-Июн-11, 11:16
	обидно только, что aio нельзя задать если используется libvirt пруфлинки: http://wiki.libvirt.org/page/Todo https://bugzilla.redhat.com/show_bug.cgi?id=576830 а я как раз использую именно его ;(
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема