Назад | Перейти на главную страницу

kvm низкая производительность io

производительность моей установки довольно хороша (geekbench, как он «ощущается», ...) даже пропускная способность диска (libvirt на необработанном lvm-разделе) очень близка к необработанной производительности на сервере) но IOP / s составляет всего 100-200 гостевых серверов (по сравнению с ~ 1000 хостов) как на Linux, так и на гостевых компьютерах Windows.
Это вещь, с которой нужно жить (kvm просто не может сделать это лучше) или я делаю что-то совершенно не так?

Интересно то, что я смог повлиять на пропускную способность, изменив настройку (qcow2 vs raw-image vs raw-partition) или конфигурацию (кеширование или io-scheduling) и варианты, но IOP оставались на той же самой низкой точке по всем этим комбинации.

оборудование #

• supermicro dual xeon E5520 с 24 ГБ оперативной памяти
• 2x seagate constellation 1 ТБ (RAID1 на Adaptec 3405)
• 2x seagate cheetah (RAID1 на Adaptec 6405).

программное обеспечение

• ubuntu 11.10 3.0.0-13-сервер
• эмулятор kvm / QEMU версии 0.14.1 (qemu-kvm-0.14.1)
• тестирование дисков (bonnie ++, hdparm) от хостов и гостей (bonnie ++, hdparm, hdtune на windows)

config

Я протестировал несколько конфигураций дисков, текущая настройка:

хосты linux

(Им просто "не нужна" высокая производительность ввода-вывода, поэтому я сохраняю более удобные дисковые файлы)
• файлы диска qcow2 на lvm по моим созвездиям
• qemu / ide

<disk type='file' device='disk'>
  <driver name='qemu' type='qcow2'/>
  <source file='/media/vm/images/mex/mex_root.qcow2'/>
  <target dev='hda' bus='ide'/>
  <address type='drive' controller='0' bus='0' unit='0'/>
</disk>

хосты Windows ###

(Запуск SQL-Server и Remote-Desktop-Services, поэтому здесь мне определенно нужна хорошая производительность ввода-вывода)
• сырые перегородки lvm на моих гепардах
• virtio

<emulator>/usr/bin/kvm</emulator>
<disk type='block' device='disk'>
  <driver name='qemu' type='raw' cache='none'/>
  <source dev='/dev/Cheetah/mts'/>
  <target dev='vda' bus='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
</disk>

Оптимальная конфигурация (обычно) следующая:

  1. На хосте установите elevator=deadline
  2. Используйте virtio и только virtio
  3. по возможности используйте необработанные LV. Qcow2 дает накладные расходы. Файлы на FS также имеют накладные расходы
  4. в виртуальной машине используйте elevator=noop
  5. как на хосте, так и на виртуальной машине используйте noatime,nodiratime в fstab везде, где возможно
  6. Убедитесь, что драйверы virtio обновлены, особенно для Windows.
  7. Дистрибутивы на основе Debian (возможно) не так хороши, как Fedora и RHEL для QEMU / KVM. Не хочу начинать войну, но большая часть разработки и тестирования выполняется в Fedora и RHEL, и по моему собственному опыту, в Ubuntu и Debian было много проблем, которые я не мог воспроизвести в Fedora и RHEL. Вы можете игнорировать этот конкретный пункт, если хотите, но если вы ищете решение, обычно стоит попробовать быстрый тест на другом дистрибутиве.

Попробуйте установить крайний срок в качестве планировщика ввода-вывода для вашего хозяин диски перед запуском KVM:

 for f in /sys/block/sd*/queue/scheduler; do echo "deadline" > $f; done

Если у вас есть ограниченная нагрузка ввода-вывода, это может быть вашим лучшим выбором в качестве этот документ IBM предлагает.