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

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 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.