TauCeti.NET The lost star colony...

KVM Benchmark: Apachebench, IOzone, Graphics Magick

Update 20100115: Bezügl. I/O-Performance und dem qcow2-Format, sollte man das hier noch lesen: Features/KVM qcow2 Performance . Seit Qemu/KVM 0.11.0 hat sich da einiges getan. Vorraussetzung für die bessere Performance ist aber, das man das qcow2-Image mit Qemu >= Version 0.11.0 erzeugt hat. Es kann also durchaus Sinn machen, ein altes Image in ein Neues zu konvertieren.

Ich habe in den letzten Tagen auf einem HP DL 380 G6 Server ein paar Benchmarks mit der Linux Kernel Virtual Maschine (KVM) gemacht. Ich persönlich nutze die KVM schon seit fast zwei Jahren und produktiv laufen aktuell über 40 VMs. Die Stabilität und die Performance hat sich in den letzten Releases sehr gut entwickelt und die Entwicklung geht sehr schnell voran.

Der Host und der Gast liefen mit Gentoo und Kernel 2.6.31.1. Der Host hat folgende Komponeten eingebaut:

2 x Intel Xeon CPU L5520 - 2 Quad-Processors (static performance, VT-d, Hyperthreading eingeschaltet in BIOS)
8 x 300 GB SAS 10k Festplatten (RAID 10)
24 GB RAM

(Einige) Host (kernel) Einstellungen:
I/O scheduler: deadline
Filesystem: xfs
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
CONFIG_VIRTIO_BLK=m
CONFIG_VIRTIO_NET=m
CONFIG_VIRTIO_CONSOLE=m
CONFIG_HW_RANDOM_VIRTIO=m
CONFIG_VIRTIO=m
CONFIG_VIRTIO_RING=m
CONFIG_VIRTIO_PCI=m
CONFIG_VIRTIO_BALLOON=m

(Einige) Gast (Kernel) Einstellungen:
I/O scheduler: deadline/cfq (siehe unten)
Filesystem: ext3 (datamode=ordered/writeback [siehe unten])
VIRTIO Network (VIRTIO_NET) und Block (VIRTIO_BLK) Treiber verwendet.
Der Gast ist ein qcow2-Image, welches ich vorher mit "dd" erweitert habe, damit es für den IO Test groß genug ist und nicht erst während des Tests erweitert wird (was die Werte total verfälscht hätte).
CONFIG_KVM_CLOCK=y
CONFIG_KVM_GUEST=y
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_VIRTIO_BLK=y
CONFIG_VIRTIO_NET=m
CONFIG_VIRTIO_CONSOLE=y
CONFIG_HW_RANDOM_VIRTIO=y
CONFIG_VIRTIO=y
CONFIG_VIRTIO_RING=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_BALLOON=y
CONFIG_PARAVIRT_SPINLOCKS=y

KVM Startup Optionen (die Wichtigsten):
-m "variabel-siehe unten"
-smp "variabel-siehe unten"
-cpu host
-daemonize
-drive file=/data/kvm/kvmimages/gfs1.qcow2,if=virtio,boot=on
-net nic,vlan=104,model=virtio,macaddr=00:ff:48:23:45:4b
-net tap,vlan=104,ifname=tap.b.gfs1,script=no
-net nic,vlan=96,model=virtio,macaddr=00:ff:48:23:45:4d
-net tap,vlan=96,ifname=tap.f.gfs1,script=no

Da wir KVM hauptsächlich für Webserver benötigen, habe ich Benchmarks mit Apachebench, Graphics Magick und IOzone erstellt:

Apachebench mit 4 GB RAM, CFQ Scheduler, 1/2/4/8 vProcs verglichen mit dem Host (der hp380g6 Graph):
http://www.tauceti.net/kvm-benchmarks/merge-3428/
Apachebench mit 2 GB RAM, CFQ Scheduler, 1/2/4/8 vProcs verglichen mit dem Host:
http://www.tauceti.net/kvm-benchmarks/merge-6053/

Mich hat hier u.a. interessiert, ob mehr RAM mehr Durchsatz bringt und ob mehrere virtuelle Prozessoren skalieren. Wenn man die 2xQuadCore + Hyperthreading mit den 8 virtuellen Prozessoren (vProcs) vergleicht, dann kann die KVM hier mithalten. Die Speichergröße spielt keine Rolle.

Graphics Magick resize mit 4 GB RAM, CFQ scheduler, 1/2/4/8 vProcs verglichen mit dem Host (der hp380g6 Graph):
http://www.tauceti.net/kvm-benchmarks/merge-5214/
Graphics Magick resize mit 2 GB RAM, CFQ scheduler, 1/2/4/8 vProcs verglichen mit dem Host (the hp380g6 graph):
http://www.tauceti.net/kvm-benchmarks/merge-7186/

Mit 8 vProcs ist die KVM ungefähr 10% langsamer. Mehr Speicher scheint auch hier nicht zu helfen.

Der folgende IOzone Test lief mit der KVM-Option cache=none. In diesem Fall ist alleine der Host für's Wegschreiben der Daten verantwortlich. Das erscheint mir aktuell immer noch die sicherste Option zu sein, um die Datenintegrität des KVM-Images und der Filesysteme in der KVM sicher zu stellen. Allerdings bremst das die Performance:

IOzone Schreibtest (write) mit 2 GB RAM, CFQ scheduler, ext3 Filesystem und datamode=ordered, 1/2/4/8 vProcs verglichen mit dem Host (der hp380g6 Graph):
http://www.tauceti.net/kvm-benchmarks/merge-3564/
IOzone Schreibtest (write) mit 2 GB RAM, deadline scheduler, ext3 Filesystem und datamode=ordered, 1/2/4/8 vProcs:
http://www.tauceti.net/kvm-benchmarks/merge-4533/

Wie man sieht, bringt das Austauschen des Schedulers ungefähr 10-15 MByte/s mehr an Durchsatz. Die CPU-Auslastung habe ich aber nicht überprüft während des Tests.

Die folgenden IOzone Tests liefen ohne cache-Option und somit mit dem Defaultwert writethrough:

IOzone Schreibtest (write) mit 2 GB RAM, deadline scheduler, ext3-Filesystem und writeback (siehe Testseite), 8 vProcs verglichen mit dem Host (der hp380g6 Graph):
http://www.tauceti.net/kvm-benchmarks/merge-7526/

Die Zahlen sind relativ beeindruckend. Die KVM kann eigentlich fast immer - mit den entsprechenden Einstellungen - mit dem "echten" Host mithalten in diesen Tests. Den Netzdurchsatz müsste man jetzt noch messen, dann wäre der gesamte Benchmark schon fast vollständig.

Posted at 11:32nachm. Okt. 06, 2009 by cetixx in Tipps  |  Kommentare [3]