O convidado KVM io é muito mais lento que o host io: isso é normal?

13

Eu tenho uma configuração de sistema host Qemu-KVM no CentOS 6.3. Quatro HDDs de 1 TB SATA trabalhando no software RAID10. O Guest CentOS 6.3 é instalado em um LVM separado. As pessoas dizem que veem o desempenho de convidados quase igual ao desempenho do host, mas eu não vejo isso. Meus testes de E / S mostram um desempenho 30-70% mais lento no sistema convidado do que no sistema host. Tentei alterar o agendador (definido elevator=deadlineno host e elevator=noopno convidado), definido blkio.weightcomo 1000 no cgroup, alterar io para virtio ... Mas nenhuma dessas alterações me deu resultados significativos. Esta é uma parte de configuração .xml de convidado:

<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>

Aqui estão meus testes:

Sistema host:

teste iozone

# 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 

Teste de leitura de dd: um processo e quatro processos 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

dd write test: um processo e depois quatro processos 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 convidado:

teste iozone

# 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 

Teste de leitura de dd: um processo e quatro processos 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

dd write test: um processo e depois quatro processos 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

Eu me pergunto é essa situação normal ou eu perdi alguma coisa?

Evolver
fonte
Você disse que mudou seu convidado para usar um tipo de virtio de barramento que ofereça melhor desempenho, mas ele deve ter os drivers do virtio instalados para colher esses benefícios. Você não disse se os está usando ou não. Não conheço o CentOS completamente o suficiente para comentar sobre o tempo em que esses drivers estarão presentes no seu convidado por padrão ou não.
jwbensley
1
O @javano CentOS sempre inclui o virtio e você precisaria removê-lo explicitamente, reconstruindo os pacotes do kernel.
Michael Hampton
Sempre útil saber, cheers :)
jwbensley

Respostas:

21

Você ainda não terminou o ajuste de desempenho.

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

Primeiro, qual mecanismo de E / S usar.

O QEMU possui dois mecanismos de E / S assíncronos: emulação POSIX AIO usando um conjunto de threads de trabalho e AIO Linux nativo.

Defina um io='native'ou io='threads'em seu XML para comparar cada um deles.

O segundo é qual mecanismo de cache usar. Você pode definir cache='writeback', cache='writethrough'ou você pode desligá-lo com cache='none', o que você realmente pode encontrar obras melhor.

Se você estiver usando volumes ou partições brutos, é melhor evitar o cache completamente, o que reduz cópias de dados e tráfego de barramento.

Não use a writebackmenos que sua matriz RAID seja suportada por bateria ou corre o risco de perder dados. (Obviamente, se a perda de dados estiver correta, fique à vontade.)

Terceiro, algumas outras coisas que podem ajudar incluem desligar barreiras e usar o agendador de prazos no hóspede.

Finalmente, faça alguma pesquisa. A IBM fez uma apresentação muito interessante sobre o desempenho de E / S KVM na Linux Plumbers Conference 2010. Além disso, eles têm um extenso conjunto de melhores práticas sobre o uso do KVM, o que certamente será do seu interesse.

PS Leituras e gravações sequenciais longas raramente representam uma carga de trabalho do mundo real. Tente fazer benchmarks com outros tipos de cargas de trabalho, idealmente os aplicativos reais que você pretende executar na produção.

Michael Hampton
fonte
+1 para "teste com seu padrão de E / S"
Javier
Oh, boa gosta dos documentos da IBM, +1 :)
jwbensley
1
Muito útil, obrigado! Agora, aprimorei meus resultados de convidados em até 90% com o desempenho do host. Minha culpa foi bastante estúpida: virsh reset <domain>não aplicou minhas virsh edit <domain>alterações e eu acreditava que o hóspede usava virtio, mas na verdade não. Apenas virsh destroy <domain>seguido por virsh start <domain>ajudado. Regras do Virtio! ;)
Evolver
1
cache = writeback não adiciona riscos da vida real (dados importantes não estão em perigo, apenas dados em voo, que são descartados de qualquer maneira em caso de acidente). Somente cache = não seguro. O write-back não implica requisitos adicionais de hardware ("matriz RAID suportada por bateria" não ajuda em nada). Ele tem o mesmo nível de integridade que um cache de gravação em HDD: ambos são liberados quando necessário pelo sistema operacional.
Korkman # 15/13
io='native'deu quase 20-30% o desempenho de gravação extra no meu caso
rahul286