it-swarm.com.de

Unglaublich niedrig KVM Festplattenleistung (qcow2-Festplattendateien + virtio)

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

  • Der Gast ist mit ein paar CPUs und 4 GB RAM) konfiguriert und führt derzeit nichts anderes aus. Die Installation ist derzeit völlig minimal.
  • Die Leistung wird mit time dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=16000 Getestet.
  • Der Gast ist für die Verwendung von virtio konfiguriert, dies scheint jedoch keinen Einfluss auf die Leistung zu haben.
  • Die Host-Partitionen sind 4 KB ausgerichtet (und die Leistung auf dem Host ist sowieso in Ordnung).
  • Die Verwendung von Writeback-Caching auf den Datenträgern erhöht die gemeldete Leistung massiv, aber ich würde es vorziehen, sie nicht zu verwenden. Auch ohne sollte die Leistung weitaus besser sein.
  • Host und Gast führen beide Ubuntu 12.04 LTS aus, das mit qemu-kvm 1.0 + noroms-0ubuntu13 und libvirt 0.9.8-2ubuntu17.1 geliefert wird.
  • Der Host hat die Frist 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 sollte ich zu diesem Zeitpunkt eine weitaus bessere Leistung erzielen, also scheint etwas bereits sehr falsch zu sein.

pdate 1

Und plötzlich, wenn ich zurück gehe und jetzt teste, ist es 26.6 MB/s; Dies ist eher das, was ich mit qcrow2 erwartet hatte. Ich werde die Frage offen lassen, falls jemand irgendwelche Ideen hat, was das Problem gewesen sein könnte (und falls es auf mysteriöse Weise wieder zurückkommt).

pdate 2

Ich habe aufgehört, mir Gedanken über die Leistung von qcow2 zu machen, und bin einfach mit RAW1 auf LVM über RAID1 umgestiegen. Ich habe immer noch virtio verwendet, aber auf dem Festplattenlaufwerk cache = 'none' und io = 'native' gesetzt. Die Schreibleistung beträgt jetzt ca. 135 MB/s unter Verwendung des gleichen Basistests wie oben, daher scheint es nicht sinnvoll zu sein, herauszufinden, wo das Problem lag, wenn es so einfach vollständig umgangen werden kann.

29
El Yobo

Ja, qcow2-Dateien sind nicht für eine blitzschnelle Leistung ausgelegt. Sie werden viel mehr Glück mit rohen Partitionen (oder vorzugsweise LVs) haben.

15
womble

So erreichen Sie Spitzenleistung mit QCOW2:

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

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

Sie können auch einen unsicheren Cache bereitstellen, wenn dies keine Produktionsinstanz ist (dies ist gefährlich und nicht empfohlen, nur zum Testen geeignet):

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

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

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

8
lzap

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

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

hiermit werden Gast-Caches deaktiviert und AIO (Asynchronous IO) aktiviert. Durch Ausführen Ihres Befehls dd erhielt ich 177 MB/s auf dem Host und 155 MB/s auf dem Gast. Das Image befindet sich auf demselben LVM-Volume, auf dem der Host-Test durchgeführt wurde.

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

6
gertas

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 liegenden Speicher (Backstore) für meine iSCSI-LUNs habe ich zunächst LVM verwendet, dann aber auf dateibasierte Images umgestellt.

Lange Rede, kurzer Sinn: Wenn der Sicherungsspeicher an den Speichercontroller virtio_blk (vda, vdb usw.) angehängt ist, betrug die Leistung des iSCSI-Clients, der eine Verbindung zum iSCSI-Ziel herstellt, in meiner Umgebung ~ 20 IOPS mit Durchsatz (abhängig von IO Größe) ~ 2-3 MiB/s. Ich habe den virtuellen Festplattencontroller innerhalb der virtuellen Maschine auf SCSI geändert und kann über 1000 IOPS und einen Durchsatz von über 100 MiB/s von meinen iSCSI-Clients 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>
3
Greg W

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 brachte mich von 3 MB/s auf 70 MB/s

2
Kourindou Hime

In alten Qemu/KVM-Versionen war das Qcow2-Backend sehr langsam, wenn es nicht vorab zugewiesen wurde, insbesondere 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: Writeback Cache ist der bevorzugte Modus, es sei denn, Sie verwenden einen Gast ohne oder mit deaktivierter Unterstützung für das Löschen/Sperren des Festplatten-Cache. In der Praxis werden Win2000 + -Gäste und alle Linux EXT4-, XFS- oder EXT3 + -Barriermontageoptionen mit Bußgeldern belegt. Andererseits sollte cache = unsicher niemals von Produktionsmaschinen verwendet werden, da Cache-Leergut nicht an das Host-System weitergegeben wird. Ein unerwartetes Herunterfahren des Hosts kann das Dateisystem des Gastes buchstäblich zerstören.

2
shodanshok