Performances du disque KVM incroyablement faibles (fichiers disque qcow2 + virtio)

27

J'ai de sérieux problèmes de performances de disque lors de la configuration d'un invité KVM. À l'aide d'un ddtest simple , la partition sur l'hôte sur laquelle les images qcow2 résident (une matrice RAID en miroir) écrit à plus de 120 Mo / s , tandis que mon invité obtient des écritures allant de 0,5 à 3 Mo / s .

  • L'invité est configuré avec quelques processeurs et 4 Go de RAM et n'exécute actuellement rien d'autre; c'est une installation complètement minimale pour le moment.
  • Les performances sont testées à l'aide de time dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=16000.
  • L'invité est configuré pour utiliser virtio, mais cela ne semble pas faire de différence dans les performances.
  • Les partitions hôtes sont alignées à 4 Ko (et les performances sont bonnes sur l'hôte, de toute façon).
  • L'utilisation de la mise en cache en écriture différée sur les disques augmente massivement les performances signalées, mais je préférerais ne pas l'utiliser; même sans cela, les performances devraient être bien meilleures que cela.
  • L'hôte et l'invité exécutent tous les deux Ubuntu 12.04 LTS, qui est fourni avec qemu-kvm 1.0 + noroms-0ubuntu13 et libvirt 0.9.8-2ubuntu17.1.
  • L'hôte a le planificateur d'E / S de délai activé et l'invité n'a pas de noop.

Il semble y avoir beaucoup de guides pour peaufiner les performances kvm, et j'y arriverai finalement, mais il semble que je devrais obtenir des performances bien meilleures que cela à ce stade, il semble donc que quelque chose soit déjà très mal.

Mise à jour 1

Et soudain, quand je reviens et que je teste maintenant, c'est 26,6 Mo / s; c'est plus ce à quoi je m'attendais avec qcrow2. Je laisse la question au cas où quelqu'un aurait une idée de ce qui aurait pu être le problème (et au cas où il reviendrait mystérieusement).

Update 2

J'ai cessé de m'inquiéter des performances de qcow2 et je suis passé à LVM au-dessus de RAID1 avec des images brutes, en utilisant toujours virtio mais en définissant cache = 'none' et io = 'native' sur le lecteur de disque. Les performances d'écriture sont désormais approximatives. 135 Mo / s utilisant le même test de base que ci-dessus, il ne semble donc pas très utile de déterminer quel était le problème alors qu'il peut être si facilement résolu entièrement.

El Yobo
la source
Vous n'avez pas mentionné la distribution et les versions logicielles utilisées.
dyasny
Ajout d'informations sur les versions.
El Yobo
ah, comme prévu, ubuntu ... une chance que vous puissiez reproduire cela sur fedora?
dyasny
Le serveur est en Allemagne et je suis actuellement au Mexique, ce qui pourrait être un peu délicat. Et si cela fonctionnait soudainement ... je ne voudrais toujours pas avoir à traiter avec un serveur Fedora;) J'ai vu quelques commentaires suggérant que les systèmes Debian / Ubuntu avaient plus de problèmes que Fedora / CentOS pour KVM le travail de développement y a été fait.
El Yobo
mon point exactement. et dans tous les cas, si vous recherchez un système d'exploitation de qualité serveur, vous avez besoin de RHEL, pas d'Ubuntu
dyasny

Réponses:

14

Eh bien, oui, les fichiers qcow2 ne sont pas conçus pour des performances incroyablement rapides. Vous aurez beaucoup plus de chance de sortir des partitions brutes (ou, de préférence, des LV).

womble
la source
3
Évidemment, mais ils ne sont pas non plus censés être aussi merdiques que les chiffres que j'obtiens non plus.
El Yobo
1
La plupart des exemples montrent des performances similaires avec qcow2, ce qui semble être une amélioration significative par rapport à l'ancienne version. Le site KVM lui-même a trouvé des chiffres à linux-kvm.org/page/Qcow2 qui montrent des temps comparables pour une gamme de cas.
El Yobo
1
18:35 (qcow2) vs 8:48 (raw) est "des temps comparables"?
womble
1
Je les ai basculés sur des images brutes soutenues par LVM au-dessus de RAID1, défini le programmateur io sur noop sur l'invité et la date limite sur l'hôte et il écrit maintenant à 138 Mo / s. Je ne sais toujours pas ce qui a poussé le qcow2 à avoir des vitesses de 3 Mo / s, mais il est clair qu'il peut être contourné en utilisant du brut, alors merci de m'avoir poussé dans cette direction.
El Yobo
1
Ce n'est pas tout à fait vrai - les derniers correctifs dans qemu accélèrent beaucoup qcow2! Nous sommes presque à égalité.
lzap
7

