KVM guest io намного медленнее, чем host io: это нормально?


13

У меня есть настройка хост-системы Qemu-KVM на CentOS 6.3. Четыре жестких диска SATA емкостью 1 ТБ, работающие в программном RAID10. Guest CentOS 6.3 установлен на отдельном LVM. Люди говорят, что они видят производительность гостя почти равную производительности хоста, но я этого не вижу. Мои тесты ввода / вывода показывают на 30-70% более медленную производительность на гостевой, чем на хост-системе. Я попытался изменить планировщик (установлен elevator=deadlineна хосте и elevator=noopна госте), установить blkio.weight1000 в cgroup, изменить io на virtio ... Но ни одно из этих изменений не дало мне существенных результатов. Это часть конфигурации гостевого .xml:

<disk type='file' device='disk'>
  <driver name='qemu' type='raw'/>
  <source file='/dev/vgkvmnode/lv2'/>
  <target dev='vda' bus='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</disk>

Вот мои тесты:

Хост-система:

тест на йозон

# iozone -a -i0 -i1 -i2 -s8G -r64k
                                                            random  random 
              KB  reclen   write rewrite    read    reread    read   write 
         8388608      64  189930  197436   266786   267254   28644   66642 

Тест чтения дд: один процесс, а затем четыре одновременных процесса

# dd if=/dev/vgkvmnode/lv2 of=/dev/null bs=1M count=1024 iflag=direct
1073741824 bytes (1.1 GB) copied, 4.23044 s, 254 MB/s

# dd if=/dev/vgkvmnode/lv2 of=/dev/null bs=1M count=1024 iflag=direct skip=1024 & dd if=/dev/vgkvmnode/lv2 of=/dev/null bs=1M count=1024 iflag=direct skip=2048 & dd if=/dev/vgkvmnode/lv2 of=/dev/null bs=1M count=1024 iflag=direct skip=3072 & dd if=/dev/vgkvmnode/lv2 of=/dev/null bs=1M count=1024 iflag=direct skip=4096
1073741824 bytes (1.1 GB) copied, 14.4528 s, 74.3 MB/s
1073741824 bytes (1.1 GB) copied, 14.562 s, 73.7 MB/s
1073741824 bytes (1.1 GB) copied, 14.6341 s, 73.4 MB/s
1073741824 bytes (1.1 GB) copied, 14.7006 s, 73.0 MB/s

тест записи dd: один процесс и затем четыре одновременных процесса

# dd if=/dev/zero of=test bs=1M count=1024 oflag=direct
1073741824 bytes (1.1 GB) copied, 6.2039 s, 173 MB/s

# dd if=/dev/zero of=test bs=1M count=1024 oflag=direct & dd if=/dev/zero of=test2 bs=1M count=1024 oflag=direct & dd if=/dev/zero of=test3 bs=1M count=1024 oflag=direct & dd if=/dev/zero of=test4 bs=1M count=1024 oflag=direct
1073741824 bytes (1.1 GB) copied, 32.7173 s, 32.8 MB/s
1073741824 bytes (1.1 GB) copied, 32.8868 s, 32.6 MB/s
1073741824 bytes (1.1 GB) copied, 32.9097 s, 32.6 MB/s
1073741824 bytes (1.1 GB) copied, 32.9688 s, 32.6 MB/s

Гостевая система:

тест на йозон

# iozone -a -i0 -i1 -i2 -s512M -r64k
                                                            random  random
              KB  reclen   write rewrite    read    reread    read   write
          524288      64   93374  154596   141193   149865   21394   46264 

Тест чтения дд: один процесс, а затем четыре одновременных процесса

# dd if=/dev/mapper/VolGroup-lv_home of=/dev/null bs=1M count=1024 iflag=direct skip=1024
1073741824 bytes (1.1 GB) copied, 5.04356 s, 213 MB/s

# dd if=/dev/mapper/VolGroup-lv_home of=/dev/null bs=1M count=1024 iflag=direct skip=1024 & dd if=/dev/mapper/VolGroup-lv_home of=/dev/null bs=1M count=1024 iflag=direct skip=2048 & dd if=/dev/mapper/VolGroup-lv_home of=/dev/null bs=1M count=1024 iflag=direct skip=3072 & dd if=/dev/mapper/VolGroup-lv_home of=/dev/null bs=1M count=1024 iflag=direct skip=4096
1073741824 bytes (1.1 GB) copied, 24.7348 s, 43.4 MB/s
1073741824 bytes (1.1 GB) copied, 24.7378 s, 43.4 MB/s
1073741824 bytes (1.1 GB) copied, 24.7408 s, 43.4 MB/s
1073741824 bytes (1.1 GB) copied, 24.744 s, 43.4 MB/s

