Unglaublich niedrige KVM-Festplattenleistung (qcow2-Datenträgerdateien + virtio)

27

Beim Einrichten eines KVM-Gasts treten einige schwerwiegende Probleme mit der Festplattenleistung auf. Mit einem einfachen ddTest schreibt die Partition auf dem Host, auf dem sich die qcow2-Images befinden (ein gespiegeltes RAID-Array), mit über 120 MB / s , während mein Gast Schreibgeschwindigkeiten im Bereich von 0,5 bis 3 MB / s erhält .

  • Der Gast ist mit einigen CPUs und 4 GB RAM konfiguriert und führt derzeit nichts anderes aus. Es ist im Moment eine völlig 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 keinen Einfluss auf die Leistung zu haben.
  • Die Host-Partitionen sind auf 4 KB ausgerichtet (und die Leistung auf dem Host ist ohnehin in Ordnung).
  • Durch die Verwendung des Rückschreib-Caches auf den Datenträgern wird die gemeldete Leistung massiv erhöht, aber ich würde es vorziehen, sie nicht zu verwenden. auch ohne sollte die leistung deutlich besser sein.
  • Auf Host und Gast wird Ubuntu 12.04 LTS ausgeführt, das mit qemu-kvm 1.0 + noroms-0ubuntu13 und libvirt 0.9.8-2ubuntu17.1 geliefert wird.
  • Host hat den Deadline-IO-Scheduler aktiviert und der Gast hat Noop.

Es scheint viele Anleitungen zu geben, die die KVM-Leistung optimieren, und ich werde es irgendwann schaffen, aber es scheint, als würde ich zu diesem Zeitpunkt eine wesentlich bessere Leistung erzielen, sodass es den Anschein hat, als ob etwas bereits sehr falsch ist.

Update 1

Und plötzlich, wenn ich jetzt zurückkehre und teste, sind es 26,6 MB / s; das ist eher so, wie ich es erwartet hatte w / qcrow2. Ich werde die Frage offen lassen, falls jemand eine Idee hat, was das Problem sein könnte (und falls es auf mysteriöse Weise wieder auftritt).

Update 2

Ich habe aufgehört, mir Sorgen um die Leistung von qcow2 zu machen, und bin einfach über RAID1 mit Raw-Images auf LVM umgestiegen. Ich habe immer noch virtio verwendet, aber auf der Festplatte den Cache auf 'none' und io = 'native' gesetzt. Die Schreibleistung ist jetzt ca. 135 MB / s unter Verwendung des gleichen Basistests wie oben, daher scheint es nicht sinnvoll zu sein, herauszufinden, was das Problem war, wenn es so einfach umgangen werden kann.

El Yobo
quelle
Sie haben die verwendeten Distributions- und Softwareversionen nicht erwähnt.
Dyasny
Einige Informationen zu Versionen hinzugefügt.
El Yobo
ah, wie erwartet, Ubuntu ... Gibt es eine Chance, dass Sie dies auf Fedora reproduzieren können?
Dyasny
Der Server ist in Deutschland und ich bin gerade in Mexiko, also könnte das ein bisschen knifflig sein. Und wenn es plötzlich klappen würde ... Ich möchte mich immer noch nicht mit einem Fedora-Server befassen müssen;) Ich habe ein paar Kommentare gesehen, die darauf hindeuten, dass Debian / Ubuntu-Systeme mehr Probleme hatten als Fedora / CentOS für KVM Dort wurde die Entwicklungsarbeit geleistet.
El Yobo
Genau mein Punkt. und auf jeden Fall, wenn Sie nach einem Server-Grade-Betriebssystem sind, brauchen Sie RHEL, nicht Ubuntu
dyasny

Antworten:

14

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

womble
quelle
3
Natürlich, aber sie sollen auch nicht so beschissen sein wie die Zahlen, die ich bekomme.
El Yobo
1
Die meisten Beispiele zeigen eine ähnliche Leistung wie qcow2, was eine deutliche Verbesserung gegenüber der älteren Version darstellt. Die KVM-Site selbst hat unter linux-kvm.org/page/Qcow2 eine Reihe von Zahlen, die vergleichbare Zeiten für eine Reihe von Fällen anzeigen .
El Yobo
1
18:35 (qcow2) vs 8:48 (raw) ist "vergleichbare Zeiten"?
womble
1
Ich habe sie auf LVM-gestützte Raw-Images auf RAID1 umgestellt, den io-Scheduler auf noop für den Gast und deadline für den Host eingestellt und schreibt jetzt mit 138 MB / s. Ich weiß immer noch nicht, warum der qcow2 die Geschwindigkeit von 3 MB / s erreicht hat, aber mit Raw kann er eindeutig umgangen werden. Vielen Dank, dass Sie mich in diese Richtung getrieben haben.
El Yobo
1
Das ist nicht ganz richtig - die neuesten Patches in Qemu beschleunigen Qcow2 sehr! Wir sind fast gleichauf.
25.
7

