Incroyablement faible KVM (fichiers disque qcow2 + virtio)
Je rencontre de graves problèmes de performances de disque lors de la configuration d'un invité KVM. À l'aide d'un simple test dd, la partition de l'hôte sur laquelle résident les images qcow2 (un miroir) RAID array) écrit à plus de 120 Mo/s, tandis que mon invité obtient des écritures allant de ,5 à 3 Mo/s.
- L'invité est configuré avec quelques CPU et 4G 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 de l'hôte 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 la date limite IO planificateur 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).
mise à jour 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 en 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.
Eh bien, oui, les fichiers qcow2 ne sont pas conçus pour des performances incroyablement rapides. Vous aurez beaucoup plus de chance avec les partitions brutes (ou, de préférence, les LV).
Comment atteindre 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 coup de pouce à Nice, 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é si c'est pas une instance de production (c'est dangereux et non recommandé, 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 le dernier QEMU 1.5 + est requis! Encore une fois, la plupart des distributions modernes en ont.
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 commande dd 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-kvm la version est 1.0+noroms-0ubuntu14.8 et noyau 3.2.0-41-generic en stock Ubuntu 12.04.2 LTS.
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 IO taille) ~ 2-3 Mio/s. J'ai changé le contrôleur de disque virtuel dans la machine virtuelle en SCSI et je peux obtenir plus de 1000 IOPS et un débit de 100+ Mio/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>
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
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 du cache de disque/les barrières. 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 inattendu de l'hôte peut littéralement détruire le système de fichiers de l'invité.