Viele Blogs gelesen und viel probiert und endlich habe ich´ s gefunden. Nachdem ich mich dieses mal für KVM auf einem Server entschieden hatte, war die Ernüchertung groß, als die Plattenperformance bei ca. 1MB/Sekunde dahindümpelte.
Späßchen wie dieser kleine Test hier:
time dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=160 160+0 Datensätze ein 160+0 Datensätze aus 10485760 Bytes (10 MB) kopiert, 12,6418 s, 829 kB/s
oder
time dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=1600 (abgebrochen, weil´ es zulange dauerte) 1085+0 Datensätze ein 1085+0 Datensätze aus 71106560 Bytes (71 MB) kopiert, 51,3672 s, 1,4 MB/s
frustierten jeden Tag, besonders weil es auf der Dom0 so aussah:
Auf der Dom0:
time dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=16000 16000+0 records in 16000+0 records out 1048576000 bytes (1.0 GB) copied, 8.83056 s, 119 MB/s
Ich habe Google bemüht und viel gelesen. Daraufhin von QCOW auf RAW images in Logical Volumes umgestellt, Virtio eingesetzt – doch nichts hat geholfen. Zwischenzeitlich dachte ich es sei meine ext4 Partitionierung. Aber auch mit ext3 war´s lahm und die Partitionen hatten das richtige Alignment.
Heute dann der entscheidende Versuch. Das Caching! Komplett abgestellt ergibt sich auf einmal ein um 9400% schnelleres Bild (nur um mal dicke Zahlen zu spucken, wenn man nicht unbedingt eine 1GB große File schreibt, wird es schon langsamer sein).
Hier die entscheidenden Zeilen in der XML Defition des Gastes:
von
<disk type='block' device='disk'> <driver name='qemu' type='raw'/>
zu
<disk type='block' device='disk'> <driver name='qemu' type='raw' cache='none'/>
und siehe da:
time dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=16000 16000+0 Datensätze ein 16000+0 Datensätze aus 1048576000 Bytes (1,0 GB) kopiert, 11,0531 s, 94,9 MB/s
Happy End.