İnanılmaz derecede düşük KVM disk performansı (qcow2 disk dosyaları + virtio)


27

KVM konuğu kurarken bazı ciddi disk performans sorunları yaşıyorum. Basit kullanarak ddtesti, qcow2 görüntüleri (yansıtılmış RAID dizisinde) ikamet bu ana bilgisayarda bölüm boyunca en yazar 120MB / s misafirim arasında değişen yazma alırken, 0.5 3MB / s .

  • Konuk birkaç CPU ve 4G RAM ile yapılandırılmış ve şu anda başka bir şey çalıştırmıyor; şu anda tamamen minimal bir kurulum.
  • Performans kullanılarak test edilmiştir time dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=16000.
  • Konuk virtio kullanacak şekilde yapılandırılmış, ancak bu performansta bir fark yaratmıyor gibi görünüyor.
  • Ana bilgisayar bölümleri 4 kb boyutundadır (ve yine de ana bilgisayarda performans iyidir).
  • Disklerde geri yazma önbelleği kullanmak rapor edilen performansı büyük ölçüde artırır, ancak kullanmamayı tercih ederim; Bu olmadan bile performans bundan daha iyi olmalı.
  • Ev sahibi ve misafir hem qemu-kvm 1.0 + noroms-0ubuntu13 hem de 0.9.8-2ubuntu17.1 libvirt ile gelen Ubuntu 12.04 LTS'yi çalıştırıyor.
  • Ana bilgisayar son tarihi IO zamanlayıcısını etkinleştirdi ve konukta noop var.

Kvm performansında ince ayar yapan pek çok rehber var gibi görünüyor ve sonunda oraya gideceğim, ama sanırım bu noktada çok daha iyi bir performans elde etmem gerekiyor gibi görünüyor, bu yüzden bir şey zaten çok yanlış gibi görünüyor.

Güncelleme 1

Ve şimdi geri dönüp test ettiğimde aniden 26.6 MB / s; Bu beklediğim gibi daha fazla w / qcrow2. Sorunun ne olabileceğine dair herhangi bir fikriniz varsa (ve gizemli bir şekilde tekrar gelmesi durumunda) soruyu bırakacağım.

Güncelleme 2

Qcow2 performansı hakkında endişelenmeyi bıraktım ve RAID1'in üstündeki LVM'yi kesmeye başladım, yine de virtio kullanarak ancak disk sürücüsünde cache = 'none' ve io = 'native' ayarını yaptım. Yazma performansı şimdi ek. 135MB / sn yukarıdaki ile aynı temel testi kullanıyor, bu yüzden sorunun tamamen kolayca çözülebildiği zaman problemin ne olduğunu bulmakta pek bir nokta yok gibi görünmüyor.


Kullanılan dağıtım ve yazılım sürümlerinden bahsetmediniz.
dyasny

Sürümlerle ilgili bazı bilgiler eklendi.
El Yobo

ah, beklendiği gibi, ubuntu ... bunu fedorada çoğaltabilme ihtimalin var mı?
dyasny

Sunucu Almanya'da ve şu anda Meksika'dayım, bu yüzden biraz zor olabilir. Birdenbire işe yaradıysa ... Hala bir Fedora sunucusuyla uğraşmak istemem;) Debian / Ubuntu sistemlerinin KVM için Fedora / CentOS'tan daha çok sorunu olduğunu öne süren birkaç yorum gördüm. geliştirme çalışmaları orada yapıldı.
El Yobo

tam olarak benim açımdan. ve her durumda, eğer bir sunucu sınıfı işletim sisteminden sonra iseniz,
RHEL'e

Yanıtlar:


14

