Desempenho de armazenamento qemu extremamente lento com imagens qcow2

Question

Estou executando algumas imagens usando libvirt em um pequeno cluster Openstack. O desempenho de armazenamento nessas máquinas é extremamente ruim: minha ferramenta de monitoramento mostra 100% de utilização (geralmente em gravações, mas às vezes em leituras) com throughputs de até ~ 50KB / s - até um máximo de cerca de 1MB / s.

Esta é uma captura de tela da ferramenta nmon mostrando o desempenho da CPU ao longo do tempo e a taxa de transferência atual do armazenamento. O que eles mostram é típico:

EurepliqueiomesmoproblemadedesempenhoemduasoutrasmáquinasusandoaferramentapackerparaconstruirimagensDebianeUbuntuusandooqemu.Aquiestáaminhalinhadecomandodoqemu:

/usr/bin/qemu-system-x86_64-netdevuser,id=user.0,hostfwd=tcp::3213-:22-devicevirtio-net,netdev=user.0-cdrom/home/$user/packer_cache/23e6874116128e16e11cfad1c369c54be97c20023e59b9b9d39d312233e09cd6.iso-m512M-displaysdl-machinetype=pc,accel=kvm-vnc0.0.0.0:47-namepacker-openstack-drivefile=output-openstack/packer-openstack.qcow2,if=virtio,cache=none-bootonce=d

Comovocêpodever,estouusandoodrivervirtioecache=none.

Euatéatualizeioempacotadorparausar-opreallocation=metadatanosargumentosparaqemu-imgcreate.Issopareceumelhorarascoisasdeformamarginal,masodesempenhopermanececomordensdemagnitudemaisbaixasdoquenosistemahost.

Estacapturadetelaemparticularfoitiradaduranteoestágio"Instalando o sistema base" de uma instalação do Ubuntu, mas é consistente com mais ou menos qualquer uso de armazenamento.

Foi tirado na minha estação de trabalho que é um Macbrook Pro com um SSD; a máquina Openstack que tem o mesmo problema é a execução de um cluster RAID10 que testei em cerca de 1200MB / s no sistema host.

Obviamente, não espero que o desempenho do armazenamento no qemu corresponda ao do sistema host - mas é impressionante como isso é lento. As VMs host no cluster Openstack levam vários segundos para executar operações tão simples quanto uma instrução CREATE DATABASE no postgres.

No momento, a única pista que me resta é essa captura de tela aqui:

Aqui nmon mostra que /dev/sda tem utilização total, mas /dev/sda7 - a partição que realmente contém a imagem qcow2 - tem apenas 1% de uso. A última estatística corresponde ao que realmente espero que o desempenho do disco esteja aqui.

É importante notar que a saturação aqui não é simplesmente um artefato da minha ferramenta de monitoramento: todas operações na máquina host são muito lentas enquanto isso está acontecendo.

Como posso descobrir o que realmente está acontecendo aqui?

Devo estar vendo coisas como usar elevator=noop no host e convidados para ajustar o agendador?

-

Editar : aqui está a saída de uname -a na minha estação de trabalho:

Linux $hostname 3.18.6-1-ARCH #1 SMP PREEMPT Sat Feb 7 08:44:05 CET 2015 x86_64 GNU/Linux

E aqui na máquina Openstack:

Linux $hostname 3.13.0-40-generic #69-Ubuntu SMP Thu Nov 13 17:53:56 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

    

Answer 1

O backend de arquivo Qcow2 pode ficar significativamente lento com a configuração cache = none. Além disso, "-o prellocation = metadata" pré-aloca apenas os metadados e os dados reais do arquivo serão fragmentados. Em outras palavras, o arquivo qcow2 permanece esparso com apenas um curto traçado de alocação (para metadados). No passado apareceu uma opção "-o preallocation = full", na versão qemu-img recente eu não a encontrei.

Você pode tentar:
1) use cache=writeback (é uma aposta muito mais segura que a opção "inseguro")
2) pré-alocar todo o arquivo qcow2 emitindo " fallocate <filename> <filesize> " no arquivo qcow2?

Você pode encontrar outras informações aqui e aqui .

Obviamente, faça a operação acima em testar somente a VM! Se, após o teste, tudo estiver OK, você poderá propagar as alterações para outras VMs.

    

Answer 2

cache=none provavelmente não é uma boa ideia quando você está usando arquivos qcow2. Um arquivo qcow2 faz parecer que todo acesso ao disco está fragmentado. Isso significa que você obtém o desempenho de acesso aleatório da unidade toda vez e algumas unidades flash são tremendamente lentas (a intenção da ortografia) em gravações aleatórias.

Tente com cache=unsafe (temporariamente) para confirmar que este é o problema, então escolha um modo de cache onde você esteja satisfeito com o trade-off (eu iria para cache=writethrough na maioria das máquinas e cache=writeback se ext3 / 4 no modo de registro de dados) ou altere o formato do disco virtual.

Se nenhum dos modos de cache for aceitável, será necessário um formato de disco mais linear, por exemplo, volumes lógicos de lvm (meus preferidos) ou arquivos de imagem brutos. IME com lvm o desempenho do qemu está muito próximo do desempenho do host.

Modos de cache do Qemu