[KVM@Ubuntu14.04] Trage Disk IOPS in de Guests

[tim427]

Sinds lange tijd draai ik naar al tevredenheid een KVM hypervisor op Ubunut Server 14.04 maar kom nu langzamerhand er achter dat de disk IOPS niet super zijn.

Voorheen nooit last van gehad omdat de VM's weinig met Read/Writes hebben, maar nu met een ownCloud installatie begin ik goed te merken dat de performance niet al te best is.

Hardware:
Supermicro X8ST3 (Virtualisatie aan)
Intel Xeon E5620 @ 2.40GHz (1x fysiek, 4 cores, hyperthreat, VT-x)
24GB (6x 4GB DIMM 1333 MHz)
2TB Mirror (SoftRAID, LVM, 2x WDC WD20EZRX-00D)

IOPS testje op de hypervisor:

tim@node01:~$ dd if=/dev/zero of=testfile bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 14.6403 s, 73.3 MB/s

Dit varieerd tussen de 70 en 75 MB/s (Zou volgens de specs 147 MB/s moeten zijn, volgens anderen: HDTune)


Disk specs van Guest:

<disk type='file' device='disk'>
  <driver name='qemu' type='raw'/>
  <source file='/var/lib/libvirt/images/web01.signal.blue.img'/>
  <target dev='vda' bus='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>

IOPS testje op een willekeurige Guest:

tim@web01:~$ dd if=/dev/zero of=testfile bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1,1 GB) copied, 96,2799 s, 11,2 MB/s

Het gekke is dat als ik daarna nog een keer deze test doe, ik veel hogere waardes krijg:

tim@web01:~$ dd if=/dev/zero of=testfile bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1,1 GB) copied, 13,6419 s, 78,7 MB/s

Aantal vraagjes:
-Is het normaal dat de Host op 50% van de snelheid zit tenopzichte van fabriekswaardes?
-Is het normaal dat de initiele test op alles Guests rond de 11 MB/s zitten en de volgende tests hoger uitpakken?
-Nog performance/tweak tips van anders KVM-ers?
-Zit te twijfelen om nog een apparte SAN te maken met iSCSI, zou dit performance technich veel verbetering kunnen geven (non blocking fs)?

[CAPSLOCK2000]

- 50% is te weinig, dat kan veel beter. Je verliest wel wat, maar niet zo veel.
- Een hogere performance bij de tweede keer kan worden veroorzaakt door thin-allocated disks. De eerste keer dat je zo'n stuk storage wil gebruiken kost dan meer tijd. Ook een versnipperde LVM kan daar voor zorgen.
- Persoonlijk geef ik liever een rauw LVM logical volume aan een VM dan dat ik met files werk. Dan laat je een hele abstractielaag weg.
- dd is niet erg geschikt voor benchmarks. Gebruik liever een gespecialiseerde tool als fai of bonnie++.
- Was de storage verder helemaal idle tijdens deze test? Als een ander proces ook af en toe IO wil doen kan dat grote invloed hebben. Zeker met WD-Green schijven, die zijn daar eigenlijk niet geschikt voor.

[Thralas]

Ik was ook in de verontderstelling dat lvm veel uitmaakte, heb het even getest (ext4-op-ext4-backed-raw-disk vs ext4-lvm), maar het performanceverschil is hier verwaarloosbaar (~2%, al loop ik tegen een SATA2-bottleneck aan). YMMV.

Iets anders, je <driver> specificeert geen cache of io settings:

code:

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

De qemu manual zegt er wel het een en ander over, maar volgens mij override libvirt de defaults. Met ps moet je de daadwerkelijk gebruikte opties wel kunnen achterhalen, en misschien kun je hier wat mee spelen?

[gekkie]

Dat in je bij een herhaalde test de waardes veel hoger zijn komt waarschijnlijk omdat je met raw files werkt en dus alles gecached wordt in de host.

Weet niet of je noatime en nodiratime of relatime aan hebt staan .. wil ook nog wel eens schelen (geen idee of dat eigenlijk tegenwoordig al standaard is geworden).

En als laatste zou je een andere I/O scheduler kunnen gebruiken in host en guest (ipv de standaard cfq).
Deadline voor de host en noop voor de guest zie ik regelmatig langskomen.

CAPSLOCK2000 schreef op maandag 22 december 2014 @ 18:57:
- dd is niet erg geschikt voor benchmarks. Gebruik liever een gespecialiseerde tool als fai of bonnie++.

fio ipv fai ?

Met je simpele dd kom ik onder xen uit op 128MB/s op de host tegen 100 MB/s in een guest, op een simpel 7200rpm diskje met LVM.

[ Voor 27% gewijzigd door gekkie op 22-12-2014 23:51 ]

[tim427]

Thanks voor de input.

Dat die HDD van de baremetal machine maar 50% is blijft gek.. Zijn inderdaad wel WD Green schijfjes, misschien niet ideaal, maar toch... (Server was eerst voor andere doeleinden ; ) Zou het heel veel zin hebben om de twee WD Greens te vervangen met WD Se's?

Deze regel:

code:

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

had ik inderdaad ook al op het interwebs gevonden, maar schijnt ook niet veel uit te maken. Binnenkort maar eens proberen

Heeft het heel veel zin om de storage op een aparte machine te draaien d.m.v. iSCSI? Performance technisch gezien? Hoe zit het dan met snapshots? Gaat dit op iSCSI niveau of werkt dit ook via libvirt?

[CAPSLOCK2000]

gekkie schreef op maandag 22 december 2014 @ 23:39:
fio ipv fai ?

Oeps, yup.

tim427 schreef op dinsdag 23 december 2014 @ 11:52:
Dat die HDD van de baremetal machine maar 50% is blijft gek.. Zijn inderdaad wel WD Green schijfjes, misschien niet ideaal, maar toch... (Server was eerst voor andere doeleinden ; ) Zou het heel veel zin hebben om de twee WD Greens te vervangen met WD Se's?

Het zal zeker beter worden al ben ik bang dat we het echte probleem over het hoofd zien.
Je suggereert dat VT-x aan staat. Staat VT-d ook aan?

Heeft het heel veel zin om de storage op een aparte machine te draaien d.m.v. iSCSI? Performance technisch gezien? Hoe zit het dan met snapshots? Gaat dit op iSCSI niveau of werkt dit ook via libvirt?

Ik denk niet dat iSCSI gaat helpen. Als je toevallig een iSCSI-NAS hebt staan zou het een aardig experiment kunnen zijn om te achterhalen waar het probleem zit, maar iSCSI is niet fundamenteel sneller dan lokale storage, in tegendeel.

[tim427]

De commando "kvm-ok" geeft aan dat alles compatibel is en werkt

iotop geeft ook geen mega IOPS processen aan... Blijft vreemd.