Evet, qcow2 dosyaları cayır cayır yanan hızlı performans için tasarlanmamıştır. Ham bölmelerden (veya tercihen LV'lerden) daha iyi şanslar elde edersiniz.


3
Açıkçası, ama onlar da aldığım numaralar kadar saçma değil.
El Yobo

1
Örneklerin çoğu, qcow2 ile benzer performansı göstermektedir ki bu, eski sürüme göre önemli bir gelişme gibi görünmektedir. KVM sitesinin kendisi, bir dizi durum için karşılaştırılabilir zamanlar gösteren linux-kvm.org/page/Qcow2 adresinde sayıları buldu .
El Yobo,

1
18:35 (qcow2) vs 8:48 (işlenmemiş) "karşılaştırılabilir zamanlar" mı?
womble

1
Onları LVM destekli ham görüntülere RAID1'in üstüne koydum, io zamanlayıcısını konukta noop ve ana bilgisayardaki son tarihe ayarladım ve şimdi 138 MB / s. Qcow2'nin 3 MB / s hıza sahip olmasına neyin neden olduğunu hala bilmiyorum, ama açıkça ham kullanarak kaldırılabilir, bu yüzden beni o yöne ittiğiniz için teşekkürler.
El Yobo,

1
Bu tam olarak doğru değil - qemu'daki en son yamalar qcow2'yi çok hızlandırıyor! Neredeyse eşitiz.
20'de

7

QCOW2 ile en iyi performans nasıl elde edilir :

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

En önemlisi, qcow2 geliştiricilere göre, iyi bir destek veren ön dağıtımdır. Artık LVM ile neredeyse aynı ! Bunun genellikle modern (Fedora 25+) Linux dağıtımlarında etkin olduğunu unutmayın.

Ayrıca eğer bu bir üretim örneği değilse güvenli olmayan önbellek sağlayabilirsiniz (bu tehlikeli ve tavsiye edilmez, sadece test için iyidir):

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

Bazı kullanıcılar bu yapılandırmanın bazı testlerde LVM / güvenli olmayan yapılandırmayı geçtiğini bildiriyor.

Tüm bu parametreler için en son QEMU 1.5+ gereklidir! Yine, modern dağıtımların çoğunda bunlar var.


2
Öyle değil kullanım cache = güvensiz için iyi bir fikir: beklenmedik konak kapatma büyük hasara yol açabilir , tüm konuk dosya sistemi. Öyle çok benzer performans, ancak çok daha iyi güvenilirlik: kullanım cache = geri yazma daha iyi.
shodanshok

1
Söylediğim gibi: eğer bu üretim örneği değilse (test için iyi)
saat

Yeterince adil. Ben özledim;)
shodanshok

6

Bu ayar ile qcow2 görüntüsü için harika sonuçlar elde ettim:

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

Bu, konuk önbelleklerini devre dışı bırakır ve AIO'yu (Asenkron IO) etkinleştirir. ddKomutunuzu çalıştırmak bana ana makinede 177 MB / s, konuğa 155 MB / s verdi. Görüntü, ana bilgisayar testinin yapıldığı LVM birimine yerleştirilir.

Benim sürümüm qemu-kvm, 1.0+noroms-0ubuntu14.8çekirdeği 3.2.0-41-genericUbuntu 12.04.2 LTS.


5
Bir qcow2 görüntü türünü "raw" olarak mı ayarladınız?
Alex,

Sanırım eski girişi kopyaladım, hız avantajlarının aynı olması gerektiğini düşünüyorum type='qcow2', düzenlemeden önce kontrol edebilir misiniz? Bu tür bir yapılandırmaya daha fazla erişimim yok mount bind- Konuklarda gerçek yerel hızları elde etmek için dizinlerle LXC'ye geçtim .
gertas,

2

Vms'nizi tek bir komutla çalıştırıyorsanız, kullanabileceğiniz değişkenler için

kvm -drive dosyası = / path_to.qcow2, eğer = virtio, önbellek = kapalı <...>

Beni 3 MB / sn'den 70 MB / sn'ye yükseltti


2

Eski Qemu / KVM sürümlerinde, Qcow2 arka uç önceden dağıtılmadığında çok yavaştı, daha doğrusu geri yazma önbelleği etkin olmadan kullanılırsa. Daha fazla bilgi için buraya bakınız.

Daha yeni Qemu sürümlerinde, Qcow2 dosyaları önceden tahsisat kullanılmamasına rağmen (ya da yalnızca meta veri ön yüklemesi kullanıldığında), çok daha hızlıdır. Yine de, LVM hacimleri daha hızlı kalır.

Önbellek modlarına ilişkin bir not: geri yazma önbelleği, disk önbelleği temizleme / engelleri için desteği olmayan veya devre dışı desteği olan bir konuk kullanmıyorsa, tercih edilen moddur. Uygulamada Win2000 + misafirleri ve Linux EXT4, XFS veya EXT3 + bariyer montaj seçenekleri para cezasıdır. Öte yandan, önbellek temizleme işlemleri ana sisteme yayılmadığından , önbellek = güvensiz üretim makinelerinde asla kullanılmamalıdır. Beklenmeyen bir ana bilgisayar kapatma, tam anlamıyla konukların dosya sistemini imha edebilir.


2

Ben de aynı sorunu yaşadım. RHEL7 sanal makinesinde, diğer makinelerin bağlandığı LIO iSCSI hedef yazılımına sahibim. İSCSI LUN'larım için temel depolama (arka mağaza) olarak başlangıçta LVM kullandım ancak dosya tabanlı görüntülere geçtim.

Uzun lafın kısası: yedek depolama virtio_blk (vda, vdb, vb.) Bağlıyken depolama denetleyicisi - iSCSI hedefine bağlanan iSCSI istemcisinin performansı benim ortamımdaydı ~ 20 IOPS, verim ile (IO boyutuna bağlı olarak) ~ 2- 3 MiB / s. Sanal makinedeki sanal disk denetleyicisini SCSI olarak değiştirdim ve iSCSI istemcilerimden 1000+ IOPS ve 100 + MiB / s veri alabiliyorum.

<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>
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.