Comment atteindre des performances optimales avec QCOW2 :

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

Le plus important est la préallocation qui donne un bon coup de pouce, selon les développeurs de qcow2. C'est presque à égalité avec LVM maintenant! Notez que cela est généralement activé dans les distributions Linux modernes (Fedora 25+).

Vous pouvez également fournir un cache non sécurisé s'il ne s'agit pas d'une instance de production (c'est dangereux et déconseillé, seulement bon pour les tests):

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

Certains utilisateurs signalent que cette configuration bat la configuration LVM / dangereuse dans certains tests.

Pour tous ces paramètres, la dernière version de QEMU 1.5+ est requise! Encore une fois, la plupart des distributions modernes en ont.

lzap
la source
2
Ce n'est pas une bonne idée d'utiliser cache = unsafe: un arrêt d'hôte inattendu peut faire des ravages sur l' ensemble du système de fichiers invité. Il est bien préférable de cache utilisation = writeback: des performances similaires, mais bien meilleure fiabilité.
shodanshok
1
Comme je l'ai dit: si ce n'est pas une instance de production (bon pour les tests)
lzap
C'est suffisant. Je l'ai raté;)
shodanshok
6

J'ai obtenu d'excellents résultats pour l'image qcow2 avec ce paramètre:

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

qui désactive les caches invités et active AIO (Asynchronous IO). L'exécution de votre ddcommande m'a donné 177 Mo / s sur l'hôte et 155 Mo / s sur l'invité. L'image est placée sur le même volume LVM où le test de l'hôte a été effectué.

Ma qemu-kvmversion est 1.0+noroms-0ubuntu14.8et le noyau 3.2.0-41-genericdu stock Ubuntu 12.04.2 LTS.

gertas
la source
5
Vous définissez un type d'image qcow2 sur "brut"?
Alex
Je suppose que j'ai copié une entrée plus ancienne, je suppose que les avantages de vitesse devraient être les mêmes type='qcow2', pourriez-vous vérifier cela avant de modifier? Je n'ai plus accès à une telle configuration - j'ai migré vers LXC avec des mount bindrépertoires pour atteindre de véritables vitesses natives chez les invités.
gertas
2

Si vous exécutez votre vms avec une seule commande, pour les arguments que vous pouvez utiliser

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

Cela m'a fait passer de 3 Mo / s à 70 Mo / s

Kourindou Hime
la source
2

Sur les anciennes versions de Qemu / KVM, le backend Qcow2 était très lent lorsqu'il n'était pas préalloué, surtout s'il était utilisé sans cache d'écriture différée activé. Voir ici pour plus d'informations.

Sur les versions plus récentes de Qemu, les fichiers Qcow2 sont beaucoup plus rapides, même lorsqu'ils n'utilisent pas de pré-allocation (ou de pré-allocation de métadonnées uniquement). Pourtant, les volumes LVM restent plus rapides.

Remarque sur les modes de cache: le cache d' écriture différée est le mode préféré, sauf si vous utilisez un invité sans prise en charge ou désactivé pour le vidage / les barrières du cache de disque. Dans la pratique, les invités Win2000 + et toutes les options de montage de barrière Linux EXT4, XFS ou EXT3 + sont des amendes. D'un autre côté, cache = unsafe ne doit jamais être utilisé sur les machines de production, car les vidages de cache ne sont pas propagés au système hôte. Un arrêt d'hôte inattendu peut littéralement détruire le système de fichiers de l'invité.

shodanshok
la source
2

J'ai vécu exactement le même problème. Dans la machine virtuelle RHEL7, j'ai un logiciel cible LIO iSCSI auquel d'autres machines se connectent. En tant que stockage sous-jacent (backstore) pour mes LUN iSCSI, j'ai d'abord utilisé LVM, mais je suis ensuite passé à des images basées sur des fichiers.

En bref: lorsque le stockage de sauvegarde est attaché au contrôleur de stockage virtio_blk (vda, vdb, etc.) - les performances du client iSCSI se connectant à la cible iSCSI étaient dans mon environnement ~ 20 IOPS, avec un débit (selon la taille des IO) ~ 2- 3 Mio / s. J'ai changé le contrôleur de disque virtuel au sein de la machine virtuelle en SCSI et je peux obtenir plus de 1000 IOPS et un débit de 100+ Mo / s de mes clients iSCSI.

<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
la source