L'invité io KVM est beaucoup plus lent que l'hôte io: est-ce normal?


13

J'ai une configuration de système hôte Qemu-KVM sur CentOS 6.3. Quatre disques durs SATA de 1 To fonctionnant en logiciel RAID10. CentOS 6.3 invité est installé sur un LVM distinct. Les gens disent qu'ils voient les performances des invités presque égales aux performances de l'hôte, mais je ne vois pas cela. Mes tests d'E / S montrent des performances 30 à 70% plus lentes sur l'invité que sur le système hôte. J'ai essayé de changer le planificateur (défini elevator=deadlinesur l'hôte et elevator=noopsur l'invité), défini blkio.weightsur 1000 dans cgroup, changer io en virtio ... Mais aucun de ces changements ne m'a donné de résultats significatifs. Il s'agit d'une partie de configuration invité .xml:

<disk type='file' device='disk'>
  <driver name='qemu' type='raw'/>
  <source file='/dev/vgkvmnode/lv2'/>
  <target dev='vda' bus='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</disk>

Voici mes tests:

Système hôte:

test d'iozone

# iozone -a -i0 -i1 -i2 -s8G -r64k
                                                            random  random 
              KB  reclen   write rewrite    read    reread    read   write 
         8388608      64  189930  197436   266786   267254   28644   66642 

test de lecture dd: un processus puis quatre processus simultanés

# dd if=/dev/vgkvmnode/lv2 of=/dev/null bs=1M count=1024 iflag=direct
1073741824 bytes (1.1 GB) copied, 4.23044 s, 254 MB/s

# dd if=/dev/vgkvmnode/lv2 of=/dev/null bs=1M count=1024 iflag=direct skip=1024 & dd if=/dev/vgkvmnode/lv2 of=/dev/null bs=1M count=1024 iflag=direct skip=2048 & dd if=/dev/vgkvmnode/lv2 of=/dev/null bs=1M count=1024 iflag=direct skip=3072 & dd if=/dev/vgkvmnode/lv2 of=/dev/null bs=1M count=1024 iflag=direct skip=4096
1073741824 bytes (1.1 GB) copied, 14.4528 s, 74.3 MB/s
1073741824 bytes (1.1 GB) copied, 14.562 s, 73.7 MB/s
1073741824 bytes (1.1 GB) copied, 14.6341 s, 73.4 MB/s
1073741824 bytes (1.1 GB) copied, 14.7006 s, 73.0 MB/s

test d'écriture dd: un processus puis quatre processus simultanés

# dd if=/dev/zero of=test bs=1M count=1024 oflag=direct
1073741824 bytes (1.1 GB) copied, 6.2039 s, 173 MB/s

# dd if=/dev/zero of=test bs=1M count=1024 oflag=direct & dd if=/dev/zero of=test2 bs=1M count=1024 oflag=direct & dd if=/dev/zero of=test3 bs=1M count=1024 oflag=direct & dd if=/dev/zero of=test4 bs=1M count=1024 oflag=direct
1073741824 bytes (1.1 GB) copied, 32.7173 s, 32.8 MB/s
1073741824 bytes (1.1 GB) copied, 32.8868 s, 32.6 MB/s
1073741824 bytes (1.1 GB) copied, 32.9097 s, 32.6 MB/s
1073741824 bytes (1.1 GB) copied, 32.9688 s, 32.6 MB/s

Système invité:

test d'iozone

# iozone -a -i0 -i1 -i2 -s512M -r64k
                                                            random  random
              KB  reclen   write rewrite    read    reread    read   write
          524288      64   93374  154596   141193   149865   21394   46264 

test de lecture dd: un processus puis quatre processus simultanés

# dd if=/dev/mapper/VolGroup-lv_home of=/dev/null bs=1M count=1024 iflag=direct skip=1024
1073741824 bytes (1.1 GB) copied, 5.04356 s, 213 MB/s

# dd if=/dev/mapper/VolGroup-lv_home of=/dev/null bs=1M count=1024 iflag=direct skip=1024 & dd if=/dev/mapper/VolGroup-lv_home of=/dev/null bs=1M count=1024 iflag=direct skip=2048 & dd if=/dev/mapper/VolGroup-lv_home of=/dev/null bs=1M count=1024 iflag=direct skip=3072 & dd if=/dev/mapper/VolGroup-lv_home of=/dev/null bs=1M count=1024 iflag=direct skip=4096
1073741824 bytes (1.1 GB) copied, 24.7348 s, 43.4 MB/s
1073741824 bytes (1.1 GB) copied, 24.7378 s, 43.4 MB/s
1073741824 bytes (1.1 GB) copied, 24.7408 s, 43.4 MB/s
1073741824 bytes (1.1 GB) copied, 24.744 s, 43.4 MB/s

