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

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

• Гість налаштований на пару процесорів і 4G оперативної пам’яті і наразі не працює нічим іншим; це абсолютно мінімальна установка на даний момент.
• Продуктивність перевіряється за допомогою 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, але встановивши кеш = 'none' та io = 'native' на дисководі. Виконання запису тепер є додатком. 135 Мб / с, використовуючи той самий базовий тест, що і вище, тому, здається, немає особливого сенсу з'ясовувати, в чому проблема, коли її можна так легко вирішити цілком.

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

Як досягти найкращих показників за допомогою QCOW2 :

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

Найважливішим з них є попереднє розміщення, яке дає приємний стимул, на думку розробників qcow2. Зараз це майже нарівні з LVM ! Зауважте, що це зазвичай увімкнено у сучасних дистрибутивах Linux (Fedora 25+).

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

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

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

Для всіх цих параметрів потрібна остання версія QEMU 1.5+ ! Знову ж таки, більшість сучасних дистрибутивів мають це.

Я домігся чудових результатів для зображення qcow2 за допомогою цього параметра:

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

який відключає кеш-адрес гостя та вмикає AIO (Asynchronous IO). Виконання вашої 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, if = virtio, cache = off <...>

Це отримало мене від 3 Мб / с до 70 МБ / с

У старих версіях Qemu / KVM бекенд Qcow2 був дуже повільним, коли він не був попередньо розміщений, тим більше, якщо він використовувався без включеного кешу зворотного запису. Дивіться тут для отримання додаткової інформації.

У останніх версіях Qemu файли Qcow2 набагато швидше, навіть якщо не використовується попереднє розміщення (або лише метадані). Однак обсяги LVM залишаються швидшими.

Зауваження про режими кешу: зворотна запис кеш є кращим способом, якщо не використовуючи гість без або з обмеженою можливостями підтримки кешу диска змиву / бар'єри. На практиці Win2000 + гості та будь-які параметри кріплення бар'єру Linux EXT4, XFS або EXT3 + - це штрафи. З іншого боку, кеш = небезпечний ніколи не повинен використовуватися у виробничих машинах, оскільки промивання кеш-пам’яті не розповсюджується на хост-систему. Несподіване відключення хоста може буквально знищити файлову систему гостя.

У мене виникло саме таке питання. У віртуальній машині RHEL7 у мене є цільове програмне забезпечення LIO iSCSI, до якого підключаються інші машини. Як базове сховище (backstore) для своїх iSCSI LUN я спочатку використовував LVM, але потім перейшов до файлів на основі зображень.

Довга історія: коли резервне зберігання додається до контролера зберігання virtio_blk (vda, vdb тощо) - продуктивність від клієнта iSCSI, який підключається до цілі iSCSI, була в моєму середовищі ~ 20 IOPS, з пропускною здатністю (залежно від розміру IO) ~ 2- 3 МіБ / с. Я змінив контролер віртуального диска у віртуальній машині на SCSI і я можу отримати 1000+ IOPS та пропускну здатність 100+ MiB / s від своїх клієнтів 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>