Onderwerp: Beroerde disk I/O binnen KVM quests (virtio)

Ik zit al een tijdje te "knutselen" met een disk I/O probleem binnen KVM guests. Nog altijd geen oplossing voor gevonden, wellicht dat er hier meer mensen zijn met een vergelijkbaar probleem.
Probleem is dat de disk I/O binnen guest VM's enorm beroerd is. Zelfs zo erg dat de installatie op een USB stick van 3 euro vast en zeker sneller zal gaan

Specs van mijn huidige knutsel/dev bak op kantoor:
Supermicro X9SCM-F (C204 chipset)
Intel E3-1240v2
32GB DDR3-ECC
4x Seagate 2TB 7200rpm SATA-600 disks (op SATA-300 poorten)
Host OS: CentOS 6.3 x64 inclusief alle updates
KVM: Standaard qemu-kvm uit de CentOS repo (0.12.1.x meen ik)

Systeem draait op een software RAID-10 config.
Op de host geen problemen met disk I/O. Rebuilden van de array gaat met bijna 400MB/s, en een simpele DD write test doet makkelijk 200MB/s+.
Zowel read als write geen enkel probleem, kort maar krachtig "lightning fast".
Middels SolusVM een KVM VM aangemaakt, en een ISO gemount. In dit geval Ubuntu 12.10, maar maakt weinig uit - probleem doet zich met elk OS voor.
Tijdens de installatie gaat alles, op de disk I/O na super snel - zodra het system gaat partitioneren en de eerste systeem files begint te kopieren blijft er niets over kwa performance.
Een minimal Ubuntu Server 12.10 x64 installatie duurt 1 a 2 uur - gewoon te gek voor woorden.

Wanneer ik op de host de stats van de LVM volumes bekijk, zie ik dat de LVM van de betreffende VM continu 100% load heeft. Gek genoeg 100% load met praktisch geen disk I/O (30 tot 80 writes/sec, 2.6MB/s).
Na de installatie is het systeem redelijk bruikbaar, met een simpele "apt-get upgrade" is het systeem zo 45 minuten bezig. Een simpele kernel update heeft 35 tot 45 minuten nodig - puur omdat er nauwelijks disk I/O is.

Je zou zeggen... KVM en slechte disk I/O, dat zal de IDE driver wel zijn..... in mijn geval betreft het baggere performance icm de Virtio disk driver.
Probleem is niet hardware specifiek - op andere hardware exact dezelfde problemen.

Als vergelijking heb ik op bovenstaande hardware een test gedaan met CentOS 6.3 + Xen 4.2.0. Resultaat is duidelijk merkbaar - een smooth OS! Op de LVM van de betreffende VM zonder problemen 25 tot 30x meer writes/sec.

Code:

KVM 0.12.x (standaard CentOS repo) + virtio disk driver:
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     0.00    0.00   68.00     0.00  1352.50    39.78     0.55    8.68   8.04  54.70
sdb               0.00     0.00    0.00   67.00     0.00  1352.50    40.37     0.52    7.69   7.66  51.30
sdd               0.00     0.00    0.00   50.00     0.00  1259.50    50.38     0.51   10.14  10.10  50.50
sdc               0.00     0.00    0.00   50.00     0.00  1259.50    50.38     0.42    8.32   8.28  41.40
md2               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
md1               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
md0               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
md3               0.00     0.00    0.00   84.00     0.00  2612.00    62.19     0.00    0.00   0.00   0.00
dm-0              0.00     0.00    0.00   84.00     0.00  2612.00    62.19     0.98   12.18  11.63  97.70


Xen PV (4.2.0):
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00   327.00   15.00  682.00    60.00 18116.00    52.15     2.90    4.17   0.53  36.80
sdb               0.00   326.00    0.00  683.00     0.00 18116.00    53.05     1.56    2.29   0.37  25.30
sdc               0.00   271.00    4.00  626.00    16.00 17300.00    54.97     1.04    1.66   0.33  20.80
sdd               0.00   270.00    0.00  627.00     0.00 17300.00    55.18     1.34    2.13   0.29  18.30
md2               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
md1               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
md0               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
md127             0.00     0.00   19.00 1904.00    76.00 35408.00    36.90     0.00    0.00   0.00   0.00
dm-0              0.00     0.00   19.00 1904.00    76.00 35408.00    36.90     6.49    3.37   0.24  45.20
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00

De results bij Xen zijn duidelijk zichtbaar, echter was de server + xen op dat moment ook nog druk bezig met rebuilden van een verse RAID-10 array! Na het rebuilden waren writes/sec van 2500+ heel normaal.
Bij de KVM opstelling had het systeem al moeite om te pieken op 84 writes /sec - average was vele malen lager (15-50 het gros van de tijd).


Iemand een soort gelijk probleem gehad, en wellicht ook een oplossing?
Ik zie veel toekomst in KVM, echter met "kansloze" disk I/O hier praktisch onbruikbaar

Ik heb wel performance verschil gevoelsmatig gehad tussen IDE en de VIRTIO driver, maar dat was lang niet zo droevig als wat jij nu schetst.
Wel interessant om hier ook eens te meten. Maar dat gaat op z'n vroegst januari worden.

http://people.redhat.com/vrozenfe/build-48/

Probeer deze eens, er zijn wat "aparte" problemen in combinatie met 2.6.32 kernel en Virtio.

@Bart,
Dat lijkt betrekking te hebben tot Windows. Het probleem doet zich bij mij voor bij Linux OSen - ook wanner de guest kernel 3.5.x (Ubuntu 12.10) gebruikt, ik ga er dan toch wel vanuit dat er inmiddels een degelijke Virtio driver is ingebakken.
Windows heb ik nog niet geprobeerd - zal kijken of ik daar vandaag eens tijd voor heb

