web-dev-qa-db-fra.com

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

J'ai une configuration du système hôte QEMU-KVM sur Centos 6.3. Quatre disques disques SATA de 1TB travaillant dans le logiciel RAID10. Guest Centos 6.3 est installé sur LVM séparé. Les gens disent qu'ils considèrent la performance des invités presque égale à la performance de l'hôte, mais je ne vois pas cela. Mes tests d'E/S indiquent 30 à 70% des performances plus lentes sur invité que sur le système hôte. J'ai essayé de changer de planificateur (ensemble elevator=deadline sur l'hôte et elevator=noop sur invité), ensemble blkio.weight à 1000 en cgroup, changez IO en virtio ... mais aucun de ces changements ne m'a donné des résultats significatifs. Ceci est une partie de configuration invitée .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>

Il y a mes tests:

Système hôte :

test de 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 

dD Lire le test: 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 de 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 

dD Lire le test: 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 est cette situation normale ou ai-je manqué quelque chose?

13
Evolver

Vous n'êtes pas encore fait avec le réglage de la performance.

  <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: Emulation de POSIX AIO à l'aide d'un pool de threads de travailleur et de l'Aio Linux natif.

Définir soit io='native' ou io='threads' Dans votre XML pour comparer chacune d'elles.

La seconde est quel mécanisme de mise en cache à utiliser. Vous pouvez définir cache='writeback', cache='writethrough' ou vous pouvez l'éteindre avec cache='none', que vous trouverez peut-être le mieux.

Si vous utilisez des volumes brutes ou des partitions, 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.

N'utilisez pas writeback si votre matrice RAID est sauvegardé par une batterie, ou si vous risquez de perdre des données. (Bien sûr, si la perte de données est correcte, n'hésitez pas.)

Troisièmement, d'autres choses susceptibles d'aider à désactiver les obstacles et à utiliser le planificateur de date limite dans l'invité.

Enfin, faites des recherches. IBM a fait une présentation très intéressante sur KVM Performances d'E/S à la Conférence de 2010 Linux Plombiers. En outre, ils ont un ensemble complet des meilleures pratiques sur l'utilisation de KVM qui sera certainement intéressante.

P.s. Des lectures séquentielles longues et des écritures sont rarement représentatives d'une charge de travail du monde réel. Essayez de faire des repères avec d'autres types de charges de travail, idéalement la ou les applications réelles que vous avez l'intention d'exécuter dans la production.

22
Michael Hampton