KVM / Qemu, Ubuntu: Por que mais CPUs convidados melhoram o Disk-I / O rapidamente?

Question

Temos um cluster Heartbeat / DRBD / Pacemaker / KVM / Qemu / libvirt que consiste em dois nós. Cada nó executa o Ubuntu 12.04 64 Bit com os seguintes pacotes / versões:

• Kernel 3.2.0-32-genérico # 51-Ubuntu SMP
• DRBD 8.3.11
• qemu-kvm 1.0 + noroms-0ubuntu14.3
• libvirt 0.9.13
• pacemaker 1.1.7
• pulsação 3.0.5

Os convidados virtuais estão executando o Ubuntu 10.04 64 Bit e o Ubuntu 12.04 64 Bit. Usamos um recurso de libvirt para passar os recursos das CPUs do host para os convidados virtuais para obter o melhor desempenho da CPU.

Agora, aqui está uma configuração comum neste cluster:

• O "monitoramento" da VM tem 4 vCPUs
• VM "monitoramento" usa ide como interface de disco (estamos atualmente mudar para o VirtIO por razões óbvias)

Recentemente, fizemos alguns testes simples. Eu sei que eles não são profissionais e não atingem altos padrões, mas eles já mostram uma strong tendência:

O nó A está executando a VM "bla" O Nó B está executando o "monitoramento" da VM

Quando rsync um arquivo da VM "bla" para VM "monitoramento", atingimos apenas 12 MB / s. Quando executamos um dd simples se = / dev / null de = / tmp / blubb dentro do "monitoramento" da VM, atingimos cerca de 30 MB / s.

Em seguida, adicionamos mais 4 vCPUs à VM "monitorando" e a reiniciamos. A VM "monitoramento" agora tem 8 vCPUs. Nós re-corremos os testes com os seguintes resultados: Quando nós rsync um arquivo de VM "bla" para VM "monitoramento" agora alcançamos 36 MB / s. Quando executamos um simples dd if = / dev / null de = / tmp / blubb dentro do "monitoramento" da VM, agora alcançamos cerca de 61 MB / s.

Para mim, esse efeito é bastante surpreendente. Como é que, aparentemente, adicionar mais CPUs virtuais para esse convidado virtual significa automaticamente mais desempenho de disco dentro da VM?

Eu não tenho uma explicação para isso e realmente aprecio sua opinião. Eu quero entender o que causa esse aumento de desempenho, já que posso reproduzir esse comportamento em 100%.

    

Answer 1

Eu vou dar uma idéia / explicação muito difícil.

Na situação do OP, além de medir dentro da VM, o host também deve ser analisado.

Nesse caso, podemos supor que os itens a seguir estão corretos

1. Em todo o teste, a largura de banda de E / S do host (disco) não está maximizada. Conforme a VM ( "monitoring" ), a E / S aumenta com mais CPUs alocadas a ela. Se a E / S do host já estiver no máximo, não deverá haver ganho de desempenho de E / S.
2. "bla" não é o fator limitante Como "monitoring" desempenho de E / S foi aprimorado sem alterações em "bla"
3. A CPU é a principal fábrica de ganho de desempenho (no caso do OP) Já que a E / S não é o gargalo, e o OP não menciona nenhuma alteração no tamanho da memória. Mas por que? Ou como?

Fator adicional

1. Escreva mais tempo que Read Isso é o mesmo para a VM e para o host. Coloque-o em termos extremamente simples: VM espera que o host termine de ler e escrever.

O que acontece quando mais cpu é atribuída a "monitoring" ?

Quando "monitoring" é alocado a mais CPUs, ele ganha mais poder de processamento, mas também ganha mais processamento tempo para E / S.

Isso não tem nada a ver com rsync , pois é um programa de thread único.

É a camada de E / S que utiliza a maior potência da CPU ou, mais precisamente, o maior tempo de processamento.

Se o programa de monitoramento da CPU (por exemplo, top) for usado em "monitoring" durante o teste, ele não mostrará um, mas todo o uso da CPU aumentará e também% wa. % wa é o tempo de espera gasto em E / S.

Esse aumento de desempenho só acontecerá quando sua E / S do host não for max. fora.

Não consigo encontrar o agendamento da cpu no site do KVM, mas há este blog mencionando que o KVM está usando CFS e cgroups, segue a citação

Within KVM, each vcpu is mapped to a Linux process which in turn utilises hardware assistance to create the necessary 'smoke and mirrors' for virtualisation. As such, a vcpu is just another process to the CFS and also importantly to cgroups which, as a resource manager, allows Linux to manage allocation of resources - typically proportionally in order to set constraint allocations. cgroups also apply to Memory, network and I/O. Groups of processes can be made part of a scheduling group to apply resource allocation requirements to hierarchical groups of processes.

Em poucas palavras, mais cpu = mais tempo de cpu = mais tempo de E / S em um determinado período de tempo.