LINUX.ORG.RU
решено ФорумAdmin

Низкая скорость дисковых операций гостя kvm

 ,


0

2

Имеется гента с app-emulation/qemu-1.1.2-r2. Гость win2k3x64. Диск гостя

    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='writeback' io='native'/>
      <source file='/home/virtman/images/2k3x64.img'/>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>

# qemu-img info /home/virtman/images/2k3x64.img
image: /home/virtman/images/2k3x64.img
file format: qcow2
virtual size: 250G (268435456000 bytes)
disk size: 24G
cluster_size: 65536
Производительность дисков хоста
# hdparm -tT /dev/sda2 

/dev/sda2:
 Timing cached reads:   22734 MB in  2.00 seconds = 11379.76 MB/sec
 Timing buffered disk reads: 770 MB in  3.00 seconds = 256.36 MB/sec
В госте копирование 200Mb файла занимает около 15-ти минут. Т.е. раз в 500 медленнее, чем умеет хост... Загрузка на хосте при копировании примерно такая
%Cpu(s):  0.8 us,  1.4 sy,  0.0 ni, 91.5 id,  6.3 wa,  0.0 hi,  0.0 si,  0.0 st
С чем такая печаль может быть связана? Где и как искать затык?

покажите `mount | grep home`

ну и традиционно уже - попробуйте на Федоре (и более современной гостевой ОС тоже не помешало бы)

dyasny ★★★★★ ()
Ответ на: комментарий от dyasny
/dev/sda2 on /home type reiserfs (rw,noexec,nosuid,nodev)

Менять хост-генту на федору нет возможности. linux-гостя щаз поставлю.
По ходу разбирательств возник вопрос - можно-ли (и как) уже созданный и набитый инфой qcow2 образ, сделать preallocated? Он изначально был создан динамически растущим и есть подозрение, что он по мере роста так лажает.

NightSpamer ()
Ответ на: комментарий от NightSpamer

да, это одно из подозрений. при росте, qcow2 увеличивается на 4k, что может оказаться совсем мало - отсюда и тормоза. Можно или сконвертировать его в raw через qemu-img, или просто забить его нулями, внутри гостевой ОС

mount options для репозитория имиджей ВМ обычно оптимизируют. Как минимум noatime, nodiratime

и еще, поменяйте cache на none

dyasny ★★★★★ ()
Ответ на: комментарий от dyasny

Как минимум noatime, nodiratime

там не только образы VM. Так бы я ещё notail добавил.

поменяйте cache на none

Ради теста поменяю, конечно. Но в интернетах всё указывает на то, что writeback, как минимум, не медленнее, чем всё остальное.
Результаты по линукс-гостю подоспели:

dd if=/dev/zero of=test bs=4k count=1M
1048576+0 записей получено
1048576+0 записей отправлено
 скопировано 4294967296 байт (4,3 GB), 113,501 c, 37,8 MB/c
Кроме «тваюмать» ничего в голову не приходит. Не люблю с виндосами ковыряться.

NightSpamer ()
Ответ на: комментарий от NightSpamer

Даже если неправильно сделаешь - все равно будет быстрее, чем qcow2 :)
Хотя что там можно сделать неправильно, даже не знаю. Разве что, накосячить с alignment'ом разделов, если HDD с Advanced Format'ом (аппаратный 4К сектор).

pekmop1024 ★★★★★ ()
Ответ на: комментарий от dyasny

Можно или сконвертировать его в raw через qemu-img

Всмысле qcow2 -> raw -> qcow2 ? Мне-бы оставить возможность делать снапшоты, а в raw они, AFAIK, не поддерживаются.
Или снапшоты - не тру и бэкапы делать надо тупым копированием образа при выключенном госте? Как оно правильней?

NightSpamer ()
Ответ на: комментарий от pekmop1024

аппаратный 4К сектор

Не. Аппаратный raid с

Array stripe size in number of blocks : 64
Array sector size : 512

NightSpamer ()
Ответ на: комментарий от tazhate

Да, рейзер. После того, как на ext3 кончились иноды при 40+% свободного места. (Вот я тогда знатно затупил глядя на это.) Может, и не лучший выбор, конечно.

NightSpamer ()
Ответ на: комментарий от pekmop1024

прямой блочный доступ конечно немного быстрее, но qcow2 с современным qemu работает почти так же как raw

dyasny ★★★★★ ()
Ответ на: комментарий от NightSpamer

стоп, там еще и снепшоты есть? тогда точно будут тормоза, COW как алгоритм не оптимален, поэтому на нем тормозит у всех.

я имел ввиду один плоский имидж, без снимков

dyasny ★★★★★ ()
Ответ на: комментарий от NightSpamer

ну, с таким раскладом даже не знаю, вряд ли кто либо это проверял вообще когда либо

сделайте LVM, и избавьтесь от снимков для начала

dyasny ★★★★★ ()
Ответ на: комментарий от true_admin

да, в случае сбоев на сервере с cache=... образ может серьёзно покорёжиться.

true_admin ★★★★★ ()
Ответ на: комментарий от dyasny

Кстати, о прямом доступен на LVM.
У меня на нем с aio=native больше IOPS'ов, а с aio=threads - больше линейная скорость чтения... оба случая замерялись с cache=none.

pekmop1024 ★★★★★ ()
Ответ на: комментарий от true_admin

Было-же указано
<driver name='qemu' type='qcow2' cache='writeback' io='native'/>
Снапшоты были, но были удалены. Тормоза начались уже после удаления.
Конверчу в raw.

NightSpamer ()
Ответ на: комментарий от dyasny

сконвертировать его в raw через qemu-img

Оно! По ощущениям, стало даже быстрее, чем на хосте. Видать, кэширование сказывается.

NightSpamer ()
Ответ на: комментарий от pekmop1024

интересно, у меня немного другие показатели. Правда я пользуюсь стабильным RHEL, и железом которое не является узким местом (недавно одна ВМ показала 1.6 миллион iops)

dyasny ★★★★★ ()
Ответ на: комментарий от dyasny

Отключил. Странно, но разницы при переходе writeback->none не заметил. Хотя и не искал особо.

NightSpamer ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.