Frage Unglaublich langsame KVM-Festplattenleistung (qcow2-Dateien + virtio)


Beim Einrichten eines KVM-Gastes treten schwerwiegende Probleme mit der Datenträgerleistung auf. Mit einem einfachen dd test, schreibt die Partition auf dem Host, auf der sich die qcow2-Images befinden (ein gespiegeltes RAID-Array), bei over 120 MB / s, während mein Gast schreibt, reicht von 0,5 bis 3 MB / s.

  • Der Gast ist mit ein paar CPUs und 4G RAM konfiguriert und läuft derzeit nichts anderes; Im Moment ist es eine minimale Installation.
  • Die Leistung wird mit getestet time dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=16000.
  • Der Gast ist für die Verwendung von virtio konfiguriert, dies scheint jedoch für die Leistung keinen Unterschied zu machen.
  • Die Host-Partitionen sind 4kB ausgerichtet (und Leistung ist auf dem Host sowieso in Ordnung).
  • Das Verwenden von Writeback-Caching auf den Datenträgern erhöht die gemeldete Leistung massiv, aber ich würde es vorziehen, es nicht zu verwenden; auch ohne es sollte die Leistung weit besser sein.
  • Gastgeber und Gast betreiben beide Ubuntu 12.04 LTS, das mit qemu-kvm 1.0 + noroms-0ubuntu13 und libvirt 0.9.8-2ubuntu17.1 geliefert wird.
  • Der Host hat den Termin-E / A-Scheduler aktiviert und der Gast hat Noop.

Es scheint eine Menge an Guides zu geben, die die Kvm-Performance verbessern, und ich werde es irgendwann schaffen, aber es scheint, als würde ich zu diesem Zeitpunkt eine weitaus bessere Performance bekommen als das, daher scheint es, dass etwas schon sehr falsch ist.

Update 1

Und plötzlich, wenn ich zurück gehe und es jetzt teste, ist es 26.6 MB / s; Das ist mehr wie ich erwartet hatte mit qcrow2. Ich lasse die Frage offen, für den Fall, dass jemand irgendwelche Ideen hat, was das Problem gewesen sein könnte (und falls es auf mysteriöse Weise wiederkehrt).

Update 2

Ich habe aufgehört, mir Gedanken über die Leistung von qcow2 zu machen, und habe einfach mit RAW-Bildern auf LVM übergegriffen. Dabei verwende ich immer noch virtio, aber setze cache = 'none' und io = 'native' auf dem Laufwerk. Schreibleistung ist jetzt appx. 135 MB / s mit dem gleichen grundlegenden Test wie oben, so scheint es nicht viel Sinn zu haben, herauszufinden, was das Problem war, wenn es so einfach um völlig herum bearbeitet werden kann.


22
2017-07-15 06:36


Ursprung


Sie haben die verwendeten Distributions- und Softwareversionen nicht erwähnt. - dyasny
Einige Informationen zu Versionen hinzugefügt. - El Yobo
ah, wie erwartet, ubuntu ... jede Chance, die Sie auf Fedora reproduzieren können? - dyasny
Der Server ist in Deutschland und ich bin gerade in Mexiko, das könnte ein bisschen knifflig sein. Und wenn es plötzlich funktionieren würde ... würde ich immer noch nicht mit einem Fedora-Server arbeiten wollen;) Ich habe ein paar Kommentare gesehen, die darauf hindeuten, dass Debian / Ubuntu-Systeme mehr Probleme als Fedora / CentOS für KVM hatten Die Entwicklungsarbeit wurde dort gemacht. - El Yobo
Genau mein Punkt. und in jedem Fall, wenn Sie nach einem Server-Grade-Betriebssystem sind, benötigen Sie RHEL, nicht Ubuntu - dyasny


Antworten:


Nun, ja, qcow2-Dateien sind nicht für blitzschnelle Leistung ausgelegt. Sie werden viel mehr Glück aus rohen Partitionen (oder vorzugsweise LVs).


13
2017-07-15 07:45



Natürlich, aber sie sind auch nicht so mies wie die Zahlen, die ich bekomme. - El Yobo
Die meisten Beispiele zeigen eine ähnliche Leistung mit qcow2, was eine deutliche Verbesserung gegenüber der älteren Version darstellt. Die KVM-Seite selbst hat Zahlen erreicht linux-kvm.org/page/Qcow2 die vergleichbare Zeiten für eine Reihe von Fällen zeigen. - El Yobo
18:35 (qcow2) vs 8:48 (roh) ist "vergleichbare Zeiten"? - womble♦
Ich habe sie auf LVM-gestützte RAW-Images auf RAID1 umgestellt, den io-Scheduler auf den Gast und die Deadline auf dem Host gesetzt und schreibt jetzt mit 138 MB / s. Ich weiß immer noch nicht, was es bewirkt hat, dass qcow2 die Geschwindigkeit von 3MB / s hat, aber klarerweise kann man es umgehen, indem man roh verwendet, also danke, dass du mich in diese Richtung gedrängt hast. - El Yobo
Das ist nicht ganz richtig - die neuesten Patches in qemu beschleunigen qcow2 sehr! Wir sind fast auf Augenhöhe. - lzap


Ich habe mit dieser Einstellung großartige Ergebnisse für das qcow2-Bild erzielt:

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

