KVM guest io es mucho más lento que el host io: ¿es eso normal?

Tengo una configuración del sistema host Qemu-KVM en CentOS 6.3. Cuatro discos duros SATA de 1 TB que funcionan en RAID10 de software. Guest CentOS 6.3 está instalado en LVM separado. La gente dice que ven el rendimiento de los invitados casi igual al rendimiento del host, pero yo no lo veo. Mis pruebas de E / S muestran un rendimiento 30-70% más lento en el invitado que en el sistema host. Traté de cambiar el planificador (configurado elevator=deadlineen el host y elevator=noopen el invitado), establecerlo blkio.weighten 1000 en cgroup, cambiar io a virtio ... Pero ninguno de estos cambios me dio ningún resultado significativo. Esta es una parte de configuración de invitado .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>

Estas son mis pruebas:

Sistema host:

prueba de iozona

# 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 

prueba de lectura dd: un proceso y luego cuatro procesos simultáneos

# 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

prueba de escritura dd: un proceso y luego cuatro procesos simultáneos

# 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

Sistema de invitados:

prueba de iozona

# 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 

prueba de lectura dd: un proceso y luego cuatro procesos simultáneos

# 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

prueba de escritura dd: un proceso y luego cuatro procesos simultáneos

# 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

Me pregunto si es esa situación normal o me perdí algo.

Aún no has terminado con el ajuste del rendimiento.

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

Primero es qué mecanismo de E / S usar.

QEMU tiene dos mecanismos de E / S asíncronas: emulación POSIX AIO utilizando un grupo de subprocesos de trabajo y Linux AIO nativo.

Establezca io='native'o io='threads'en su XML para comparar cada uno de estos.

El segundo es qué mecanismo de almacenamiento en caché utilizar. Puede configurar cache='writeback', cache='writethrough'o puede desactivarlo cache='none', con lo que en realidad puede encontrar que funciona mejor.

Si está utilizando volúmenes o particiones sin procesar, es mejor evitar la memoria caché por completo, lo que reduce las copias de datos y el tráfico del bus.

No lo use a writebackmenos que su matriz RAID esté respaldada por batería o corra el riesgo de perder datos. (Por supuesto, si perder datos está bien, entonces siéntase libre).

Tercero, algunas otras cosas que pueden ayudar incluyen apagar las barreras y usar el programador de la fecha límite en el invitado.

Finalmente, investiga un poco. IBM hizo una presentación muy interesante sobre el rendimiento de E / S KVM en la Conferencia de fontaneros de Linux 2010. Además, tienen un amplio conjunto de mejores prácticas sobre el uso de KVM que sin duda serán de interés.

PD: Las largas lecturas y escrituras secuenciales rara vez son representativas de una carga de trabajo del mundo real. Intente realizar puntos de referencia con otros tipos de cargas de trabajo, idealmente las aplicaciones reales que pretende ejecutar en producción.