Невероятно низкая производительность диска KVM (файлы на диске qcow2 + virtio)

У меня серьезные проблемы с производительностью диска при настройке гостевой системы KVM. Используя простой ddтест, раздел на хосте, на котором находятся образы qcow2 (зеркальный массив RAID), записывает со скоростью более 120 МБ / с , а мой гость получает записи в диапазоне от 0,5 до 3 МБ / с .

• Гость настроен с парой процессоров и 4 Гб оперативной памяти и в настоящее время больше ничего не работает; это абсолютно минимальная установка на данный момент.
• Производительность проверяется с помощью time dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=16000.
• Гость настроен на использование virtio, но это не влияет на производительность.
• Разделы хоста выровнены по 4 КБ (и в любом случае производительность на хосте хорошая).
• Использование кэширования с обратной записью на дисках значительно увеличивает заявленную производительность, но я бы предпочел не использовать ее; даже без этого производительность должна быть намного лучше, чем эта.
• Хост и гость работают под управлением Ubuntu 12.04 LTS, которая поставляется с qemu-kvm 1.0 + noroms-0ubuntu13 и libvirt 0.9.8-2ubuntu17.1.
• На хосте включен планировщик ввода-вывода крайнего срока, а у гостя - noop.

Кажется, есть множество руководств по настройке производительности kvm, и я доберусь до конца, но в данный момент мне кажется, что я должен получить значительно лучшую производительность, поэтому кажется, что что-то уже очень неправильно.

Обновление 1

И вдруг, когда я возвращаюсь и проверяю сейчас, это 26,6 МБ / с; это больше похоже на то, что я ожидал w / qcrow2. Я оставлю этот вопрос на тот случай, если у кого-нибудь возникнут какие-либо идеи относительно возможной проблемы (и если она снова загадочным образом вернется).

Обновление 2

Я перестал беспокоиться о производительности qcow2 и просто переключился на LVM поверх RAID1 с необработанными образами, по-прежнему используя virtio, но установив cache = 'none' и io = 'native' на диске. Производительность записи теперь составляет ок. 135 МБ / с, используя тот же базовый тест, что и выше, так что, кажется, нет смысла выяснять, в чем проблема, когда ее можно так легко обойти полностью.

Ну да, файлы qcow2 не предназначены для невероятно быстрой работы. Вы получите гораздо больше удачи от необработанных разделов (или, предпочтительно, LV).

Как добиться максимальной производительности с QCOW2 :

qemu-img create -f qcow2 -o preallocation=metadata,compat=1.1,lazy_refcounts=on imageXYZ

По словам разработчиков qcow2, наиболее важным является предварительное распределение, которое дает хороший импульс. Теперь он почти на одном уровне с LVM ! Обратите внимание, что это обычно включено в современных (Fedora 25+) дистрибутивах Linux.

Также вы можете предоставить небезопасный кеш, если это не рабочий экземпляр (это опасно и не рекомендуется, только для тестирования):

<driver name='qemu' cache='unsafe' />

Некоторые пользователи сообщают, что в некоторых тестах эта конфигурация превосходит конфигурацию LVM / небезопасную.

Для всех этих параметров требуется последняя версия QEMU 1.5+ ! Опять же, у большинства современных дистрибутивов есть такие.

Я добился отличных результатов для изображения qcow2 с этой настройкой:

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

который отключает гостевые кэши и включает AIO (асинхронный ввод-вывод). Выполнение вашей ddкоманды дало мне 177 МБ / с на хосте и 155 МБ / с на госте. Образ помещается на тот же том LVM, где был проведен тест хоста.

Моя qemu-kvmверсия 1.0+noroms-0ubuntu14.8и ядро 3.2.0-41-genericсо стоковой Ubuntu 12.04.2 LTS.

Если вы запускаете vms одной командой, для аргументов вы можете использовать

kvm -drive file = / path_to.qcow2, если = virtio, cache = off <...>

Это дало мне от 3 МБ / с до 70 МБ / с

В старых версиях Qemu / KVM бэкэнд Qcow2 был очень медленным, если не был выделен заранее, особенно если он использовался без кеша обратной записи. Смотрите здесь для более подробной информации.

В более поздних версиях Qemu файлы Qcow2 работают намного быстрее, даже если не используется предварительное распределение (или предварительное распределение только для метаданных). Тем не менее, объемы LVM остаются быстрее.

Обратите внимание на режимы кэширования: предпочтительным режимом является кэш с обратной записью , если только не используется гостевой режим, в котором нет или отключена поддержка очистки / барьеров дискового кэша. На практике гостевые системы Win2000 + и любые варианты барьерного монтирования Linux EXT4, XFS или EXT3 + - это штраф. С другой стороны, cache = unsafe никогда не следует использовать на производственных машинах, поскольку сброс кеша не распространяется на хост-систему. Неожиданное отключение хоста может буквально уничтожить гостевую файловую систему.

Я испытал точно такую ​​же проблему. В виртуальной машине RHEL7 у меня есть целевое ПО LIO iSCSI, к которому подключаются другие машины. В качестве базового хранилища (хранилища) для моих iSCSI LUN я изначально использовал LVM, но затем переключился на основанные на файлах образы.

Короче говоря: когда резервное хранилище подключено к контроллеру хранения virtio_blk (vda, vdb и т. Д.) - производительность от клиента iSCSI, подключающегося к цели iSCSI, была в моей среде ~ 20 IOPS, с пропускной способностью (в зависимости от размера IO) ~ 2- 3 МиБ / с. Я изменил контроллер виртуального диска в виртуальной машине на SCSI, и я могу получить 1000+ IOPS и пропускную способность 100+ МБ / с от моих клиентов iSCSI.

<disk type='file' device='disk'>
   <driver name='qemu' type='qcow2' cache='none' io='native'/>
   <source file='/var/lib/libvirt/images/station1/station1-iscsi1-lun.img'/>
   <target dev='sda' bus='scsi'/>
   <address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>