Dies deaktiviert Gast-Caches und aktiviert AIO (Asynchronous IO). Lauf dein dd Befehl gab mir 177MB / s auf Host und 155MB / s auf Gast. Das Bild wird auf demselben LVM-Volume platziert, auf dem der Host-Test durchgeführt wurde.

Meine qemu-kvm Version ist 1.0+noroms-0ubuntu14.8 und Kernel 3.2.0-41-generic ab Lager Ubuntu 12.04.2 LTS.


5
2018-06-15 21:29



Sie legen einen qcow2-Bildtyp auf "roh" fest? - Alex
Ich denke, ich habe älteren Eintrag kopiert, ich nehme an, dass die Geschwindigkeitsvorteile gleich sein sollten type='qcow2'Könntest du das überprüfen, bevor ich es bearbeite? Ich habe keinen Zugang mehr zu einer solchen Konfiguration - ich bin zu LXC mit migriert mount bind Verzeichnisse, um echte natürliche Geschwindigkeiten bei Gästen zu erreichen. - gertas


Wie zu erreichen Top-Performance mit QCOW2:

qemu-img create -f qcow2 -o preallocation=metadata,compat=1.1,lazy_refcounts=on imageXYZ

Der wichtigste ist die Vorab-Zuweisung, die laut qcow2-Entwicklern einen schönen Schub gibt. Es ist fast auf Augenhöhe mit LVM jetzt! Beachten Sie, dass dies normalerweise in modernen (Fedora 25+) Linux-Distributionen aktiviert ist.

Sie können auch unsicheren Cache bereitstellen, wenn dies der Fall ist keine Produktionsinstanz (das ist gefährlich und nicht empfehlenswert, nur gut zum Testen):

<driver name='qemu' cache='unsafe' />

Einige Benutzer berichten, dass diese Konfiguration in einigen Tests die LVM / unsichere Konfiguration übertrifft.

Für alle diese Parameter neueste QEMU 1.5+ Wird benötigt! Auch hier haben die meisten modernen Distributionen diese.


5
2017-11-25 21:04



Es ist nicht eine gute Idee, Cache = unsicher zu verwenden: ein unerwarteter Host - Shutdown kann Chaos anrichten ganz Gastdateisystem. Es ist viel besser, Cache zu verwenden = Rückschreiben: ähnliche Leistung, aber viel bessere Zuverlässigkeit. - shodanshok
Wie ich sagte: wenn dies keine Produktionsinstanz ist (gut zum Testen) - lzap
Meinetwegen. Ich habe es verpasst ;) - shodanshok


Wenn Sie Ihren vms mit einem einzigen Befehl ausführen, können Sie Argumente verwenden

kvm -drive file = / path_to.qcow2, wenn = virtio, cache = aus <...>

Es hat mich von 3MB / s auf 70MB / s gebracht


2
2018-04-02 16:06





Bei alten Qemu / KVM-Versionen war das Qcow2-Backend sehr langsam, wenn es nicht vorab zugewiesen wurde, insbesondere dann, wenn es ohne Write-Back-Cache verwendet wurde. Sehen Sie hier für weitere Informationen.

In neueren Qemu-Versionen sind Qcow2-Dateien viel schneller, selbst wenn keine Vorbelegung (oder nur Vorbelegung von Metadaten) verwendet wird. Dennoch bleiben LVM-Volumes schneller.

Eine Anmerkung zu den Cache-Modi: Schreib zurück Cache ist der bevorzugte Modus, es sei denn, man verwendet einen Gast ohne oder mit deaktivierter Unterstützung für Festplatten-Cache-Flush / Barrieren. In der Praxis sind Win2000 + Guests und alle Linux EXT4-, XFS- oder EXT3 + -Montieroptionen Bußgelder. Auf der anderen Seite sollte Cache = unsicher sein noch nie von Produktionsmaschinen verwendet werden, da Cache-Flushes nicht an das Host-System weitergegeben werden. Ein unerwarteter Host-Shutdown kann das Dateisystem des Gastes zerstören.


2
2018-04-02 17:23





Ich habe genau das gleiche Problem erlebt. Innerhalb der virtuellen Maschine von RHEL7 habe ich die LIO iSCSI-Zielsoftware, mit der sich andere Maschinen verbinden. Als zugrundeliegender Speicher (Backstore) für meine iSCSI-LUNs habe ich anfangs LVM verwendet, bin dann aber zu dateibasierten Images gewechselt.

Lange Rede, kurzer Sinn: Wenn Backing Storage an den Storage Controller virtio_blk (vda, vdb, etc.) angehängt ist - Performance von iSCSI client Verbindung zum iSCSI Target war in meiner Umgebung ~ 20 IOPS, mit Durchsatz (abhängig von IO Größe) ~ 2- 3 MiB / s. Ich habe den virtuellen Festplatten-Controller innerhalb der virtuellen Maschine auf SCSI umgestellt und bin in der Lage, mehr als 1000 IOPS und einen Durchsatz von 100+ MiB / s von meinen iSCSI-Clients zu erhalten.

<disk type='file' device='disk'>
   <driver name='qemu' type='qcow2' cache='none' io='native'/>
   <source file='/var/lib/libvirt/images/station1/station1-iscsi1-lun.img'/>
   <target dev='sda' bus='scsi'/>
   <address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>

2
2017-07-24 14:40