Increíblemente bajo rendimiento del disco KVM (archivos de disco qcow2 + virtio)

Tengo algunos problemas graves de rendimiento del disco al configurar un invitado KVM. Usando una ddprueba simple , la partición en el host en el que residen las imágenes qcow2 (una matriz RAID duplicada) escribe a más de 120 MB / s , mientras que mi invitado recibe escrituras que varían de 0.5 a 3 MB / s .

• El invitado está configurado con un par de CPU y 4G de RAM y actualmente no está ejecutando nada más; Es una instalación completamente mínima en este momento.
• El rendimiento se prueba usando time dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=16000.
• El invitado está configurado para usar virtio, pero esto no parece hacer una diferencia en el rendimiento.
• Las particiones del host están alineadas a 4 kb (y el rendimiento es bueno en el host, de todos modos).
• El uso del almacenamiento en caché de reescritura en los discos aumenta enormemente el rendimiento informado, pero prefiero no usarlo; incluso sin él, el rendimiento debería ser mucho mejor que esto.
• El host y el invitado ejecutan Ubuntu 12.04 LTS, que viene con qemu-kvm 1.0 + noroms-0ubuntu13 y libvirt 0.9.8-2ubuntu17.1.
• El host tiene habilitado el planificador de IO de fecha límite y el invitado tiene noop.

Parece que hay muchas guías que modifican el rendimiento de kvm, y llegaré allí eventualmente, pero parece que debería estar obteniendo un rendimiento mucho mejor que esto en este momento, por lo que parece que algo ya está muy mal.

Actualización 1

Y de repente, cuando vuelvo y pruebo ahora, son 26.6 MB / s; Esto es más parecido a lo que esperaba con qcrow2. Dejaré la pregunta en caso de que alguien tenga alguna idea sobre cuál podría haber sido el problema (y en caso de que vuelva misteriosamente).

Actualización 2

Dejé de preocuparme por el rendimiento de qcow2 y simplemente corté a LVM en la parte superior de RAID1 con imágenes en bruto, todavía usando virtio pero configurando cache = 'none' e io = 'native' en la unidad de disco. El rendimiento de escritura ahora es appx. 135 MB / s usando la misma prueba básica que la anterior, por lo que no parece tener mucho sentido descubrir cuál era el problema cuando se puede solucionar tan fácilmente.

Bueno, sí, los archivos qcow2 no están diseñados para un rendimiento increíblemente rápido. Obtendrá mucha mejor suerte de las particiones en bruto (o, preferiblemente, LV).

Cómo lograr el máximo rendimiento con QCOW2 :

qemu-img create -f qcow2 -o preallocation=metadata,compat=1.1,lazy_refcounts=on imageXYZ

El más importante es la preasignación, que da un buen impulso, según los desarrolladores de qcow2. ¡Está casi a la par con LVM ahora! Tenga en cuenta que esto generalmente está habilitado en las distribuciones de Linux modernas (Fedora 25+).

También puede proporcionar memoria caché insegura si esta no es una instancia de producción (esto es peligroso y no se recomienda, solo es bueno para las pruebas):

<driver name='qemu' cache='unsafe' />

Algunos usuarios informan que esta configuración supera la configuración LVM / insegura en algunas pruebas.

¡Para todos estos parámetros se requiere la última versión de QEMU 1.5+ ! Una vez más, la mayoría de las distribuciones modernas tienen estos.

Logré excelentes resultados para la imagen qcow2 con esta configuración:

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

que deshabilita los cachés de invitados y habilita AIO (Asynchronous IO). Ejecutar su ddcomando me dio 177 MB / s en el host y 155 MB / s en el invitado. La imagen se coloca en el mismo volumen LVM donde se realizó la prueba del host.

Mi qemu-kvmversión es 1.0+noroms-0ubuntu14.8y kernel 3.2.0-41-genericdel stock Ubuntu 12.04.2 LTS.

Si está ejecutando su vms con un solo comando, para argumentos puede usar

kvm -drive file = / path_to.qcow2, if = virtio, cache = off <...>

Me consiguió de 3 MB / sa 70 MB / s

En versiones antiguas de Qemu / KVM, el backend de Qcow2 era muy lento cuando no estaba preasignado, más aún si se usaba sin caché de reescritura habilitada. Ver aquí para más información.

En las versiones más recientes de Qemu, los archivos Qcow2 son mucho más rápidos, incluso cuando no se utiliza una asignación previa (o una asignación previa solo de metadatos). Aún así, los volúmenes LVM siguen siendo más rápidos.

Una nota sobre los modos de caché: la caché de reescritura es el modo preferido, a menos que se use un invitado sin compatibilidad o deshabilitado para la descarga / barreras de caché de disco. En la práctica, los invitados Win2000 + y cualquier opción de montaje de barrera EXT4, XFS o EXT3 + de Linux son multas. Por otro lado, cache = inseguro nunca debe usarse en máquinas de producción, ya que los vaciamientos de caché no se propagan al sistema host. Un apagado inesperado del host puede literalmente destruir el sistema de archivos del huésped.

Experimenté exactamente el mismo problema. Dentro de la máquina virtual RHEL7 tengo el software de destino LIO iSCSI al que se conectan otras máquinas. Como almacenamiento subyacente (backstore) para mis iSCSI LUN inicialmente utilicé LVM, pero luego cambié a imágenes basadas en archivos.

En pocas palabras: cuando el almacenamiento de respaldo está conectado al controlador de almacenamiento virtio_blk (vda, vdb, etc.): el rendimiento del cliente iSCSI que se conectó al objetivo iSCSI estaba en mi entorno ~ 20 IOPS, con rendimiento (dependiendo del tamaño de IO) ~ 2- 3 MiB / s. Cambié el controlador de disco virtual dentro de la máquina virtual a SCSI y puedo obtener más de 1000 IOPS y un rendimiento de más de 100 MiB / s de mis clientes iSCSI.

<disk type='file' device='disk'>
   <driver name='qemu' type='qcow2' cache='none' io='native'/>
   <source file='/var/lib/libvirt/images/station1/station1-iscsi1-lun.img'/>
   <target dev='sda' bus='scsi'/>
   <address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>