Dienstag Okt. 06, 2009

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.

Kommentare:

Was nimmst du als Storage her ? Hast du das ganze schonmal mit GlusterFS getestet ?

Gesendet von Sebastian am Dezember 21, 2009 at 05:33 nachm. MEZ #

Das stand eigentlich im Text dabei:

8 x 300 GB SAS 10k Festplatten (RAID 10)

GlusterFS in dem Sinne wie du es meinst (also als geshare'ten Storage für KVM) noch nicht. Aber GlusterFS innerhalb von KVMs funktioniert einwandfrei. Aber nachdem man KVMs jetzt mit Qemu 0.12 wohl auch live von Rechner zu Rechner migrieren kann, ohne ein geshare'tes Storage zu haben, werde ich das auch nicht mehr testen. Verteilte Dateisysteme sind gut und schön und manchmal sinnvoll, aber im Bebrieb auch nicht ohne Probleme. Ich halte es nach dem Motto: Keep it simple stupid ;-)

Gesendet von cetixx am Dezember 22, 2009 at 03:21 nachm. MEZ #

Ach was, Quemu ab 0.12 kann live von Rechner zu Rechner ohne shared-storage? (Danke für den Tipp, habe es jetzt auch gefunden.)
Geil, hat das schon mal jemand hier ausprobiert?
Also für simple System A auf System B Migration wäre das natürlich schon eine super Vereinfachung.

Gesendet von goooby am Februar 06, 2010 at 02:32 nachm. MEZ #

Senden Sie einen Kommentar:
  • HTML Syntax: Ausgeschaltet