Desempenho de disco KVM incrivelmente lento (arquivos de disco qcow2 + virtio)

Question

Estou com sérios problemas de desempenho de disco ao configurar um convidado KVM. Usando um teste dd simples, a partição no host em que as imagens qcow2 residem (uma matriz RAID espelhada) grava em 120MB / s , enquanto meu convidado recebe gravações que variam de 0,5 para 3MB / s .

• O convidado está configurado com algumas CPUs e 4G de RAM e não está executando mais nada no momento; é uma instalação completamente mínima no momento.
• O desempenho é testado usando time dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=16000 .
• O convidado está configurado para usar o virtio, mas isso não parece fazer diferença no desempenho.
• As partições do host são 4kb alinhadas (e o desempenho é bom no host, de qualquer forma).
• Usar o cache de write-back nos discos aumenta o desempenho relatado em massa, mas prefiro não usá-lo; mesmo sem desempenho deve ser muito melhor do que isso.
• Host e guest estão executando o Ubuntu 12.04 LTS, que vem com qemu-kvm 1.0 + noroms-0ubuntu13 e libvirt 0.9.8-2ubuntu17.1.
• O host tem o agendador de IO de prazo ativado e o convidado tem noop.

Parece haver muitos guias por aí que estão melhorando o desempenho do kvm, e eu vou chegar lá eventualmente, mas parece que eu deveria estar tendo um desempenho muito melhor do que isso neste momento, então parece que algo já está muito errado.

Atualização 1

E, de repente, quando volto e testo agora, são 26,6 MB / s; isso é mais parecido com o que eu esperava w / qcrow2. Deixarei a pergunta para o caso de alguém ter alguma idéia do que poderia ter sido o problema (e no caso dele misteriosamente retornar novamente).

Atualização 2

Parei de me preocupar com o desempenho do qcow2 e recortei para o LVM sobre o RAID1 com imagens brutas, ainda usando o virtio, mas definindo cache = 'none' e io = 'native' no drive de disco. O desempenho de gravação agora é appx. 135MB / s usando o mesmo teste básico acima, então não parece haver muito sentido em descobrir qual era o problema quando ele pode ser facilmente trabalhado por completo.

    

Answer 1

Bem, sim, arquivos qcow2 não são projetados para um desempenho incrivelmente rápido. Você terá muito mais sorte com partições simples (ou, preferencialmente, LVs).

    

Answer 2

Como alcançar o desempenho máximo com o QCOW2 :

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

O mais importante é a pré-alocação que dá um bom impulso, de acordo com os desenvolvedores do qcow2. Está quase em paridade com o LVM agora! Note que isto é normalmente habilitado em distribuições Linux modernas (Fedora 25+).

Além disso, você pode fornecer cache inseguro se não for a instância de produção (isso é perigoso e não é recomendado, só é bom para testes):

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

Alguns usuários relatam que essa configuração supera a configuração LVM / insegura em alguns testes.

Para todos estes parâmetros mais recente QEMU 1.5 + é necessário! Mais uma vez, a maioria das distros modernas tem essas.

    

Answer 3

Consegui ótimos resultados para a imagem qcow2 com essa configuração:

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

que desativa os caches de convidado e ativa o AIO (Asynchronous IO). A execução do seu comando dd me deu 177MB / s no host e 155MB / s no guest. A imagem é colocada no mesmo volume do LVM onde o teste do host foi feito.

Meu qemu-kvm versão é 1.0+noroms-0ubuntu14.8 e kernel 3.2.0-41-generic do estoque Ubuntu 12.04.2 LTS.

    

Answer 4

Se você está executando o seu vms com um único comando, para argumentos você pode usar

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

Isso me levou de 3 MB / s para 70 MB / s

    

Answer 5

Nas versões antigas do Qemu / KVM, o backend Qcow2 era muito lento quando não pré-alocado, mais ainda se usado sem o cache de write-back ativado. Veja aqui para mais informações.

Em versões mais recentes do Qemu, os arquivos Qcow2 são muito mais rápidos, mesmo quando não usam nenhuma pré-alocação (ou pré-alocação apenas de metadados). Ainda assim, os volumes de LVM permanecem mais rápidos.

Uma nota sobre os modos de cache: o cache writeback é o modo preferencial, a menos que você use um convidado sem ou com suporte desabilitado para liberar / barrar o cache de disco. Na prática, os convidados Win2000 + e quaisquer opções de montagem de barreira Linux EXT4, XFS ou EXT3 + são multas. Por outro lado, cache = inseguro deve nunca ser usado em máquinas de produção, já que liberações de cache não são propagadas para o sistema host. Um desligamento inesperado do host pode literalmente destruir o sistema de arquivos do convidado.

    

Answer 6

Eu experimentei exatamente o mesmo problema. Dentro da máquina virtual RHEL7, tenho o software de destino LIO iSCSI ao qual outras máquinas se conectam. Como armazenamento subjacente (backstore) para minhas LUNs iSCSI, inicialmente usei o LVM, mas depois mudei para imagens baseadas em arquivos.

Longa história curta: quando o armazenamento de apoio é anexado a virtio_blk (vda, vdb, etc) controlador de armazenamento - desempenho do cliente iSCSI conectando ao destino iSCSI estava no meu ambiente ~ 20 IOPS, com taxa de transferência (dependendo do tamanho IO) ~ 2-3 MiB / s. Mudei o controlador de disco virtual dentro da máquina virtual para SCSI e consegui obter mais de 1000 IOPS e transferir mais de 100 MiB / s dos meus 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>