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


27

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

  • O convidado está configurado com algumas CPUs e 4G de RAM e atualmente não está executando mais nada; é 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 estão alinhadas em 4kb (e o desempenho é bom no host, pelo menos).
  • O uso do cache de write-back nos discos aumenta enormemente o desempenho relatado, mas prefiro não usá-lo; mesmo sem ele, o desempenho deve ser muito melhor que isso.
  • O host e o convidado estão executando o Ubuntu 12.04 LTS, que vem com o qemu-kvm 1.0 + noroms-0ubuntu13 e libvirt 0.9.8-2ubuntu17.1.
  • O host tem o agendador de E / S do prazo ativado e o convidado não tem oop.

Parece haver muitos guias por aí ajustando o desempenho do kvm, e chegarei lá eventualmente, mas parece que eu deveria estar obtendo um desempenho muito melhor do que esse neste momento, então parece que algo já está muito errado.

Atualização 1

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

Atualização 2

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


Você não mencionou as versões de distribuição e software em uso.
dyasny

Adicionadas informações sobre as versões.
El Yobo

ah, como esperado, ubuntu ... alguma chance de você poder reproduzir isso no fedora?
dyasny

O servidor está na Alemanha e atualmente estou no México, o que pode ser um pouco complicado. E se de repente funcionasse ... Eu ainda não gostaria de lidar com um servidor Fedora;) Eu vi alguns comentários sugerindo que os sistemas Debian / Ubuntu tinham mais problemas do que o Fedora / CentOS para KVM. o trabalho de desenvolvimento foi feito lá.
ElYobo

meu ponto, exatamente. e em qualquer caso, se você estiver após um OS grau servidor você precisa RHEL, não Ubuntu
dyasny

Respostas:


14

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


3
Obviamente, mas eles também não devem ser tão ruins quanto os números que estou recebendo também.
ElYobo

1
A maioria dos exemplos mostra um desempenho semelhante com o qcow2, que parece ser uma melhoria significativa em relação à versão anterior. O próprio site da KVM apresentou números em linux-kvm.org/page/Qcow2, que mostram tempos comparáveis ​​para vários casos.
El Yobo

1
18:35 (qcow2) vs 8:48 (bruto) são "tempos comparáveis"?
Womble

1
Eu as troquei para imagens brutas apoiadas pelo LVM em cima do RAID1, configurei o agendador io para noop no convidado e o prazo no host e agora ele grava em 138 MB / s. Ainda não sei o que levou o qcow2 a ter velocidades de 3 MB / s, mas claramente pode ser evitado usando raw, então obrigado por me empurrar nessa direção.
El Yobo

1
Isso não é bem verdade - os últimos patches no qemu aceleram bastante o qcow2! Estamos quase no mesmo nível.
Lzap

7

Como obter o melhor desempenho com o QCOW2 :

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

O mais importante é a pré-localização, o que dá um bom impulso, de acordo com os desenvolvedores do qcow2. Está quase no mesmo nível do LVM agora! Observe que isso geralmente é ativado nas distribuições modernas do Linux (Fedora 25+).

Além disso, você pode fornecer cache não seguro se essa não for uma instância de produção (isso é perigoso e não recomendado, apenas bom para teste):

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

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

Para todos esses parâmetros, é necessário o mais recente QEMU 1.5+ ! Novamente, a maioria das distribuições modernas tem essas.


2
É não uma boa idéia para cache de uso = inseguro: um desligamento anfitrião inesperado pode causar estragos no todo sistema de arquivos convidado. É muito melhor usar cache = write-back: desempenho semelhante, mas confiabilidade muito melhor.
Shodanshok #

1
Como eu já disse: se isso não é instância de produção (bom para teste)
lzap

Justo. Eu perdi;)
shodanshok

6

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

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

que desativa os caches de convidados e habilita o AIO (E / S assíncrona). Executar seu ddcomando me deu 177MB / s no host e 155MB / s no convidado. A imagem é colocada no mesmo volume LVM em que o teste do host foi realizado.

Minha qemu-kvmversão é 1.0+noroms-0ubuntu14.8e kernel 3.2.0-41-genericdo estoque Ubuntu 12.04.2 LTS.


5
Você definiu um tipo de imagem qcow2 como "bruto"?
18713 Alex

Acho que copiei as entradas mais antigas. Suponho que os benefícios de velocidade sejam os mesmos type='qcow2'. Você pode verificar isso antes de editar? Não tenho mais acesso a essa configuração - migrei para o LXC com mount binddiretórios para obter velocidades nativas reais nos convidados.
precisa saber é

2

Se você estiver executando seus vms com um único comando, para argumentos, você pode usar

kvm -drive arquivo = / caminho_para.qcow2, se = virtio, cache = desativado <...>

Me passou de 3MB / s para 70MB / s


2

Nas versões antigas do Qemu / KVM, o back-end do 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.

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

Uma observação sobre os modos de cache: o cache de write - back é o modo preferido, a menos que seja utilizado um convidado com ou sem suporte desabilitado para liberação / barreiras do cache de disco. Na prática, os convidados Win2000 + e qualquer opção de montagem de barreira Linux EXT4, XFS ou EXT3 + são multas. Por outro lado, cache = inseguro nunca deve ser usado em máquinas de produção, pois as 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 hóspede.


2

Eu experimentei exatamente o mesmo problema. Na 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, usei inicialmente o LVM, mas depois mudei para imagens baseadas em arquivo.

Longa história: quando o backup de armazenamento é anexado ao controlador de armazenamento virtio_blk (vda, vdb, etc.) - o desempenho do cliente iSCSI conectado ao destino iSCSI estava no meu ambiente ~ 20 IOPS, com taxa de transferência (dependendo do tamanho do IO) ~ 2- 3 MiB / s. Alterei o controlador de disco virtual dentro da máquina virtual para SCSI e posso obter mais de 1000 IOPS e obter mais de 100 MiB / s de 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>
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.