Kinerja disk KVM yang sangat rendah (file disk qcow2 + virtio)

Saya mengalami beberapa masalah kinerja disk yang serius saat mengatur tamu KVM. Menggunakan ddtes sederhana , partisi pada host tempat gambar qcow2 berada (array RAID cermin) menulis di lebih dari 120MB / s , sementara tamu saya mendapatkan menulis mulai dari 0,5 hingga 3MB / s .

• Tamu dikonfigurasi dengan beberapa CPU dan 4G RAM dan saat ini tidak menjalankan hal lain; ini adalah instalasi yang sangat minim saat ini.
• Kinerja diuji menggunakan time dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=16000.
• Tamu dikonfigurasikan untuk menggunakan virtio, tetapi ini tampaknya tidak membuat perbedaan untuk kinerja.
• Partisi tuan rumah sejajar 4kb (dan kinerja baik-baik saja pada tuan rumah).
• Menggunakan caching penulisan balik pada disk meningkatkan kinerja yang dilaporkan secara masif, tapi saya lebih suka tidak menggunakannya; bahkan tanpa itu kinerja harus jauh lebih baik dari ini.
• Host dan guest menjalankan Ubuntu 12.04 LTS, yang hadir dengan qemu-kvm 1.0 + noroms-0ubuntu13 dan libvirt 0.9.8-2ubuntu17.1.
• Host memiliki batas waktu IO scheduler diaktifkan dan tamu tidak memiliki noop.

Tampaknya ada banyak panduan di luar sana mengutak-atik kinerja kvm, dan saya akan sampai di sana pada akhirnya, tetapi sepertinya saya harus mendapatkan kinerja yang jauh lebih baik daripada ini pada saat ini sehingga sepertinya ada sesuatu yang sudah sangat salah.

Perbarui 1

Dan tiba-tiba ketika saya kembali dan menguji sekarang, itu 26,6 MB / s; ini lebih seperti apa yang saya harapkan w / qcrow2. Saya akan meninggalkan pertanyaan kalau-kalau ada yang punya ide tentang apa yang mungkin menjadi masalah (dan jika kembali secara misterius).

Perbarui 2

Saya berhenti khawatir tentang kinerja qcow2 dan hanya memotong ke LVM di atas RAID1 dengan gambar mentah, masih menggunakan virtio tetapi pengaturan cache = 'tidak ada' dan io = 'asli' pada disk drive. Kinerja menulis sekarang appx. 135MB / s menggunakan tes dasar yang sama seperti di atas, jadi sepertinya tidak ada banyak gunanya untuk mencari tahu apa masalahnya ketika itu dapat dengan mudah diselesaikan sepenuhnya.

Ya, file qcow2 tidak dirancang untuk kinerja yang sangat cepat. Anda akan mendapatkan keberuntungan yang lebih baik dari partisi mentah (atau, lebih disukai, LV).

Cara mencapai kinerja puncak dengan QCOW2 :

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

Yang paling penting adalah pra-alokasi yang memberikan dorongan yang bagus, menurut pengembang qcow2. Hampir setara dengan LVM sekarang! Perhatikan bahwa ini biasanya diaktifkan di distro Linux modern (Fedora 25+).

Anda juga dapat memberikan cache yang tidak aman jika ini bukan contoh produksi (ini berbahaya dan tidak disarankan, hanya baik untuk pengujian):

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

Beberapa pengguna melaporkan bahwa konfigurasi ini mengalahkan konfigurasi LVM / tidak aman dalam beberapa pengujian.

Untuk semua parameter ini, QEMU 1.5+ terbaru diperlukan! Sekali lagi, sebagian besar distro modern memilikinya.

Saya mencapai hasil yang bagus untuk gambar qcow2 dengan pengaturan ini:

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

yang menonaktifkan cache tamu dan mengaktifkan AIO (Asynchronous IO). Menjalankan ddperintah Anda memberi saya 177MB / s pada host dan 155MB / s pada tamu. Gambar ditempatkan pada volume LVM yang sama di mana tes host dilakukan.

qemu-kvmVersi saya adalah 1.0+noroms-0ubuntu14.8dan kernel 3.2.0-41-genericdari stok Ubuntu 12.04.2 LTS.

Jika Anda menjalankan vms Anda dengan satu perintah, untuk argumen yang dapat Anda gunakan

kvm -drive file = / path_to.qcow2, if = virtio, cache = off <...>

Itu membuat saya dari 3MB / s ke 70MB / s

Pada versi Qemu / KVM lama, backend Qcow2 sangat lambat saat tidak dialokasikan, lebih dari itu jika digunakan tanpa cache writeback diaktifkan. Lihat di sini untuk informasi lebih lanjut.

Pada versi Qemu yang lebih baru, file Qcow2 jauh lebih cepat, bahkan ketika tidak menggunakan pra-alokasi (atau pra-alokasi hanya metadata). Namun, volume LVM tetap lebih cepat.

Catatan tentang mode cache: cache writeback adalah mode yang lebih disukai, kecuali jika menggunakan tamu tanpa dukungan yang dinonaktifkan untuk hambatan flush / hambatan cache disk. Dalam praktiknya, tamu Win2000 + dan opsi pemasangan penghalang Linux EXT4, XFS atau EXT3 + adalah denda. Di sisi lain, cache = tidak aman tidak boleh digunakan oleh mesin produksi, karena cache flush tidak disebarkan ke sistem host. Shutdown host yang tidak terduga dapat menghancurkan sistem file tamu

Saya mengalami masalah yang persis sama. Di dalam mesin virtual RHEL7 saya memiliki perangkat lunak target LIO iSCSI yang terhubung dengan mesin lain. Sebagai penyimpanan dasar (backstore) untuk LUNs iSCSI saya, saya awalnya menggunakan LVM, tetapi kemudian beralih ke file gambar berbasis.

Singkatnya: ketika penyimpanan dukungan dilampirkan ke virtio_blk (vda, vdb, dll.) Pengontrol penyimpanan - kinerja dari klien iSCSI yang terhubung ke target iSCSI ada di lingkungan saya ~ 20 IOPS, dengan throughput (tergantung pada ukuran IO) ~ 2- 3 MiB / s. Saya mengubah pengontrol disk virtual dalam mesin virtual ke SCSI dan saya bisa mendapatkan 1000+ IOPS dan throughput 100+ MiB / s dari klien iSCSI saya.

<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>