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

13

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.

Evolver
fuente
Dijiste que has cambiado tu invitado para usar un tipo de virtio de bus que ofrece un mejor rendimiento, pero debe tener los controladores virtio instalados para obtener estos beneficios. No dijiste si los estás usando o no. No conozco CentOS lo suficiente como para comentar si estos controladores estarán presentes en su invitado de forma predeterminada o no.
jwbensley
1
@javano CentOS siempre incluye virtio y tendrías que eliminarlo explícitamente reconstruyendo los paquetes del kernel.
Michael Hampton
Siempre útil para saber,
salud

Respuestas:

21

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.

Michael Hampton
fuente
+1 para "prueba con su patrón IO"
Javier
Oh, buenos likes para los documentos de IBM, +1 :)
jwbensley
1
Muy útil, gracias! Ahora he mejorado los resultados de mis invitados hasta un 90% del rendimiento del host. Mi culpa fue bastante estúpida: virsh reset <domain>no virsh edit <domain>apliqué mis cambios y creía que el invitado usaba virtio, pero en realidad no lo hizo. Solo virsh destroy <domain>seguido por virsh start <domain>ayudado. Virtio gobierna! ;)
Evolver
1
cache = writeback no agrega ningún riesgo en la vida real (los datos importantes no están en peligro, solo los datos en vuelo, que de todos modos se descartan en caso de accidente). Solo caché = inseguro lo hace. La reescritura no implica requisitos de hardware adicionales ("matriz RAID respaldada por batería" no ayuda de ninguna manera). Tiene el mismo nivel de integridad que un caché de escritura de HDD: el sistema operativo enjuaga ambos cuando es necesario.
Korkman
io='native'dio casi un 20-30% de rendimiento adicional de ESCRITURA en mi caso
rahul286