тест записи dd: один процесс и затем четыре одновременных процесса

# dd if=/dev/zero of=test bs=1M count=1024 oflag=direct
1073741824 bytes (1.1 GB) copied, 10.415 s, 103 MB/s

# dd if=/dev/zero of=test bs=1M count=1024 oflag=direct & dd if=/dev/zero of=test2 bs=1M count=1024 oflag=direct & dd if=/dev/zero of=test3 bs=1M count=1024 oflag=direct & dd if=/dev/zero of=test4 bs=1M count=1024 oflag=direct
1073741824 bytes (1.1 GB) copied, 49.8874 s, 21.5 MB/s
1073741824 bytes (1.1 GB) copied, 49.8608 s, 21.5 MB/s
1073741824 bytes (1.1 GB) copied, 49.8693 s, 21.5 MB/s
1073741824 bytes (1.1 GB) copied, 49.9427 s, 21.5 MB/s

Интересно, это нормальная ситуация или я что-то пропустил?


Вы сказали, что изменили своего гостя на использование шины virtio, которая обеспечивает лучшую производительность, но для этого должны быть установлены драйверы virtio. Вы не сказали бы, используете ли вы их или нет. Я не знаю CentOS достаточно подробно, чтобы прокомментировать, будут ли эти драйверы присутствовать в вашем госте по умолчанию или нет.
Jwbensley

1
@javano CentOS всегда включает virtio, и вам придется явно удалить его, перекомпилировав пакеты ядра.
Майкл Хэмптон

Всегда удобно знать, ура :)
jwbensley

Ответы:


22

Вы еще не закончили настройку производительности.

  <driver name='qemu' type='raw' cache='writethrough' io='native'/>

Во-первых, какой механизм ввода / вывода использовать.

В QEMU есть два механизма асинхронного ввода-вывода: эмуляция POSIX AIO с использованием пула рабочих потоков и собственный Linux AIO.

Установите io='native'или io='threads'в своем XML для сравнения каждого из них.

Во-вторых, какой механизм кэширования использовать. Вы можете установить cache='writeback', cache='writethrough'или вы можете отключить его cache='none', который вы можете найти лучше всего работает.

Если вы используете необработанные тома или разделы, лучше всего полностью избегать кэширования, что уменьшает объем копий данных и трафик шины.

Не используйте, writebackесли ваш массив RAID не работает от батареи, или вы рискуете потерять данные. (Конечно, если потеря данных в порядке, не стесняйтесь.)

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

Наконец, сделайте небольшое исследование. IBM сделала очень интересную презентацию о производительности ввода-вывода KVM на конференции Linux Plumber 2010 года. Кроме того, у них есть обширный набор лучших практик по использованию KVM, которые, безусловно, будут интересны.

PS Длинные последовательные чтения и записи редко представляют реальную рабочую нагрузку. Попробуйте выполнить эталонные тесты с другими типами рабочих нагрузок, в идеале с реальными приложениями, которые вы собираетесь запускать в работе.


+1 за «тест с вашим шаблоном ввода-вывода»
Хавьер

О, хорошие лайки к документам IBM, +1 :)
jwbensley

1
Очень полезно, спасибо! Теперь я улучшил свои гостевые результаты до 90% от производительности хоста. Моя ошибка была довольно глупой: я virsh reset <domain>не применил мои virsh edit <domain>изменения, и я полагал, что гость использовал virtio, но на самом деле это не так. Только virsh destroy <domain>следом virsh start <domain>помог. Виртио правит! ;)
Evolver

1
cache = writeback не добавляет никаких реальных рисков (важные данные не находятся в опасности, только данные в полете, которые в любом случае сбрасываются при сбое). Только кеш = небезопасно. Обратная запись не подразумевает дополнительных аппаратных требований («RAID-массив с батарейным питанием» никак не помогает). Он имеет тот же уровень целостности, что и кэш записи жесткого диска: оба сбрасываются при необходимости операционной системой.
korkman

io='native'дал почти 20-30% дополнительной производительности WRITE в моем случае
rahul286
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.