2 votes

IO disque extrêmement lent dans la VM qemu-kvm

J'ai une VM fonctionnant sous Debian Woody (noyau 2.4.18). Qemu-2.1.2, 2 cœurs de CPU, 512M RAM, image qcow2 connectée comme IDE, ext3. Le problème est que les entrées-sorties du disque sont lentes. Voici le résultat de dd "benchmark" juste après le redémarrage de la VM :

(none):~# time dd if=/dev/zero of=test1 bs=102400 count=100
100+0 records in
100+0 records out

real    0m0.035s
user    0m0.000s
sys 0m0.020s
(none):~# time dd if=/dev/zero of=test1 bs=102400 count=100
100+0 records in
100+0 records out

real    0m0.022s
user    0m0.000s
sys 0m0.020s
(none):~# time dd if=/dev/zero of=test1 bs=102400 count=100
100+0 records in
100+0 records out

real    0m55.589s
user    0m0.020s
sys 0m0.560s

Si je regarde ce qui se passe sur l'hôte, je vois que le processus qemu consomme ~90% de CPU (sur un total de 600%), et que la lecture et l'écriture se font à environ 1,2MB/s. Le disque dur lui-même est correct, la vitesse d'écriture est d'environ 70 Mo/s. J'ai essayé différents paramètres VM (y compris "threading" et "usafe"), converti l'image en raw, déplacé l'image vers un système de fichiers fraîchement formaté (j'ai essayé ext4 et btrfs). Aucune différence visible.

J'ai également remarqué des problèmes de vitesse d'E/S pour d'autres VM avec des noyaux plus récents, mais je n'ai pas eu le temps de les tester correctement et j'ai utilisé le montage NFS pour contourner le problème.

Qu'est-ce qui ne va pas ?

UPD Même mount -t nfs ... pendent. strace dit que mount() L'appel se bloque :

mount("192.168.1.1:/mnt/gw/tmp", "/mnt", "nfs", 0xc0ed0000, 0x805a920) = -1 ENOSYS (Function not implemented)
mount("192.168.1.1:/mnt/gw/tmp", "/mnt", "nfs", 0xc0ed0000, 0x805a920) = -1 ENOSYS (Function not implemented)
mount("192.168.1.1:/mnt/gw/tmp", "/mnt", "nfs", 0xc0ed0000, 0x805a920) = -1 ENOSYS (Function not implemented)
mount("192.168.1.1:/mnt/gw/tmp", "/mnt", "nfs", 0xc0ed0000, 0x805a920\[here it freezes for a several minutes\]) = 0

2voto

robmaz Points 11

J'avais l'intention de le faire de toute façon, alors j'ai fait quelques installations.

La valeur par défaut pour les périphériques de type IDE dans cette configuration semble fonctionner à la vitesse du mode PIO alors que haparm revendique le DMA ... en faisant cela dans la VM, c'est environ 70 fois plus rapide sur ma machine.

hdparm -d1 /dev/hda
echo hdparm -d1 /dev/hda > /etc/rcS.d/S00hdparm.sh
chmod +x /etc/rcS.d/S00hdparm.sh

L'autre option est d'utiliser une émulation de disque SCSI, sur la ligne de commande qemu remplacez ceci

-hda $DISK

avec cette

-drive if=scsi,file=$DISK

donne une émulation de périphérique compatible "sym53c8xx" que l'installateur détecte automatiquement. Cela a pour effet agréable que le périphérique s'appelle "/dev/sda" plutôt que l'ancien style "/dev/hda".

Mais attention, il n'est pas simple de changer cela sur un système déjà installé.

Note : l'utilisation de ahci ne fonctionnera pas ; Debian woody est antérieure à SATA.

PS : Mon test de fumée de compatibilité semble la plupart du temps réussie, juste quelques drapeaux GCC stupides. Bonne chance avec le vôtre.

0voto

elbarna Points 312

J'utilise kvm avec libvirt, en utilisant les paramètres unsafe et threads pour i/o. rendent la vm très rapide, bien sûr unsafe signifie qu'il ne faut pas l'utiliser en production. Pour le format, j'utilise raw sans lvm.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X