So erreichen Sie mit QCOW2 Höchstleistungen :

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

Das wichtigste ist laut den Entwicklern von qcow2 die Vorbelegung, die einen netten Schub gibt. Es ist jetzt fast auf dem Niveau von LVM ! Beachten Sie, dass dies normalerweise in modernen Linux-Distributionen (Fedora 25+) aktiviert ist.

Sie können auch unsicheren Cache bereitstellen, wenn es sich nicht um eine Produktionsinstanz handelt (dies ist gefährlich und nicht empfohlen, nur zum Testen geeignet):

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

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

Für all diese Parameter ist die neueste QEMU 1.5+ erforderlich! Wieder haben die meisten modernen Distributionen diese.

lzap
quelle
2
Es ist keine gute Idee, cache = unsafe zu verwenden: Ein unerwartetes Herunterfahren des Hosts kann das gesamte Dateisystem des Gasts in Mitleidenschaft ziehen. Es ist viel besser, cache = writeback zu verwenden: ähnliche Leistung, aber viel bessere Zuverlässigkeit.
Shodanshok
1
Wie gesagt: Wenn dies keine Produktionsinstanz ist (gut zum Testen)
lzap
Meinetwegen. Ich habe es verpasst;)
Shodanshok
6

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

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

Hiermit werden Gast-Caches deaktiviert und AIO (Asynchronous IO) aktiviert. ddWenn Sie Ihren Befehl ausführen, habe ich 177 MB / s auf dem Host und 155 MB / s auf dem Gast. Das Image wird auf dasselbe LVM-Volume gestellt, auf dem der Host-Test durchgeführt wurde.

Meine qemu-kvmVersion ist 1.0+noroms-0ubuntu14.8und Kernel 3.2.0-41-genericab Lager Ubuntu 12.04.2 LTS.

gertas
quelle
5
Sie setzen einen Bildtyp von qcow2 auf "raw"?
Alex
Ich denke, ich habe einen älteren Eintrag kopiert. Ich nehme an, die Geschwindigkeitsvorteile sollten gleich sein type='qcow2'. Könnten Sie das überprüfen, bevor Sie ihn bearbeiten? Ich habe keinen Zugriff mehr auf eine solche Konfiguration - ich bin mit mount bindVerzeichnissen auf LXC umgestiegen , um echte native Geschwindigkeiten bei Gästen zu erreichen.
Gertas
2

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

kvm -drive file = / path_to.qcow2, if = virtio, cache = off <...>

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

Kourindou Hime
quelle
2

In alten Qemu / KVM-Versionen war das Qcow2-Backend sehr langsam, wenn es nicht vorab zugeordnet wurde. Dies gilt umso mehr, wenn es ohne aktivierten Rückschreibcache verwendet wurde. Weitere Informationen finden Sie hier.

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

Ein Hinweis zu den Cache-Modi: Der Rückschreib- Cache ist der bevorzugte Modus, es sei denn, Sie verwenden einen Gast mit keiner oder deaktivierter Unterstützung für das Leeren / Sperren des Festplatten-Cache. In der Praxis sind Win2000 + -Gäste und alle Linux EXT4-, XFS- oder EXT3 + -Barrier-Mount-Optionen Bußgelder. Auf der anderen Seite sollte für Produktionsmaschinen niemals cache = unsafe verwendet werden, da Cache-Flushes nicht an das Host-System weitergegeben werden. Ein unerwartetes Herunterfahren des Hosts kann das Dateisystem des Gasts buchstäblich zerstören.

Shodanshok
quelle
2

Ich habe genau das gleiche Problem erlebt. Innerhalb der virtuellen RHEL7-Maschine habe ich eine LIO iSCSI-Zielsoftware, mit der andere Maschinen eine Verbindung herstellen. Als zugrunde liegender Speicher (Backstore) für meine iSCSI-LUNs habe ich zunächst LVM verwendet, dann aber auf dateibasierte Images umgestellt.

Kurz gesagt: Wenn der Sicherungsspeicher an den virtio_blk-Speichercontroller (vda, vdb usw.) angehängt ist, lag die Leistung des iSCSI-Clients, der eine Verbindung zum iSCSI-Ziel herstellt, in meiner Umgebung bei ca. 20 IOPS mit Durchsatz (abhängig von der E / A-Größe). 3 MiB / s. Ich habe den virtuellen Festplattencontroller in der virtuellen Maschine auf SCSI geändert und kann von meinen iSCSI-Clients über 1000 IOPS und einen Durchsatz von über 100 MiB / s erzielen.

<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>
Greg W
quelle