Wat ik nog vergeten was te melden in de TS. Zodra er een OS geinstalleerd is op de guest, en ik vervolgens een write test doe met DD...... raar maar waar op een lege host (1 guest) haal ik dan toch nog 190MB/s.
Maar zodra er ook maar iets van random I/O komt (denk aan het readen van een kleine 500KB file), blijft er van de write performance op at moment helemaal niets over. Ook wanneer er meerdere guests actief zijn, duikt de performance snel in elkaar, zelfs als er praktisch geen I/O is.
Apt-get upgrade binnen Ubuntu is natuurlijk een hele berg random I/O, maar dan zou een simpele kernel upgrade echt geen 30+ min nodig moeten hebben. Simpele zaken zoals "tcpdump / iptraf / nano / wget / sysstat " duren ook gerust enkele minuten.
Zelfde kernel update gaat op een oud 80GB IDE schijfje nog tig keer sneller - je zou verwachten dat het met 4*7200RPM disks @ RAID-10 helemaal los zou moeten komen

Ik heb even een CentOS installatie getimed op KVM met een ISO. Pak en beet 5 minuten nodig voor CentOS 5; dit is ruim inclusief het configgen en met Virtio.Dit is wel icm hardware RAID 10 en een E3-1230 V1 CPU, in principe zijn dit geen afwijkende specs. De disks zijn wel enterprise 1 TB disks (ook van Seagate). Updaten en installeren van random yum dingetjes geven ook geen problemen op de gast. Dit is overigens op een VPS node waar ook andere guest's op draaien incl Windows.

Ik weet alleen niet wat het effect van software RAID is bij KVM, hier heb ik verder geen test's mee uitgevoerd. Maar zo'n groot verschil heb ik niet. Gebruik je de standaard instellingen van SolusVM met de disk cache?

Hmmm, strange
Kwa RAID... als er op de host zelf geen problemen zijn, dan lijkt mij dat het probleem buiten hard/software RAID zit. Als de software raid array een bottleneck zou vormen lijkt mij dat ik dit op zijn minst zou moeten merken op de host zelf.

Met de cache settings heb ik zowel "default" (writethrough) als "none" geprobeerd. Bij gebruik van "none" is de disk throughput (bij een dd write test) wel vele malen hoger.
Ik heb het idee dat 'writethrough' wel iets (maar minimaal) beter performed wanneer 1 guest actief is. Bij meerdere guests lijkt "none" toch de beste keus.
Wanneer ik met dd een write test doe op de guest haal ik met:
- Writethrough, +/- 50 tot 70MB/s
- None, +/- 160 - 190MB/s
(dit met uitsluitend write I/O - zodra er random I/O komt kijken blijft er praktisch geen performance over).

Update! :-)
Vanmiddag besloten om vanaf scratch te beginnen. Vervolgens een SolusVM install erop zoals gebruikelijk. Vervolgens libvirt/qemu (kort maar krachtig, alles m.b.t kvm) eruit gedonderd.
Vervolgens libvirt 1.0 en qemu-kvm 1.2 vanuit de source compiled. Resultaat was al een heel stuk beter (read's van 300MB/s binnen guests).
Aangezien ik toch bezig was de kernel stap gemaakt, en een custom kernel naar eigen smaak compiled (3.6.9) - inmiddels is 3.6.10 ook uit maar daarin zie ik geen spannende wijzigingen m.b.t. mijn doel.
Hier wat snelle results:

- read benchmark guest OS (580 - 600MB/s bij het lezen van 100 files van bij elkaar 20GB groot)
- write benchmark guest OS (250 - 300MB/s bij het schrijven van 100 files van bij elkaar 20GB groot)
- random access time ( 6 a 8 ms bij 1000 seeks test)
- Windows 2008 STD install binnen +/- 5 minuten, en dat met de IDE driver!
- CentOS 6.3 install in pak 'n beet 3 minuten

Wat me vooral opvalt is dat nu het performance verschil tussen IDE en Virtio een heel stuk kleiner is.

Tijd voor wat meer benchmarks, maar de eerste results zeggen al een hoop

Ten eerste moet ik even melden dat Random IO altijd een heel stuk trager is dan sequentiele throughput. Vooral op tragere schijven zonder hardware RAID.

Het draaien van VM's is haast altijd Random IO dus hier moet je je systeem op aanschafffen/configureren.

Bij het gebruik van ruwe volumes of partities (LVM) is het advies dat je beter "cache=none" kan instellen, dit geeft minder overhead. (http://www.linux-kvm.org/page/Tuning_KVM)

Er zijn trouwens drie settings mogelijk voor Linux Software RAID 10, welke heb je gekozen? “near”, “far” of “offset”?

Nog een vraagje, welke IO scheduler gebruik je? Deadline is geadviseerd voor KVM...

@Netbulae;

De RAID-10 array is vrij standaard, en draait volgens de "n2" setting.
Aan de IO scheduler heb ik zelf nog niet eens gedacht - dat was allemaal standaard. Ga nu de dev bak even rebooten, met de "deadline" io scheduler, en gelijk "vm.swappinnes = 0".

Oorspronkelijk geplaatst door Lite-On

@Netbulae;

De RAID-10 array is vrij standaard, en draait volgens de "n2" setting.
Aan de IO scheduler heb ik zelf nog niet eens gedacht - dat was allemaal standaard. Ga nu de dev bak even rebooten, met de "deadline" io scheduler, en gelijk "vm.swappinnes = 0".

Ik zou het eens met de "offset" (ow) layout proberen. Lees dit artikel maar eens:

http://www.ilsistemista.net/index.ph...l?limitstart=0

(o2) bedoelde ik ipv (ow). typo