test d'écriture dd: un processus puis quatre processus simultanés

# dd if=/dev/zero of=test bs=1M count=1024 oflag=direct
1073741824 bytes (1.1 GB) copied, 10.415 s, 103 MB/s

# dd if=/dev/zero of=test bs=1M count=1024 oflag=direct & dd if=/dev/zero of=test2 bs=1M count=1024 oflag=direct & dd if=/dev/zero of=test3 bs=1M count=1024 oflag=direct & dd if=/dev/zero of=test4 bs=1M count=1024 oflag=direct
1073741824 bytes (1.1 GB) copied, 49.8874 s, 21.5 MB/s
1073741824 bytes (1.1 GB) copied, 49.8608 s, 21.5 MB/s
1073741824 bytes (1.1 GB) copied, 49.8693 s, 21.5 MB/s
1073741824 bytes (1.1 GB) copied, 49.9427 s, 21.5 MB/s

Je me demande si cette situation est normale ou si j'ai raté quelque chose?


Vous avez dit que vous avez changé d'invité pour utiliser un type de bus virtio qui donne de meilleures performances, mais il doit avoir les pilotes virtio installés pour profiter de ces avantages. Vous n'avez pas dit si vous les utilisiez ou non. Je ne connais pas suffisamment CentOS pour commenter si ces pilotes seront présents dans votre invité par défaut ou non.
jwbensley

1
@javano CentOS inclut toujours virtio et vous devrez le supprimer explicitement en reconstruisant les packages du noyau.
Michael Hampton

Toujours à portée de main,
merci

Réponses:


22

Vous n'avez pas encore terminé le réglage des performances.

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

Le premier est le mécanisme d'E / S à utiliser.

QEMU a deux mécanismes d'E / S asynchrones: l'émulation POSIX AIO utilisant un pool de threads de travail et Linux AIO natif.

Définissez soit io='native'ou io='threads'dans votre XML pour comparer chacun d'eux.

Le deuxième est le mécanisme de mise en cache à utiliser. Vous pouvez définir cache='writeback', cache='writethrough'ou vous pouvez le désactiver cache='none', ce qui vous semble le mieux fonctionner.

Si vous utilisez des volumes ou des partitions bruts, il est préférable d'éviter complètement le cache, ce qui réduit les copies de données et le trafic de bus.

Ne l'utilisez writebackque si votre matrice RAID est alimentée par batterie ou si vous risquez de perdre des données. (Bien sûr, si la perte de données est OK, alors n'hésitez pas.)

Troisièmement, certaines autres choses peuvent aider à éliminer les barrières et à utiliser le planificateur de délais dans l'invité.

Enfin, faites quelques recherches. IBM a fait une présentation très intéressante sur les performances des E / S KVM lors de la conférence Linux Plumbers 2010. De plus, ils ont un ensemble complet de meilleures pratiques sur l'utilisation de KVM qui sera certainement intéressant.

PS Les longues lectures et écritures séquentielles sont rarement représentatives d'une charge de travail réelle. Essayez de faire des tests de performances avec d'autres types de charges de travail, idéalement les applications réelles que vous avez l'intention d'exécuter en production.


+1 pour "tester avec votre modèle d'E / S"
Javier

Oh,
j'aime

1
Très utile, merci! Maintenant, j'ai amélioré mes résultats d'invité jusqu'à 90% par rapport aux performances de l'hôte. Ma faute était assez stupide: virsh reset <domain>je n'ai pas appliqué mes virsh edit <domain>modifications, et je croyais que l'invité utilisait virtio, mais ce n'était pas le cas. Seulement virsh destroy <domain>suivi par virsh start <domain>aidé. Les règles de Virtio! ;)
Evolver

1
cache = writeback n'ajoute aucun risque réel (les données importantes ne sont pas en danger, seulement les données en vol, qui sont de toute façon rejetées lors d'un crash). Seul cache = dangereux le fait. L'écriture différée n'implique pas de configuration matérielle supplémentaire (la «matrice RAID sauvegardée par batterie» n'aide en aucune façon). Il a le même niveau d'intégrité qu'un cache d'écriture de disque dur: les deux sont vidés lorsque cela est nécessaire par le système d'exploitation.
korkman

io='native'a donné près de 20 à 30% de performances d'écriture supplémentaires dans mon cas
rahul286
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.